redux-scc update: combined actions and custom types!
A couple of months ago I wrote about a library for speeding up the creation of reducers, actions, and selectors to avoid all of the dreary boilerplate code (or, worse, copy pasta!) that comes along with hand coding reducers. Some really great feedback came from the comments on that article, some of which has resulted in the additions being discussed today. So, without further ado, it’s time to introduce combined actions and custom types!
Combined actions
A what now?
A combined action addresses one of the, if not the, biggest downsides to redux-scc previously; every action created was distinct and needed to be dispatched individually. This had a few drawbacks:
- Implementing undo/redo with a redux-scc powered store was much more difficult, as any update which necessitated multiple actions could not be trivially undone (as opposed to a single update).
- Each action dispatched would result in a state change, leading to subscribers of the redux store (e.g. connected React components) being informed of a change — leading to unnecessary calculations.
- Having functionality strewn across multiple actions made it more difficult to discern the intention of the action group if looking at the action history.
Combined actions were designed to address these shortfalls. They provide a way to group together multiple redux-scc actions into a singular action, dispatched once, which can also be named semantically for easy identification.
So, what do they look like?
Taking an example store chunk:
We gain access to a few base redux-scc actions — replace and reset for both stringReducer and arrayReducer, along with the whole suite of array helper actions for arrayReducer. Using these actions let’s say we need to update both of the reducers; previously, we would need to dispatch twice:
Not ideal. We have just added two actions to the action history, and triggered two distinct store updates! This time, let’s try it a again with a combined action:
All of the actions provided as part of the actions array will be applied as part of the single dispatch, with our name conveniently showing up in the action history.
Combined actions can also impact the same reducer multiple times. In the instance where multiple actions impact a reducer, they will play out in the order they’re provided to the actions array, operating on the intermediate state from the previous action:
Can I provide my own actions in a combination?
As combined actions are still just actions like any other, it’s possible to listen out for your own custom actions provided as part of a combination. You will need to listen for the combination type and then grab your action from the payload. I plan to introduce some utilities to make the parsing easier in the future!
Grouping it all together
So as a quick recap, combined actions:
- Allow for ‘atomic’ updates of the reducer store
- Provide a way to label a group of actions to make them easier to identify and associate with specific interactions/functionality
- Implements a basis for which external reducers can better integrate with the redux-scc generated reducers.
Custom types
The types available in redux-scc have thus far proved useful for most cases, but sometimes you just need a little more nuance than what the current library provided. Maybe you would like to enforce that a value must be less the a certain number, or you would like to create a type that only accepts strings or numbers, but nothing else. The existing types didn’t help here, with the Types.any() catch all type being the only real option (which, in essence, meant no validation was applied on the type).
Custom types change all of this; you’ll now be able to create your own types, with a custom validator and accompanying error message:
A common real world use case in my projects, for example, is that I often store dates as instances of moment in the store.
With this, you’ll now be able to accurately type check your entire store, no matter what the type in question is!
The road ahead
There are a few more improvements planned for redux-scc, such as the ‘wildcard key’, which will allow you to type properties of an object based on property patterns, and some general housekeeping (primarily removing the lodash dependency) but the main features of redux-scc, as it was originally envisioned, are now in place. Any feedback on your time spent with the library is extremely welcome, and will certainly be taken into consideration when making improvements in the future.
See you in the next update!