[realharo]

So how do you deal with UI containers that don't really care about most of the state, but still need to pass it on to their child components?

It sounds like tracking this by hand ("what is needed where") could get messy, though I don't have experience with this approach.

[jcelerier]

> So how do you deal with UI containers that don't really care about most of the state, but still need to pass it on to their child components?

That's more or less the questions that they were asking in 1995 when they made the design patterns and conceived dependency injection.

[arc_of_descent]

Its turtles all the way down!

[shados]

Someone else beat me to the joke of "turtles all the way down", but that's mostly it.

I'll first refer to this Twitter thread: https://twitter.com/JEG2/status/902534133427134465

Now, the reasoning is: if you pass everything down, then things get interesting to reason about. Given a state to a component, it will always render the same way (give or take, local state and all). That is only true if you reason about children components as implementation details of the parent. That is, if a parent component renders a child one, and the child needs a prop, the parent should have that prop too.

Otherwise, you could render the parent 6 times with the same props and get 6 times a different result based on some undefined (at the parent level) magical global side effect.

Doing it this way makes your component tree essentially fractal: at any point you could detach an arbitrary component, put it in a library, and use it in another app: there's no assumption. Any part of the app is in itself a small app.

Now, the main issues is the boilerplate of typing it all out (which is minimized if you use a single "model" object at every level and either pass it as a whole, or a smaller part of it, to any child): if you use regular props for every value, you'll have top level components with 100+ props.

The other issue is maintenance. What happens when you move things around. That part really begs for a type system. Use Flow or TypeScript, and just let the compiler bark at you. When the compiler is done barking, you're done fixing, and you have a full statically checked view of your model dependencies. That's awesome!

The rest is mostly cultural. At which point does a developer throw their arm in the air and say "I don't want to do this!". A few months back, Jordan Walke did an Ask Me Anything on Discord where he said he had a pretty high tolerance for passing stuff down manually. I assume that explains some design decisions in React (eg: like how context was not a first class citizen earlier on), but I don't want to put words in his mouth.

For an example of this concept, look at Elm, where that's the primary way to build things. A fully fractal architecture where models come from the top and get passed all the way down to all the turtles. The way you build your model changes a bit (in apps Ive seen, it's more of a mirror of the component hierarchy, and less of a conceptual, normalized model), but boilerplate isn't that bad. Higher than the typical React/Redux dev will tolerate, which itself is higher than what most web devs will...but people who do it generally end up with very high quality apps that are trivial to maintain.