question: middleground between smart and dumb components?

[jokeyrhyme]

I have a side project that features lots of components and the highest level of user interaction I've tried so far in a redux project. I'm trying to level myself up in terms of redux, and now I'm in a pickle.

I'm looked at #134, #419, #475, and @timbur's intriguing #419 (comment)

One idea briefly floated around the Slack channel was passing dispatch down from container / smart components to some smart-ish components. You don't pass it all the way down, just far enough to help limit the amount of actionCreator / eventHandler props that would otherwise be necessary.

In my case, the leaf components in my tree are still purely dumb, but some of the intermediate components are smart-ish. For me, these have been quite app-specific, and wouldn't have been very useful in other projects anyway, so trading portability for reduced boilerplate in these cases seemed like a worthy compromise.

So I've ended up with 3 types of components:

• smart "container" components
  • use connect(), dispatch() and actionCreators
  • pass dispatch down to smart-ish components
  • pass eventHandlers down to dumb components
• smart-ish components
  • use dispatch() and actionCreators
  • pass eventHandlers down to dumb components
• dumb components
  • only render and call provided eventHandler methods

My main problem with strictly having smart and dumb components is that so many methods need to be explicitly passed from the nearest smart component all the way down to a dumb component. For interaction-rich components, this becomes tedious.

The question I'm asking is: am I making a huge mistake with this approach? Does this sacrifice too much (simplicity, best-practices, testability, etc) in order to gain too little (less boilerplate, less code)?

[jokeyrhyme]

Also, my smart-ish components directly import and use actionCreators, instead of receiving them from parent smart components via props.

[ghost]

I'll try to create react-redux-providers some time this week. Meant to do it sooner but I've been super busy. It should actually be pretty quick to put together since nearly all of it is already done. There are a couple of minor (but necessary) improvements from my original comment though. :)

[gaearon]

Use whatever pattern works best for your apps.
You are in a better position than us to judge what works and what doesn't.
Closing as a duplicate of #419.

[ghost]

@jokeyrhyme see #419 (comment).