I have an app using redux-thunk and want to try out redux-observable.
Currently I have a thunk action creator that does the following:
const initState = () => {
return dispatch => new Promise((resolve,reject)=>{
//these each return axios promises as they get data from the server
const pr1 = dispatch(processData1())
const pr2 = dispatch(processData2())
Promise.all([pr1,pr2])
.then(r=>resolve(true))
.catch(e=>reject(e))
})
}
}
and this is called from my component in componentDidMount like so:
this.props.initState()
.then(r=>this.setState({loaded:true}))
.catch(e=>this.setState({loadError:true}))
Now I want to try redux-observable Can I combine it with redux-thunk and replace the processData2() call to instead dispatch an action which is dealt with by redux-observable?
i.e.
const pr2 = dispatch({type:OBSERVABLE_PROCESSDATA2})
Now as far as I can tell, this isn't going to return a promise so the original code will now break as in Promise.all will .then(r=>resolve(true)) immediately even though redux-observable epic has not yet processed it.
So is there a way I can wait for that dispatch to do the async stuff in the epic or do I need to basically go redux-observable all the way in this case?
You can combine redux-thunk and redux-observable in the same project.
actions ---> redux-thunk ---> redux-observable ---> store
But the idea of redux-observable is action$ in and action$ out. So you will need to write all your async logic in epics, and don't have access to the returned observable which is action stream.
So it's either you may want to convert the whole initState to an epic or just use rx.js directly in this thunk without creating epics
Related
In the Redux Style Guide, it is strongly recommended to Put as Much Logic as Possible in Reducers:
Wherever possible, try to put as much of the logic for calculating a
new state into the appropriate reducer, rather than in the code that
prepares and dispatches the action (like a click handler).
What I'm not sure of is, if thunks are also considered to be "the code" of some sort. Besides, we've also been (mis?)using thunks to grab data from other slices of state.
Hypothetically simplified code snippet of such thunk:
const addX = x => (dispatch, getState) => {
const { data, view } = getState();
const { y } = view; // <-- here accessing data from `view` state.
const yy = doSomeLogicWith(y);
const z = doSomeMoreLogicWith(yy);
dispatch({ type: 'data/xAdded', payload: { x, z } });
};
Is this actually considered to be an anti-pattern in Redux? If so, what are the cons of doing this?
Yes, a thunk would qualify as "the code that dispatches the action" for this case. So, what the rule is recommending here is that if possible, the action would just contain y, and the function calls to doSomeLogicWith(y) and doSomeMoreLogicWith(yy) would ideally exist within the reducer instead.
Having said that, it's totally fine for a thunk to extract pieces of data from the state and include that in the action, and it's not wrong for a thunk to do some pre-processing of data before dispatching the action.
The style guide rule is just saying that, given a choice between running a particular piece of logic in a reducer or outside a reducer, prefer to do it in the reducer if at all possible.
I have a project in which I have applied the redux-thunk middleware to my redux store. Now I have several thunks in my code and this are also being dispatched, but they return ThunkAction<Promise<void>, void, void, AnyAction> so I assume these are async.
In other places of my code I’m directly calling the dispatch method on the store. Does this actions also become asynchronous as an effect of applying middleware or do they remain synchronous?
For example If i do:
store.dispatch(someAction);
Would that still be synchronous?
Thanks in advance.
Yes.
Dispatching is 100% synchronous by default.
If you add middleware, a middleware may alter, delay, or stop an action from progressing through the dispatch pipeline.
However, in this case, the redux-thunk middleware does not do anything asynchronous. It simply checks to see if the "action" is actually a function, and if so, executes it immediately:
function createThunkMiddleware(extraArgument) {
return ({ dispatch, getState }) => (next) => (action) => {
if (typeof action === 'function') {
return action(dispatch, getState, extraArgument);
}
return next(action);
};
}
If the thunk middleware is applied, store.dispatch(someThunkFunction) will return whatever the thunk function returns. So, if you return a promise from the thunk, that promise will be returned from store.dispatch().
For the TS types, the first generic argument should indicate the expected return type of the thunk function. However, you would likely actually have to specify that yourself - it shouldn't be appearing randomly.
const store = createStore(
rootReducer,
initialState,
compose(
applyMiddleware(thunk, api, wsMiddleware, createLogger()),
typeof window === 'object' && typeof window.devToolsExtension !==
'undefined'
? window.devToolsExtension()
: DevTools.instrument(),
),
);
So the above is how you would usually create a store, and then you have your middleware that starts like this:
export default store => next => (action) => {
I did read up the middleware portion from redux.org, but anyone able to better explain it to me what's going on there ?
so is the middleware is receiving the store ? and calling out the next function from the store and than finally using the parameters given as action (in this case). ?
The Redux middleware pipeline can be broken down like this...
store => {...}
The store API is the first argument given to the pipeline. This allows the middleware to get the current state at any point in the pipeline and/or dispatch new actions into the store.
Note: It has many of the same characteristics as the store returned from the createStore function, but it is not the same. Only the dispatch and getState functions are available.
next => {...}
The next argument is a reference to the next middleware in the chain. If there are no more middleware to go, the store handles the action (i.e. pass it into the the reducer).
If next is not called, the action will not make it to the reducer. This can be useful to suppressing something that is not a valid action on it's own, such as a function or a promise, as an error will be raised by Redux if it tries to handle it.
action => {...}
The action argument is the thing that gets dispatched into the store.
{...}
In here is where you will test the action to see if there is something special you want to do with it and whether you will pass it onto the next handler.
An example
For this example, we will create a simplified thunk middleware, explaining how it uses each part of the pipeline.
export default store => next => action => {
// if the action is a function, treat it as a thunk
if (typeof action === 'function') {
// give the store's dispatch and getState function to the thunk
// we want any actions dispatched by the thunk to go through the
// whole pipeline, so we use the store API dispatch instead of next
return action(store.dispatch, store.getState)
} else {
// we're not handling it, so let the next handler have a go
return next(action)
}
}
Functions that conform to the Redux middleware API. Each middleware receives Store's dispatch and getState functions as named arguments, and returns a function. That function will be given the next middleware's dispatch method, and is expected to return a function of action calling next(action) with a potentially different argument, or at a different time, or maybe not calling it at all. The last middleware in the chain will receive the real store's dispatch method as the next parameter, thus ending the chain. So, the middleware signature is ({ getState, dispatch }) => next => action.
The answer was found in the applymiddleware documentation.
https://redux.js.org/docs/api/applyMiddleware.html
React, redux, redux-saga
I dispatch an action, say CREATE_REQUESTED to the store.
Redux-saga runs, and makes the async call to the server.
After the saga completes, i.e. blocks for the next CREATE_REQUESTED I want to execute additional code, from the container/component from which the first CREATE_REQUESTED was initiated.
// pseudo code
class Cmp extends React.component {
onCreateClick(id) {
const record = {id, name: 'alabala'}
// I am missing the .then() part
this.props.dispatch({type: 'CREATE_REQUESTED', record}).then(created => {
console.log(created)
}
}
}
Is there a way to do that? How?
If not, how am I supposed to design this task?
One approach could be to pass (resolve, reject) options along with the action, and make the saga call them on succcess/failure. Seems OK.
https://github.com/yelouafi/redux-saga/issues/161
In this github redux example, a dispatch of the event ADD_TODO is used to add a task. During the debugging, I found out that adding a task causes both the reducers todos and visibilityFilter being called.
How can I call just the todos reducer and not visibilityFilter reducer when I add a task. Also the visibilityFilter reducer if I sent an event of type SET_VISIBILITY_FILTER.
The combineReducers utility intentionally calls all attached reducer functions for every action, and gives them a chance to respond. This is because the suggested Redux reducer structure is "reducer composition", where many mostly-independent reducer functions can be combined into one structure, and many reducer functions could potentially respond to a single action and update their own slice of state.
As mentioned in other answers, combineReducers calls every reducer whenever a dispatch is called. You can avoid the other values changing, by making the default case equal to the state parameter passed in, so essentially they are reassigned their current value.
For example:
const individualReducer = (state = "initialState", action) => {
switch(action.type)
{
case "ACTION_TYPE":
return action.payload;
default:
return state;
}
}
export default individualReducer;