Split reducers operating on the same slice of data in redux - redux

I have a store which is shaped like this:
{
// ...data
user: {
warranties: {
W_1: ['O_1', 'O_2'],
W_2: ['O_3', 'O_4']
}
}
}
Where keys starting with W_ are warranties, keys starting with O_ are options.
For each warranty I have one or more options associated to it, relations in user.warranties are in the form: warranty => [options].
To achieve it I'm combining my reducers like this:
rootReducer = combineReducers({
// ...other main reducers
user: combineReducers({
// ...other user reducers
warranties
})
})
Now, the "problem" is that both USER_WARRANTY and USER_OPTION actions are handled by the same reducer, because:
When I add an option, I need to push it to the correct warranty entry.
Inversely when I add a warranty I need to populate it with its default options.
And ultimately, they operate on the same slice of data
So the warranties reducer, has to react to both actions, looking like this:
export default function warranties(state = {}, action) {
switch (action.type) {
case USER_WARRANTIES_ADD:
// add warranty key to `user.warranties`
case USER_WARRANTIES_REMOVE:
// remove warranty key from `user.warranties`
case USER_OPTIONS_ADD:
// push option to `user.warranties[warrantyID]`
case USER_OPTIONS_REMOVE:
// remove option from `user.warranties[warrantyID]`
default:
return state
}
}
I would like to split this in two reducers, warranties and options, but still have them operate on the same slice of data.
Ideally I would then compose my root reducer like this:
rootReducer = combineReducers({
// ...other main reducers
user: combineReducers({
// ...other user reducers
warranties: magicalCombine({
warranties,
options
})
})
})
Where magicalCombine is the function I am having troubles to find.
I have tried reduce-reducers, but looks like the second reducer (options) is never actually reached, and I'm actually unsure about it since I'm not trying to achieve flat state, but actually operate on the same key.

A reducer is simple a function that take state and action and returns a new state object, so I think this would do what you want..
rootReducer = combineReducers({
// ...other main reducers
user: combineReducers({
// ...other user reducers
warranties: (state, action) => {
// state is state.user.warranties
// we pass it to each reducer in turn and return the result
state = warranties(state, action);
return options(state, action);
}
})
})
using reduceReducers should do the same thing (I haven't used it before, but that's what it looks like..)
rootReducer = combineReducers({
// ...other main reducers
user: combineReducers({
// ...other user reducers
warranties: reduceReducers(warranties, options)
})
})
combineReducers from redux is simply intentionally restricted to pass only the value of the state property that matches the key in the reducers object provided to it, it's not really special in any other way. see more here.. https://redux.js.org/recipes/structuringreducers/beyondcombinereducers

Related

Confusion with how createStore works in redux

