3 ms·

>And this is exactly what my suggested method achieves. Disagree. Highly. Component hierarchies fundamentally tied with HTML and CSS and therefore Also tied wi

>And this is exactly what my suggested method achieves. 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.

whstl 1y ago
> Component hierarchies fundamentally tied with HTML and CSS 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.
- ninetyninenine 1y ago
  Are you saying something like this?: 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 /> ); } But this is just bundling the props on a component and using the component itself as a bundle to drill down.
  - whstl 1y ago
    It's not just this, but that's one technique. 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.

whstl 1y ago

> Component hierarchies fundamentally tied with HTML and CSS 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.

ninetyninenine 1y ago
Are you saying something like this?: 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 /> ); } But this is just bundling the props on a component and using the component itself as a bundle to drill down.
- whstl 1y ago
  It's not just this, but that's one technique. 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.