Reducers
Data-caching tier for Lore
Data-caching tier for Lore
This functionality is provided by lore-hook-reducers.Reducers are the data-caching tier for Redux. Any resources you fetch from an API endpoint will be stored here.
Before reading this documentation, it's recommended that you already understand what reducers are, as this section will document the reducers that are built into Lore, but it will not explain what reducers are in general.
To learn more them at a foundational level, see the Reducer documentation on the Redux website.
Given a model called tweet, this hook will create the following reducers:
The reducers are not meant to be accessed or used directly. Redux handles that.
This reducer has a standard Redux format:
function byId(state, action) {...})
It's purpose is to listen for the standard CRUD ActionTypes (ADD_TWEET, UPDATE_TWEET, REMOVE_TWEET, andFETCH_TWEETS) and store the results in a dictionary where the key is the model id. If a model doesn't have an id (which happens during optimistic creates) the model is not stored in the dictionary. Keeping track of the models that only exist on the client side is the job of the byCid reducer.
Here is an example of the dictionary this reducer returns:
{
'1': {
id: '1',
cid: 'c1',
data: {..some data..},
state: "RESOLVED",
error: {}
},
'2': {
...
}
}
This reducer has a standard Redux format:
// standard reducer arguments
function byCid(state, action) {...})
It's purpose is to listen for the standard CRUD ActionTypes (ADD_TWEET, UPDATE_TWEET, REMOVE_TWEET, andFETCH_TWEETS) and store the results in a dictionary where the key is the model cid. There should never be a situation where a model does not have a cid.
Here is an example of the dictionary this reducer returns (note the c2 resource that has no id and is currently being created):
{
'c1': {
id: '1',
cid: 'c1',
data: {..some data..},
state: "RESOLVED",
error: {}
},
'c2': {
id: null,
cid: 'c2',
data: {..some data..},
state: "CREATING",
error: {}
}
}
This reducer has a modified Redux format as it requires an additional third 'options' arguments that includes the results from the byId and byCid reducers stored in a nextState object.
var _byId = byId(state.byId, action);
var _byCid = byCid(state.byCid, action);
var _find = find(state.find, action, {
nextState: {
byId: _byId,
byCid: _byCid
}
});
It's purpose is to store collections of resources group by a common query, and listens for the ActionTypeFETCH_TWEETS. If new data is created that matches the query criteria for one of the lists, it will also make sure that resource is included inside that list.
Here is an example of the dictionary this reducer returns:
{
'{}': {
state: "RESOLVED",
data: [
{
id: '1',
cid: 'c1',
data: {
color: 'red'
},
state: "RESOLVED",
error: {}
},
{
id: '2',
cid: 'c2',
data: {
color: 'blue'
},
state: "RESOLVED",
error: {}
}
],
error: {}
},
'{"color":"blue"}': {
state: "RESOLVED",
data: [
{
id: '2',
cid: 'c2',
data: {
color: 'blue'
},
state: "RESOLVED",
error: {}
}
],
error: {}
}
}
The keys for the dictionary are the JSON.stringify() version of the query. For example, a called to lore.connect that looks like this:
lore.connect(function(getState, props) {
return {
tweets: getState('tweet.find', {
where: {
color: 'blue'
}
})
}
})
Specifies the query {color: 'blue'}. It's that query that gets passed to JSON.stringify() and stored as the dictionary key. When new data shows in either the byId or byCid dictionaries that are new (don't currently exist in tweet.find) they are inspected to see whether the any of the stored queries match the data, and if so that data is inserted into the collection in the dictionary.