undefined | Better HN

0 pointsninetyninenine5mo ago0 comments

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.

0 comments

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

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

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

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

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

1 more reply

j / k navigate · click thread line to collapse

0 pointsninetyninenine5mo ago0 comments

hard disagree.

With prop drilling how do you get the setter methods into C3? You have to prop drill all the way down.

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.

0 comments

naasking5mo ago

ninetyninenineOP5mo ago

Right but the problem here is that you have two hierarchies in react.

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

ninetyninenineOP5mo ago

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

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

1 more reply

j / k navigate · click thread line to collapse