I was learning Redux and came across createStore function. So, as I understood createStore receives 3 parameters:
reducer
initial state
enhancers (for simplicity we will use only middlewares)
But when we use createStore in action we do not pass initial state as the second argument BUT pass reducer with default state like this:
const initialState = {counter:0}
const reducer =(state=initialState, action)=>...
The question is why don't we put the initial state as the second argument but pass initialState to reducer?
I think you are confusing the initial state of a reducer to that of the global state of your app.
Global state simply means that combined state of all the reducers in your app.
For simplicity let's just assume you only have one reducer in your app.
Reducer :
function todos(state = [], action) {
switch (action.type) {
case 'ADD_TODO':
return state.concat([action.text])
default:
return state
}
}
So this simple function todos is our reducer which will give us the current state tree, whenever it is run.
So this is our first parameter to createStore.
Initial State :
['Understanding Store']
Let's assume our initial state as an array which contains 1 item as shown above.
This will be our second parameter to createStore.
Now we create our store like this:
import { createStore } from 'redux'
//... code
.
.
.
const store = createStore(todos, ['Understanding Store'])
Now our store is created.
Nothing fancy, store is basically an object, which has few methods on it.
One of those methods is dispatch.
This method helps in dispatching an action, which will run through our reducer and then update the state.
So when we do this
store.dispatch({
type: 'ADD_TODO',
text: 'Learn methods on Store'
})
This will update our state as below:
['Understanding Store','Learn methods on Store']
But when your app grows big, you might want to create different functions (reducers) to manage different parts of your global state.
If we have one more reducer, say counter.js :
export default function counter(state = 0, action) {
switch (action.type) {
case 'INCREMENT':
return state + 1
case 'DECREMENT':
return state - 1
default:
return state
}
}
Then to combine our 1st reducer todos and this counter reducer, we have an utility called combineReducer.
rootReducer.js
import { combineReducers } from 'redux'
import todos from './todos'
import counter from './counter'
export default combineReducers({
todos,
counter
})
Then using createStore, you just do this:
import { createStore } from 'redux'
import rootReducer from './rootReducer.js;
const store = createStore(rootReducer);
There are certain rules that you need to follow while using combineReducers.
Read the rules here
The use case for passing an initial state as the second argument in createStore is intended for use cases where you get this initial state from the outside when loading your app. Examples could be state generated on the server for server-side rendered applications that are hydrated on the client, or an application that restores the redux state form local-storage when loaded.
The initial value of a single reducer should be returned when the reducer function is called with undefined state, the easiest way is to use a default argument for state:
const reducer = (state = initialState, action) => ...
This allows you to define the initialState close to where the reducer is defined and it scales nicely with combineReducers when you have a larger number of reducers. If you would put all the initialState of all reducers into one object that is passed to createStore this would become difficult to keep in sync.
I think you have actually confused createStore with a reducer. Think of createStore as a function which returns you a collection of reducers by adding in a certain middleWares and other functionalities like dispatch
More often than not you have multiple reducers in your app and you actually combine them using combineReducers
Say for example you combineReducers is
import userReducer from 'reducers/user';
import authReducer from 'reducers/auth';
import countReducer from 'reducers/count';
const reducers = combineReducers({
userReducer,
authReducer,
countReducer,
});
Now the initialState to createStore must be of the format of an object with keys as userReducer, authReducer, countReducer and then the individual reducers state. For example
{
userReducer: { id: 1, name: 'Test'},
authReducer: { isLoading: true, isAuthenticated: false},
countReducer: {counter: 0}
}
Now thing of the second keys as equivalent to initialState each individual reducer
For example: reducer/count.js
const initialState = {counter:0}
const reducer =(state=initialState, action)=>...
The way it works is that createStore would actually call the reducer with the action each time action is invoked like
reducer(state, action);
In case of combineReducer it works like below
const combineReducers = (reducers) => {
return (state, action) => {
const tempState = { ...state };
Object.keys(reducers).forEach((key) => {
tempState[key] = reducers[key](tempState[key], action);
});
return tempState;
};
};
and for the initial time it invokes it with
reducer(initialState, {type: "##redux/INIT"});
so that each reducer's initial state is populated
P.S. If you do not pass the initialState to createStore, each reducer takes in the default argument passed to to it like const reducer =(state=initialState, action)=> and returns state for default switch clause causing the initialState from each reducer to be used

Using higher level reducer alongside combined lower level reducers

I have a react/redux app with store set up like this:
interface AppState {
substateA: SubstateA;
substateB: SubstateB;
}
And two reducers managing their individual states:
const reducer = combineReducers<AppState>({
substateA: reducerA,
substateb: reducerB,
});
What I would like to do as add a reducer that manages whole state additionally to those 2 reducers. How can I do that or is there other better solution?
A reducer is simply a function that takes state and an action and returns a new state object.
combineReducers returns a reducer which calls each of your reducers with only their slice of the state.
Have a play with something like this.. you may want it to run the combined reducers first, or your global state reducer first, depending on what you are doing.
const combinedReducer = combineReducers<AppState>({
substateA: reducerA,
substateb: reducerB,
});
const reducer = (state, action) => {
state = reducerC(state, action);
return combinedReducer(state, action);
}

Reducers in redux starting to look redundant - any way to combine them in a nicer way?

Using redux, I have a bunch of actions and a bunch of reducers that coincide with each of the action types.
Each of the actions map to a different part of the state being updated (all the action creators are primarily for fetching data from an API, for example, which maps to some part of the state). Our reducers currently look rather silly (simplified to A, B, C, for the sake of example):
export const rootReducer = combineReducers({
somePartOfStateA: someAReducer,
somePartOfStateB: someBReducer,
somePartOfStateC: someCReducer,
... (and many other reducers)
});
function someAReducer(state = [], action) {
switch (action.type) {
case FETCH_SOME_A:
return action.payload;
default:
return state;
}
}
function someBReducer(state = [], action) {
switch (action.type) {
case FETCH_SOME_B:
return action.payload;
default:
return state;
}
}
function someCReducer(state = [], action) {
switch (action.type) {
case FETCH_SOME_C:
return action.payload;
default:
return state;
}
}
// and a bunch of pretty much identical reducers continue below
From my understanding, the purpose of having them split is so that each reducer handles a part of the state's namespaces. The resulting reducers are simple, but pretty much the same thing over and over. Is there a recommended way to consolidate all of these reducers per piece of state?
Reducer is just a function. You could use higher order function to make reducer for you.
const makeSingleActionReducer = type => (state, action) =>
action.type === type ? action.payload : state
export const rootReducer = combineReducers({
somePartOfStateA: makeSingleActionReducer(FETCH_SOME_B)
...
})
Also you could go further by creating a config {stateKey: actionType, ...} and loop over it.

