3 ms·

IMO/IME these problems have more to do with program organization rather than with any individual architecture. To avoid it, funny enough, you have to take cues

by whstl 1y ago

IMO/IME these problems have more to do with program organization rather than with any individual architecture. To avoid it, funny enough, you have to take cues from functional programming, and you need strong, composable, primitives with succint interfaces (the opposite of shadcn). Even for visually combining and placing components, you need stateless layout components [1] that don't depend on anything and just render children a certain way. This way it's possible to have a very flat component hierarchy. The entire state-logic at the top-level doesn't hurt much anymore. Also, just props+events are enough, no need for Context, Redux or other tricks. But if you go the "Clean Code" route and the main reason to have components is so so they're not too big, then you get deep hierarchies, prop-drilling becomes a big problem, and you need Context or state libraries specifically for inter-component communication. This is a problem that I've seen come up time and time again not only in Frontend but also in desktop apps and in video games. And backends often have the luxury of having the entire state in the database, so it doesn't happen as often. Of course the side effect of this is that you will end up with bigger components, and you need better abstractions, but IMO this is a small price to pay for having code that is easier to work with and doesn't need special ways for handling the data. Also this method tends to work better in bigger apps and people complain it's wasteful in smaller apps, so there's that too. [1] In the design world this is often called Templates. https://atomicdesign.bradfrost.com/chapter-2/#templates https://atomicdesign.bradfrost.com/chapter-2/#templates It's interesting how this didn't catch among frontend devs. I remember "layouts" being a big part of WPF for example.

ninetyninenine 1y ago
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".

by whstl 1y ago

ninetyninenine 1y ago

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".