You have the HTML hierarchy which is the GUI, and then you have to force data to follow that hierarchy, when really only two components are relevant here. But with react you have to prop drill things all over the place.

> Let's say I add a new component under C3

Simple: you don't.

The entire point of my message is about not having the hierarchy be that deep.

I don't see what you're disagreeing with, as it seems you didn't get that my message is about architecture, not about a panacea solution.

That's the problem. Data is coupled with GUI. React can't uncouple it.

Not really.

And that's the thing: while this is the usual way, it doesn't have to be! But it does require a shift in mindset from the traditional way people partition components in React.

All I'm saying it is possible to structure the component hierarchy in a way that is independent from what the GUI looks like. By not having a deep hierarchy, you don't have "deep hierarchy problems".

So I'm forced to follow the mindset of making the GUI less nested and less complex because data flow requires it? I don't like it.

I prefer to be able to do anything I want with the GUI. The complexity of GUI and the complexity of dataflow should be completely independent.

>All I'm saying it is possible to structure the component hierarchy in a way that is independent from what the GUI looks like. By not having a deep hierarchy, you don't have "deep hierarchy problems".

Isn't it better to have components also independent of logic and side effects? Why am I forced into some specific structure for the sake of data flow? I still don't like this option. I want these concepts decoupled.

> I prefer to be able to do anything I want with the GUI

I didn't say you don't need to stop doing "complex GUIs". What I'm challenging is the assertion that "Complex GUI's will inevitably have complex nested structures". This is not true IME.

> The complexity of GUI and the complexity of dataflow should be completely independent.

And this is exactly what my suggested method achieves. But I'm doing this by going one step further and decoupling the visuals from the component hierarchy. I'm still separating parts of the page into components, I'm just using an alternative to deep hierarchies, and forcing myself to have better reusable abstractions rather than single-use components. I do this with richer primitive components and layout components. That's it.

> Isn't it better to have components also independent of logic and side effects?

This is exactly what I am proposing. What I propose requires keeping logic and side effects from the reusable components. All I'm saying is that the logic shouldn't be distributed among multiple small components, because there's no intermediate layers with single-use components. If you do this, there's no need to worry about the organization you complain about.

In a gist, it's more "Philosophy of Software Design" and less "Clean Code", but applied to React.

Disagree. Highly. Component hierarchies fundamentally tied with HTML and CSS and therefore Also tied with visuals.

Data is also tied to components as that's where it lives. Thus GUI and data are tied together fundamentally in react.

Perhaps you can elaborate. Because as far as I can tell what you're saying doesn't make any sense.

Once again: no, not necessarily, and definitely not fundamentally. Perhaps that's where you can't see where I'm coming from.

You can have more than one DOM level per component, and you can also have children/slots. Components don't even have to render anything. Thus GUI and dataflow can be 100% decoupled.

What I mean with all of this is "keep the React component hierarchy flat and use layout and richer primitives that will render THE SAME nested DOM that would be rendered using nested React component hierarchy".

The point is not changing which and how the final DOM looks like, or the design. The final HTML can and will stay EXACTLY the same with a flatter component architecture.

  function TwoColumn({ left, right }: { left: React.ReactNode; right: React.ReactNode }) {
    return (
      <div className="grid grid-cols-[240px_1fr]">
        <aside>{left}</aside>
        <main>{right}</main>
      </div>
    );
  }

  // Flat usage
  export function Dashboard() {
    return (
      <TwoColumn
        left={<NavTree />}          // could itself render nested <ul><li> DOM
        right={<ContentArea />}     // arbitrary component
      />
    );
  }

However this example has decoupled component hierarchy and HTML hierarchy. Which demonstrates they don't have to be coupled.

> But this is just bundling the props on a component and using the component itself as a bundle to drill down.

But there is no prop-drilling needed, as long as NavTree and ContentArea are also UI primitives. If you need NavTree and ContentArea to communicate with each other, for example, they're now siblings in the hierarchy, even though the HTML hierarchy is as deep as it needs to be for the design.

Btw: If "NavTree" and "ContentArea" are not primitives, they're the kind of thing that breaks a flat hierarchy and require prop-drilling/context/redux/etc in the first place. This is where one would use configurable primitive components, rather than the "Clean Code"-style extracted code.