|
|
|
|
|
by tfb
3771 days ago
|
|
I believe most of what it's doing under the hood is explained in the article. Sorry if it isn't 100% clear. 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.