Best practices for providing for deeply nested components?

[ghost]

First thing: redux is awesome! Last night I almost began creating yet another Flux implementation but decided to try out redux first and was like, "Whoa this is really close to what I imagined, but better!" I'm really liking it so far. It makes a lot of sense. :)

I'm curious though... What would you all consider to be the best design when providing common data and action creators to multiple deeply nested components? I may not have looked hard enough, but the examples seem to only use containers that provide to top-level components, and then those components pass properties down to their children as necessary. I can't decide if I like that approach or if I should go with a more explicit approach (maybe using decorators). I like that redux is designed to work either way!

[ghost]

@timbur You might be interested in:
https://github.com/gaearon/react-redux/blob/master/README.md
#419

From what I understand, the idea is to keep redux out of the majority of your codebase making it easier to adapt to changes in the redux and react-redux api, etc.

In #419 there is a bit of conversation around preferences for/against this approach. I can tell you that in my limited experience, I initially didn't grok the separation, but as I've continued to build my application out, it started making more sense.

[ghost]

Thanks @danmartinez101! I've already read both the README and that particular issue but I'll go through them again. :)

As soon as I finish fully incorporating redux into what I'm working on, I'll report back here and I think I'll be able to better explain by example what exactly I'm talking about.

[ghost]

Oh, whoops, guess you'd looked harder than I assumed

[gaearon]

I think this is pretty much the same subject as #419 so let's discuss there.

[gaearon]

If I misread your question, and you're talking about something different, please reopen. ;-)