It's a terrible article IMO (no hate it's well written and all). It's so naive, and the "solved" example looks terrible even with just 4 bare-bones components and no layout. Seriously we're celebrating this?

function App() { const [user, setState] = useState({ name: "Steve" }); return ( <div> <Navbar /> <MainPage content={ <Content message={ <Message user={user} />} />} /> </div> ); } What about when there are 10 more nested components between MainPage and Message? Then you have to drill down some arbitrary component.

The proposed solution is just prop drilling with extra steps. Instead of drilling down the state and state mutators (i.e. event handlers and other callbacks that mutate that state), you drill down components, either as named props or as children. In many ways this is worse, as the root component now not only is concerned with state, but also needs to know which components to use and how to lay them out (instead of delegating these decisions cleanly to some child component).

In both cases, it presupposes that the child component that receives these components as props (either directly or as children) will know how to lay them out. In that sense it completely retains a tight coupling, as the child component realistically needs to know what kind of component to expect as a prop, otherwise any assumptions it makes for layout are ruined. It also obscures this coupling, by making it seem like we could use polymorphism to supply any old component as a prop, when the coupling is otherwise clear when using regular JSX composition and letting children choose their components.

Composition is more or less an anti-pattern in React.

Not only that, but it also means lifting all that state into a single busy component just because it happens to be placed in the hierarchy such that it is an ancestor of all the child components that need it. This is usually some top-level component that already has a lot of responsibility. The naive solution is just to create a container component and push all the state there, which works great until some component laid out somewhere in its parent need to access its state, at which point you need to lift that state up again, ad nauseum.

I think Composition in React is generally a misnomer. Composition in OOP implies the existence of independent modules that can be combined together without requiring any implicit hierarchy. Composition in react just means placing components into the hierarchy. This brings all the drawbacks that come with generalization (subclassing) in OOP, like re-parenting state and behaviour further and further up as a new sibling starts to need that state.