Introduction
Last updated
Last updated
Using npm:
Using yarn:
redux-sands
gives you a single class as default export, from now on called ReduxWrapper
. Here's a simple example that demonstrates how you could use it:
And now let's call it:
As far as basic use cases go, that's it! No more hassle with manually creating actions, mappings and endless switches. Action-types get inferred automatically, as well as the linking to the reducer. You can focus on the actual app logic without having to deal with refactoring etc.
redux-sands
only works when calling the reducer with an object as param. You have to provide your state-changing values there.
Furthermore, ReduxWrapper
provides additional skills to simplify redux-usage:
You're able to import reducers as well as state-props from other ReduxWrapper
s in a dead-simple fashion. As demonstrated above, you can either import them 'as-is' or apply renaming.
When importing reducers, you have to hook up the saga-export to the saga-middleware in your app. Else the action won't get fired.
If you don't have it installed yet, here's the project.
redux-sands
internally uses proxies to import reducers from other comps. This is necessary b/c we can't guarantee that the component we're importing from has already been instantiated. Therefore, when an import is declared, the wrapper instance creates a unique proxy for that action. Upon calling, this proxy gets fired, which itself fires saga to dispatch the actual action.
This race-condition doesn't occur when statically importing the reducers to your store. But since we're working here at runtime, redux may not find the other's reducer during its init, since it hasn't been created yet.
Saga is necessary, b/c dispatching actions in other reducers is a non-pattern. Hence we're dispatching the requested action as a controlled side effect via saga.
Last but not least, as hinted above, redux-saga
is also supported. Here's how:
Here you can see a dummy-implementation that leverages the saga-integration. You provide both the standard reducer-function and a saga-function. The specific saga-fn gets derived by its key with the value representing the actual generator-method used by saga. After the async calls are done, you place your params in the 'put' method, which is provided in the action (including call
from saga). The params then get passed to the reducer, where stuff gets done as usual.
That's it for an overview. For detailed info, take a look at the API-specs following.