24 ms·

hard disagree. With prop drilling how do you get the setter methods into C3? You have to prop drill all the way down. Let's say I add a new component under C3

hard disagree. With prop drilling how do you get the setter methods into C3? You have to prop drill all the way down. Let's say I add a new component under C3 that has a side effect in some sister hierarchy under B. Then now suddenly in between and B and C3 and the other component I have to modify EVERYTHING to take that new change into account and these components now all have an extra prop that they don't intrinsically need but they keep in order to account for C3. Because data is so intrinsically linked with components Every component between B and C3 now needs to be modified to prop drill when previously it wasn't needed.

naasking 1y ago
This is true of any basic function call hierarchy. Lots of functions in every program's call tree are just passing around values they don't explicitly need but that some callers deeper in the call tree will need, so what you describe is a solved problem at its core: to avoid having to explicitly pass parameters that you don't use around, and having to modify whole call trees when those parameters change, lift those parameters into a data type. Then changes to parameters only have to be made in two places: the data type definition to add a field, and the initialization point to in initialize that field.
- ninetyninenine 1y ago
  Right but the problem here is that you have two hierarchies in react. 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.
whstl 1y ago
> how do you get the setter methods into C3? > 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.
- ninetyninenine 1y ago
  But the hierarchy is arbitrary. It's dependent on how you structure the GUI. You're saying to deliberately not let the GUI have deep structures such that the data won't need to prop drilled? That's unreasonable. Complex GUI's will inevitably have complex nested structures with many things that cause side effects. That's the problem. Data is coupled with GUI. React can't uncouple it.
  - whstl 1y ago
    > Complex GUI's will inevitably have complex nested structures 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".
    - ninetyninenine 1y ago
      >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. 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.
      - whstl 1y ago
        This seems to be going in circles. > 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.

naasking 1y ago

This is true of any basic function call hierarchy. Lots of functions in every program's call tree are just passing around values they don't explicitly need but that some callers deeper in the call tree will need, so what you describe is a solved problem at its core: to avoid having to explicitly pass parameters that you don't use around, and having to modify whole call trees when those parameters change, lift those parameters into a data type. Then changes to parameters only have to be made in two places: the data type definition to add a field, and the initialization point to in initialize that field.

ninetyninenine 1y ago
Right but the problem here is that you have two hierarchies in react. 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.

whstl 1y ago

> how do you get the setter methods into C3? > 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.

ninetyninenine 1y ago
But the hierarchy is arbitrary. It's dependent on how you structure the GUI. You're saying to deliberately not let the GUI have deep structures such that the data won't need to prop drilled? That's unreasonable. Complex GUI's will inevitably have complex nested structures with many things that cause side effects. That's the problem. Data is coupled with GUI. React can't uncouple it.
- whstl 1y ago
  > Complex GUI's will inevitably have complex nested structures 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".
  - ninetyninenine 1y ago
    >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. 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.
    - whstl 1y ago
      This seems to be going in circles. > 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.