redux-waitfor v1.0.0
redux-waitfor
Reducer combinator that allows reducers to wait upon each other.
Warning
You might not need to use this. See this discussion: waitFor leads to wrong design.
In the motivation section, I’ve explained the alternative without using waitFor
,
but since I’ve alread spent time creating and testing this thing,
I’ll put it online anyway.
Motivation
When building a Redux app, there are some cases that a reducer does not only
depend on the state
and action
, but also depend on the state returned by
another reducer.
For instance, I am building an expense tracking application using speech recognition. Therefore, there are these events:
SpeechRecognitionInitialize
(fired when tapping the mic)SpeechRecognitionStart
(fired when the app is ready to listen)SpeechRecognitionResult
(fired as you speak)SpeechRecognitionEnd
(fired when speech recognition ended)
My transcript
reducer consumes these series of events (actions) and produces
the transcript of what I just said (e.g. “40 Baht food”).
From the transcript
, I need to derive an interpretation
of the spoken text
(e.g. { amount: 40, category: "food" }
).
From the interpretation
, I need to derive an expense entry which will be saved
into the database.
However, before I save it to the database, I want to be able to edit it before I save.
There are two choices in architecturing this:
Put
transcript
,interpretation
, andstagedDatabaseEntry
into the store. This is the first idea that comes into my mind. “Surely I should do it this way,” I said to myself.But this means we need to set up dependencies between these reducers, so that when speech is recognized, the
interpretation
reducer has access to the latesttranscript
, andstagedDatabaseEntry
has access to the latestinterpretation
.This is where
redux-waitfor
comes into play.Think of this approach as using materialized views. Also consider the next option, as this option might not be the most appropriate one.
Only put
transcript
in the store, and use reselect to derive bothinterpretation
andstagedDatabaseEntry
.For the last requirement that I want to modify the
stagedDatabaseEntry
before actually saving it to the database, I’ll just store thestagedDatabaseOverrides
instead and derive them on-the-fly.This solution is less obvious to me, and I can only think of it as I write the documentation of this
redux-waitfor
.Think of this approach as using a (non-materialized) view of the database. In fact, this may be a better option!
Usage
If you insist on using this thing, first, you need to import it:
import { waitFor, combineReducers } from 'redux-waitfor'
waitFor(key, inject)
This is a function that takes a reducer, and returns a reducer that waits for
data from another part of the store with the specified key
.
const interpretationReducer = waitFor('transcript', transcript =>
(state = { }, action) => deriveInterpretationFromTranscript(transcript)
)
But wait! How can a reducer wait for more data? That seems impossible. Let’s try invoking this magical reducer.
> interpretationReducer(void 0, action)
[Function]
A function (a thunk) is returned instead of the new state! This signifies that we need more data from other parts of the store. We then pass the state from other parts of the store into that thunk:
> interpretationReducer(void 0, action)({
transcript: '40 Bath food'
})
{ amount: 40, category: 'Food' }
Now we have the actual, new state.
What really happens is that when we invoke that thunk waitFor
, it will inject
the state of the thing we’re waiting for into the inject
parameter.
That inject
function then takes the required data and returns a reducer,
which is then immediately invoked.
combineReducers(reducers)
This is a version of Redux’s combineReducers
that works with thunks.
How it works: Perhaps the easiest way to explain it is by examples. Here is our current state:
{ transcript: '',
interpretation: null,
stagedDatabaseEntry: null }
An action happened. It is dispatched to each reducer, just like Redux’s combineReducers
.
Some reducer returned the new state, and some returned a thunk:
{ transcript: '40 Baht food',
interpretation: [Function],
stagedDatabaseEntry: [Function] }
We then enter the digest cycle. We send this object into each thunk.
Since transcript
is available, the thunk injected it to and invokes the reducer.
Meanwhile, since interpretation
is not available yet at that time, the thunk returned itself.
This is the resulting state:
{ transcript: '40 Baht food',
interpretation: { amount: 40, category: 'food' },
stagedDatabaseEntry: [Function] }
This means we need another digest cycle. We did the same, and obtain the final state:
{ transcript: '40 Baht food',
interpretation: { amount: 40, category: 'food' },
stagedDatabaseEntry: { /* ... */ } }
For more example and tests, see example.js (which also serves as a unit test — it’s pretty comprehensive!).
As you can see, this is quite advanced and requires lots of explanation. Perhaps you can take this advice from The Zen of Python instead:
If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea.
So, unless you really need to, don’t use this library!
8 years ago