TL;DR: You can create redux providers that automatically match themselves to your components based on their propTypes. All you really need is a components directory, a providers directory, and an optional but recommended themes directory. Everything is easily interchangeable, understandable, maintainable, extendable, and reusable. There's a lot more included with all that like hot reloading both client and server, server rendering, etc., etc., etc. I built an app from scratch based on the included boilerplate yesterday and it took about 10 minutes as opposed to the 1 hour it would usually take!
Would be good to explain what `react-redux-provide` does under the hood. It might help convince redux users that the package is doing some of the work for them.
Also what would the code look like without the @provide decorator? [Stick to ES6, it's already crazy enough, no need to jump to ES7 stuff]
Short version:
- A provider has its own store (or it can share a store with other providers if you need it to).
- When you have a `propType` matching a provider's `actions`, those actions are automatically mapped to the store's dispatcher; so when you call `this.props.someAction`, it's essentially calling `provider.store.dispatch(provider.actions.someAction())`.
- And when you have a `propType` matching a provider's `reducers`, that component will always have the latest state of that reducer.
Without the `@provide` decorator, you would just `export default provide(SomeComponent)`. I've opted to use the ES7 decorator because it's cleaner, more concise, and immediately apparent.
This is a really neat idea, though I can imagine there might be some problems name conflicts for larger applications... still, it totally looks like something I will play with in the comping weeks. Thx for the writup and the above concise explanation.
