I keep reading that I should use redux-thunk or redux-saga to handle side effects.
Why not simply use action creators like that to dispatch multiple actions :
function loadProductActionCreator(dispatch) {
dispatch({
type: 'load_product',
})
fetch('api/product').then(
function (r) {
return r.json();
}
)
.then(function (res) {
dispatch({
type: 'loaded_product',
data: res
})
})
}
I tried that and it worked (complete code). So I guess there must be some inconvenients I'm not aware of.
You code is similar to what thunk does.
As per redux docs, actions should be pure. And they should always return same values for same input parameters. By using fetch you are allowing action to return not specific value, rather value from server and that mean action response may vary upon time.
That is called side effects. And it's something what shouldn't be in redux actions by default.
But why?
Yes, you can type it inside action like you have, in small apps it does not matter.
In larger application there are benefits of using redux-saga:
actions are predictable, they just return payload like
{
type: 'FETCH_POSTS',
params: {
category: 'programming'
}
}
and then you build middleware which will take actions with all data required to perform request to real API
Possible advantages:
Cleaner codebase (but may be overhead on smaller applications)
Separation of "dummy" actions with all required information to perform requests and actual API middleware
Request parameters are visible directly in redux dev tools
Possible to easily debounce, throttle fetches which may be really tricky with redux-thunk
Possible to easily combine actions (wait for another event/fetch, chain events)
Possible to stop running tasks
From personal experience, on one project (larger codebase) we have started with redux-thunk, but later we needed to integrate more advanced features, like throttle, and some dependencies between actions. So we rewrote everything to redux-saga and it worked well for us.
You are kind of replicating redux-thunk here. A pure redux action creator should return an action object to be dispatched and not dispatch an action itself (see redux doc on action creator).
To better understand why your technic is a replication of redux-thunk, look at this post from its author
Related
As its probably obvious, I am trying to have a couple of APIs, used within the redux-toolkit reducer all invalidate my queries, react-query. BUT, I can't get it to work because of not being able to use "hooks" within the reducer. Instead of tracking down all the api calls.. and then invalidating "n" number of times, I figure to just do something like... but of course, not working. Anyone have ingenius way of invaliding queries from "n" number of api calls?
.addMatcher(
(action): action is AnyAction =>
[
asyncActions.someAction1.fulfilled,
asyncActions.someAction2.fulfilled,
asyncActions.someAction3.fulfilled,
asyncActions.someAction4.fulfilled,
].some(actionCreator => actionCreator.match(action)),
(state, action: AnyAction) => {
// INVALIDATE MY QUERIES HERE
}
)
NOTE: I know redux-toolkit has it's own query. But I have a fast project and don't have time to learn it and also, by upgrading my toolkit, it creates massive amounts of TS errors (I guess a lot TS changes with later versions)...
You are not allowed to trigger any side effect in a Redux Reducer, ever. You will need to find another place to do something like this - if you want to tie it to the Redux action being dispatched, you could look into the listener middleware.
Would there be anything wrong/anti-pattern-ish (in terms of 'thinking-in-react/redux') in added a callback to the action.data passed into an action?
// reducer
ACTION_FOR_REDUCER() {
var x = 123
if ( action.data.callback ) action.data.callback( x )
return {
something: action.data.somedata
}
},
Then accessing that data later in the App when the action is called (in an container perhaps)
// later in the app
this.props.dispatch(changeSomething({
somedata: somedata,
callback: (x) => { console.log(x) }
}))
The idea is not wrong, the implementation is.
Instead of adding a callback, return a promise from the action (you will need redux-thunk middleware or some similar alternative).
Then you can simply do:
dispatch(myAction).then(callback);
Of course, you can also simply dispatch another action in your callback, which usually end up being one compound action.
const myAction = ...
const callbackAction = ...
const compoundAction = () => dispatch => {
dispatch(myAction())
.then(() => dispatch(callbackAction()));
};
The third principle of Redux (listed in the introduction section of the docs) is that 'changes are made with pure functions'.
A pure function is a function that always returns the same result given the same inputs, and doesn't cause any side effects. Having a callback log something out most definitely would be a side effect!
The docs go on to say:
It's very important that the reducer stays pure. Things you should never do inside a reducer:
Mutate its arguments;
Perform side effects like API calls and routing transitions;
Call non-pure functions, e.g. Date.now() or Math.random().
The reasoning behind this is it makes your reducers predictable - you know that, given an action with a certain payload, you're guaranteed to have the same output. This makes your app both easier to understand as a developer, and easier to unit test.
If you want to perform side effects when an action takes place, you should install a middleware that allows you to do so - some common examples of these are:
redux-thunk, which allows you to dispatch functions that can in turn dispatch actions (commonly used to make API calls)
redux-logger, which allows you to log out actions that are dispatched.
redux-devtools-extension, which allows you to view your state and actions in a Chrome devtools extension.
If you can't find a middleware package that does what you need (rare, to be honest - there's lots out there already!), you can write your own quite easily.
Callbacks introduce side-effects, so when using Redux you should consider returning a new state with the result, for example with done: true flag and react to that in componentDidUpdate.
For managing asynchrony and effects you can use redux-saga, redux-thunk, RxJs or another library.
If you want to stick with callbacks, why even bother with Redux?
If I have a situation: a component has 3 operations(list all info || search needed info || filter info), but all of these operations depend on same API, just different parameters.
I'd like to know what is the best approach to design Redux actions? To design 3 actions that are mapping the 3 operations? Or just 1 action because of just 1 API？
What are the most important considerations when designing Redux Actions?
Whether it should be one or two or three actions really depends on how your reducers are organized, and on how your UI is connected to your store.
You should think of API calls as side-effects of your actions, and not as the actions themselves. Your redux store holds a particular state of your UI: what filter is active ? What is the current search query ? and the like...
The most important consideration when designing actions is : what do they mean for the state of my UI? What impact do they have on it ? How do they relate to my store's state ?
If your concern is to mutualize API calls code, there are various patterns to handle that : use a simple helper function taking parameters, use something like redux-saga to trigger side-effects, etc.. But all in all, API calls shouldn't be relevant when designing actions.
There's nothing in the docs that says that actions should map to API endpoints. So you shouldn't have to think of how many API endpoints you have.
From http://redux.js.org/docs/basics/Actions.html:
Actions are payloads of information that send data from your
application to your store.
In your case though, if one action with payload can accomplish the result and mutate your state to the desired condition, I don't see a reason to use three (and thus have three reducers, etc).
The redux docs have a good section on how asynchronous actions/API usage should work within a redux app.
http://redux.js.org/docs/advanced/AsyncActions.html
I've followed this pattern, using the thunk middleware, and found it to work really well. The idea is to give your actions the ability to return a function. You will have:
A "main" function that will dispatch that the application is making an API call, make the API call, and handle the results.
Two pure action creators (functions that return an object with a type and any number of other properties) that will pass the information related to the API call to your reducers.
The actions:
/* Inside ./action.js */
/* This is the function you will dispatch from another component (say, a container component. This takes advantage of thunk middleware. */
export function fetchAllInfo() {
return function(dispatch) {
dispatch(requestAllInfo())
/* Import your API function, make sure it takes a callback as an argument */
API.fetchAllInfo((allinfo) => {
dispatch(receiveAllInfo(allinfo))
}
}
/* Pure action creators */
function requestAllInfo() {
return {
type: "REQUEST_ALL_INFO",
}
}
function receiveAllInfo(allinfo) {
return {
type: "RECEIVE_ALL_INFO",
allinfo,
}
}
The reducer:
/* Inside ./reducer.js */
export function inforeducer(state, action) {
switch(action.type) {
case "REQUEST_ALL_INFO": {
return Object.assign({}, state, {
/* This can be passed as prop so a component knows to show a loader */
isFetching: true,
})
case "RECEIVE_ALL_INFO": {
return Object.assign({}, state, {
isFetching: false,
allInfo: action.allInfo,
})
}
default:
return state
}
}
So with thunk middleware (or your own way of dealing with asynchronous dispatching) and a callback on each API call, you can use this method to work with API calls dispatching at both the beginning of the call and when you receive results.
I'm trying to get some thoughts on what people would consider the best practices for how people organize network calls in their react+redux apps. I usually let my components make the calls, get data and then pass that into an action that will get reduced. Is this the best practice or is it better to separate networking out of my components and place that logic somewhere else in the app, maybe in the reducers?
The best place to make network calls is in your action creators. However, you're going to need some middleware to make that work best. Take a look at this promise-middleware (in fact, I'd suggest checking out that whole tutorial). If you use that middleware, you can have action creators that return a promise and also have three action types - one for the request, one to handle successful responses, and one to handle failed requests. Then you just listen for those 3 actions in your reducers.
So with that middleware, you could have an action creator like this:
function networkCall() {
return {
types: ['MAKE_REQUEST', 'REQUEST_SUCCESS', 'REQUEST_FAILURE'],
promise: () => {
return new Promise((resolve, reject) => {
$.ajax({
url: 'example.com/api'
type: 'GET'
});
})
}
}
}
Obviously you are free to build your own promise middleware, but that should set you in the right direction.
I think this is one thing that was done right in Angular. You have all your network calls neatly placed in your services. This can easily be done in Redux.
The docs rightly suggest that network calls are in your actions. I'd factor them out into a separate place, you can call it "services". There you would define all your constants such as your API server URL, authentication-related stuff, etc. This would be the only place that is aware of the implementation details of your network calls - which library you use (jQuery, axios, superagent, etc).
Your actions files would import function from those services and call them. If you decide later on to swap out your networking library, you wouldn't have to change your actions.
You could use an API middleware, either redux-api-middleware or something of your own (it isn't very hard to write one).
Then, for example, your action creators could return actions like
{type: 'API_GET', url: '/api/userList', nextType: 'USER_LIST'}
...that would be later handled by a middleware that would send the actual request and then dispatch a new action like:
{type: 'USER_LIST_FETCHED', status: 200, payload: [{id: 1, ...}, ...]}
{type: 'USER_LIST_FAILED', status: 404, payload: {message: '...'}}
I pretty much follow the pattern of the actions in the redux tutorials for Async Actions. It makes most sense to me to keep everything async in the actions -- away from both the components and the store/reducers.
I also use Redux Crud to standardize the actions related to network actions.
I'm building a front-end for a search system where almost all user actions need to trigger the same async action to re-fetch search results. For example, if a user enters a keyword, then we need to fetch /api/search?q=foo, and if they later select a category we fetch /api/search?q=foo&categoryId=bar. I originally had separate action types for FETCH_RESULTS, SELECT_CATEGORY, DESELECT_CATEGORY, etc. I created one asynchronous action creator for FETCH_RESULTS, but the others are synchronous. The more I think about it, they all end up needing to re-fetching the results from the backend and update the app state based on the response from the backend.
Would it make sense for me to use the single async action-creator for any change? Or would it be better to use async action creators for each distinct user action (selecting a keyword, category, or filter)?
I think the advantage of granular actions would be the events more accurately reflect what the user did (e.g. the user selected a category) vs having to peer into the payload to figure out what actually changed, but they are all pretty similar.
This is of course something only you can really answer based on what you know about the project. I don't think that there is any inherent advantage to having the actions be more granular, and if there aren't any, its not worth the extra effort. I would have a generic FILTER_CHANGED event and not worry about being able to see what specifically changed--presumably the action isn't going to be complicated, so I'm not going to be debugging the action a lot. As the filter state becomes more complicated and diverse, it might make more sense to break out the actions. By default though, I don't really see much value.
I fully agree with Nathan’s answer.
I just want to add that in order to tell whether actions A and B are really one or two actions, you need to ask yourself: “If I change how some reducers react to A, will I also need to change how they react to B?”
When the handlers change together in the reducer code, it’s likely they should be a single action. When their changes may not affect each other, or if many reducers handle just one of them but not the other, they should probably stay separate.
I agree with Dan Abramov: if the text and categories are highly coupled in your interface, just fire FETCH_RESULTS with the text and categories as action payload.
If the text input and categories selection widget do not share a close parent component, it is complicated to fire a FETCH_RESULTS which contains the text and categories (unless passing a lot of props down the tree...): you then need the action granularity.
One pattern that I have found helpful when such granularity is needed is the Saga / Process manager pattern. I've written a bit about it here: https://stackoverflow.com/a/33501899/82609
Basically, implementing this on redux would mean there's a very special kind of reducer that can trigger side-effects. This reducer is not pure, but do not have the purpose of triggering React renderings, but instead manage coordination of components.
Here's an example of how I would implement your usecase:
function triggerSearchWhenFilterChangesSaga(action,state,dispatch) {
var newState = searchFiltersReducer(action,state);
var filtersHaveChanged = (newState !== state);
if ( filtersHaveChanged ) {
triggerSearch(newFiltersState,dispatch)
}
return newState;
}
function searchFiltersReducer(action,state = {text: undefined,categories: []}) {
switch (action.type) {
case SEARCH_TEXT_CHANGED:
return Object.assign({}, state, {text: action.text});
break;
case CATEGORY_SELECTED:
return Object.assign({}, state, {categories: state.categories.concat(action.category) });
break;
case CATEGORY_UNSELECTED:
return Object.assign({}, state, {categories: _.without(state.categories,action.category) });
break;
}
return state;
}
Note if you use any time-traveling (record/replay/undo/redo/whatever) debugger, the saga should always be disabled when replaying actions because you don't want new actions to be dispatched during the replay.
EDIT: in Elm language (from which Redux is inspired) we can perform such effects by "reducing" the effects, and then applying them. See that signature: (state, action) -> (state, Effect)
There is also this long discussion on the subjet.
EDIT:
I did not know before but in Redux action creators can access state. So most problems a Saga is supposed to resolve can often be solved in the action creators (but it creates more unnecessary coupling to UI state):
function selectCategory(category) {
return (dispatch, getState) => {
dispatch({type: "CategorySelected",payload: category});
dispatch({type: "SearchTriggered",payload: getState().filters});
}
}