Redux - I don't understand "Task-Based Updates" example

In link: Task-Based Updates
I don't understand below code:
import posts from "./postsReducer"; // missing this code??
import comments from "./commentsReducer"; // missing this code??
and why should do that?
const combinedReducer = combineReducers({
posts,
comments
});
const rootReducer = reduceReducers(
combinedReducer,
featureReducers
);
only featureReducers is okie? not need combindedReducer? anh what is postsReducer code, commentsReducer code?
Thanks for helps!
Unfortunately that example is a little confusing (one of the few places in the normally solid Redux docs). If you go here and check out the 'third approach', you'll see this concept explained a little better.
Essentially, postReducer and commentReducer are there to handle actions that modify only posts or only comments--that is, things that do not require changes to multiple tables (e.g posts AND comments). featureReducer is the task-based reducer that handles actions that require updates to multiple tables.
A very simplified example:
const postReducer = (state = {}, action) => {
return state
}
const commentReducer = (state = {}, action) => {
return state
}
const combined = combineReducers({
posts: postReducer,
comments: commentReducer
})
const createComment = (state, action) => {
switch(action.type) {
case 'CREATE_COMMENT':
// update multiple tables (linked example actually does an ok job ok demonstrating this)
return updatedState
default:
return state;
}
}
const rootReducer = reduceReducers( combined, createComment )
In this example, the first two reducers just create the state shape. The third, which depends on the first two to set the state up for it, updates multiple tables across the redux store.
Your state shape will look like this:
{
posts: {},
comments: {}
}
If you're confused about reduceReducers, just try to think of it like combineReducers, only it doesn't affect state shape.

Redux: dispatch function to store?

How is it possible to save a function as state in redux store?
Example:
I pass a function as parameter to a redux-thunk dispatcher function and i want to save this filter function in my redux store:
export const SET_FILTERED_USERS = 'SET_FILTERED_USERS';
export function setFilteredUsers(filter) {
return (dispatch, getState) => {
const allUsers = getState().users.allUsers;
const filteredUsers = allUsers.filter(filter);
dispatch({
type: SET_FILTERED_USERS,
data: {
filteredUsers,
filter
}
});
const activeUser = getState().users.activeUser;
if (activeUser && !_.isEmpty(filteredUsers) && filteredUsers.indexOf(activeUser._id) === -1) {
dispatch(setActiveUser(filteredUsers[0]));
} else {
dispatch(setActiveUser(allUsers[0]));
}
}
}
In ReduxDevTools i can see, "filter" is not dispatched and saved in store. Is there a way to do this?
Thanks
Update: my shortend reducer:
import {
SET_FILTERED_USERS
} from '../actions/users';
import assign from 'object-assign';
export const initialState = {
filter: null,
filteredUsers: null
};
export default function (state = initialState, action = {}) {
const {data, type} = action;
switch (type) {
case SET_FILTERED_USERS:
return assign({}, state, {
filteredUsers: data.filteredUsers,
filter: data.filter
});
default:
return state;
}
}
As Sebastian Daniel said, don't do that. Per the Redux FAQ, that breaks things like time-travel debugging, and is not how Redux is intended to be used: Can I put functions, promises, or other non-serializable items in my store state?
What you could consider as an alternative is storing some kind of description of the filtering you want. As a sort of relevant example, in my current prototype, I'm creating a lookup table of dialog classes that I might want to show, and when I need to show one, I dispatch an action containing the name of the dialog type. My dialog manager class pulls that "dialogType" field out of state, uses that to look up the correct dialog component class, and renders it.
The other question, really, is why you actually want to store a function in your state in the first place. I see what you're trying to do there, but not actually what you're hoping to accomplish with it.

Resources