I recently tried something in my project and I was quite surprised that it worked. What I did was this :-
let result = {};
Axios.post("/auth", newUser).then(res => {
// console.log(res);
result = res.data;
this.props.signupUser(result);
});
The above code was written inside onSubmit event handler of a form in react. I wanted to get the response from the POST request and store the response in redux store and I tried the above code and it worked. The result was stored in redux store. So my question is was this supposed to work? and if yes then what's the purpose of redux thunk?
signupUser is a simple action creator, a function which returns a plain object and the variable newUser is an object which contains the form data.
The purpose of thunk is to give you more control over the async actions. While your code works, consider some more advanced requirements:
A different React component is supposed to show a loading animation while the request is in progress
You you want to track all api error responses somewhere
after the user has signed up, you want to trigger other requests for unrelated resources
Thunk facilitates all of those things in a more convenient way. You can also look at the current redux state at any point with getState in thunk actions. In general, it's better to separate concerns: React components show a signup form and are wired up with redux actions. The actions take care of api requests and data handling. Nothing is stopping you from writing all that code inside of a React component, but in a larger app this will get out of hand quickly.
Related
I'm new to whole react redux world but I would like to think that I now know how redux works. However right now I'm facing a new challange I need to implement async data fetching. I've choose to use axios as my http client.
The problem I have right now is that I've read about redux async thunk but I have no idea when and why would I use it. I understand that it adds middleware to redux which can handle async/await and promises.
I want to simply use axios to get data and then use dispatch to store them. Like this
const loadData = async () => {
const res = await axios.get('https://www.api.com/mydata');
const data = res.data;
dispatch(setMyData(data));
}
How would createAsyncThunk help me with that?
In your example, loadData only waits for one api request and then dispatches one simple redux action (setMyData). If you need it exactly like this, you're correct, why would you need thunks?
But imagine the following:
Several components in your app need to be aware that this api request is in progress (for example to show a loading indicator or to hide a button)
This function is needed in more than one place
You need to deal with specific error responses to the api request
Something in the global redux state could have changed while waiting for the api request to finish. You need to react to this before dispatching setMyData().
All of these are common requirements for complex react/redux apps, you might not have them right now but are likely to run into them at some point.
The thunk middleware provides an abstraction that deals with them. You could achieve the same by writing your own helper functions etc. but you'd reinvent the wheel in the end and a lot of react/redux devs would end up writing the exact same boilerplate code.
By design, redux actions are meant to be synchronous. Adding thunks like redux-thunk allow you to write action creators that are async and therefore return promises.
For example, I can write an action creator that looks like this:
const getUsers = () => async dispatch => {
let users = await getUsers();
dispatch({
type: GET_USERS,
payload: users
});
}
So instead of calling an api, fetching data, and then dispatching an action, you can have an action that does the fetching inside it
I have one file loading ui that I call whenever my app's components fetch data from the backend so the frontend can show loading...
The issue is when one component is fetching data, I dispatch loadingData() which causes the other components to showing loading... as well. I know this is happening because I have one action for loading that I dispatch. My question is, should I have separate loading actions for each component? If no, how can I go about fixing this? Thank you.
//Loading action
export const LOADING_DATA = '[ui] LOADING DATA';
export const LOADING_DATA_COMPLETE = '[ui] LOADING DATA COMPLETE';
export const loadingData = () => ({
type: LOADING_DATA
});
The answer is you shouldn't have a loadingData() Redux action in the first place. Loading or not is, as you correctly pointed out, every component's "local" state, so you should store it appropriately - inside each component's "normal" state.
Redux store is designed for storing the data that is mutual to several components. And whether some component is ready or not is certainly NOT that.
It is perfectly fine to handle a loading state either in local component state, the part of your redux state where you will finally store the data, or a completely different part.
There is no "one size fits all" solution and different applications handle it differently.
If you want to track that state globally, it is a fairly common pattern to have a yourApi/pending action followed either by a yourApi/fulfilled or yourApi/rejected action - this is how createAsyncThunk of the official redux toolkit handles it.
But of course, if you have two components sharing the same data, then they also share the same loading state. Maybe you should check if the data is already present and fetch it only when it is not already present, because why fetch it twice in the first place?
Or, if the loading state is really describing a different endpoint, really split that up into multiple loading state.
There is good practice that you have loading for each subject you're calling a backend api, for example a loading for calling books api, a loading for calling movies api and so on.
I recommend you create a loadings object in your state and fill it with different loadings that you need like this:
loadings: {
books_loading,
movie_loading
}
so in your components, you wouldn't call a general loading state which affects a lot of components, only those who need the specific loading will use it and you will solve the problem you have
I am new to React and want to understand the difference from classic MVC.
I want to create a simple components that loads some data initially and renders let say a grid.
On some state or prop change it will reload the data and re-render.
What is the best approach in react from below two options?
using the lifecycle events to load the data, update some state and render while in another event will show some loading opacity.
Work with redux and react-redux? but in all example I cant see API calls.
Is this the role of a middleware (Thunk?)?
Will appropriate an explanation.
Both the approaches are correct. It depends on your use case. If you can avoid using redux in your app, use the lifecycle methods to make API calls (also called subscriptions in react documentation). If you think your app has many components and different components needs to share a state, then use redux.
You should also look at React hooks https://reactjs.org/docs/hooks-reference.html
You can use Effect Hook https://reactjs.org/docs/hooks-effect.html to make API calls and update your component's state.
Update:
Both Thunk and Sage are used to manage side effects in your application (making API calls from here). I've used saga, I don't know much about thunk.
How you would use redux-saga:
Say if you want to get some data for display on a button click, this is how it works:
On button click you dispatch an action, say GET_DATA
Your redux reducer will change some state on this particular action, say isLoading=true
You can use isLoading in your component to show a spinner/overlay
At the same time saga will listen to GET_DATA action and make the API call
If success, from Saga you'll dispatch an action, say GET_DATA_SUCCESS with the data from API call
Reducer will change isLoading=false and set the data in state, say apiData = { ... }
If failure, from Saga you'll dispatch an action, say GET_DATA_FAILED with the error code/message
Reducer will change isLoading=false and set the error in state, say apiError = { ... }
You can now use isLoading=false in you component to remove spinner and display the data (apiData) or error (apiError) in you component.
You can go through this tutorial to learn more https://redux-saga.js.org/docs/introduction/BeginnerTutorial.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Why use Redux Thunk then one can do something like this:
ReadableAPI.getCategories().then((categories)=>{
console.log('after getCategories', categories)
this.props.dispatch(addCategories(categories))
})
Isn't this more straightforward and achieves the same thing?
This answer from Dan Abramov explains beautifully why you would want to use redux-thunk in your application. One more benefit of using redux-thunk in your application is that you keep your business logic separate from your view part (React in your case). We had a use case where our app was written in backbone and we wanted to re-write our whole app in React. We realised that it is easy if your view and collection/models are separate. We started depreciating just the html templates and not the collections. When we deprecated all the html templates, we started using Redux in our app and deprecated our collections too.
What I want to put here is that we had our view and business logic separate, we could refactor that easily. Similarly, with React and Redux, you would want to keep that different, so that if something new comes and replaces Redux, at least you won't have to deprecate your views and you just will have to change your business logic.
Redux Thunk basically allows us to delay the dispatch of an action, i.e we can handle the action returned by the action creator and call the dispatch function when we really want to dispatch.
Your example is incomplete and it was frustrating to follow how you arrived at that oversimplified solution. After researching it I realized, you probably have some ReadableAPI.js file somewhere you should have posted with what is probably a configuration using fetch and inside of it you probably have something like this:
export const getCategories = () =>
fetch('http://localhost:3001/categories', {headers})
.then(res => res.json())
.then(data => console.log(data))
which ties into your:
ReadableAPI.getCategories().then((categories)=>{
console.log('after getCategories', categories)
this.props.dispatch(addCategories(categories))
})
So in this solution you are returning a Promise which is an object which essentially gives us notification when some amount of work such as a network request is completed and in order to get notified we chain on the .then() function which we pass an arrow function like you did: then((categories)=> and that arrow function will be called at some point in the future.
It looks like you are referring to that data as categories and you are console logging 'after Categories', categories.
What we need to know is what are the different properties attached to that categories object? Does it have a data property? Does it have a results property with some actual data in it? Is there a categories.data.results that contains whatever the data is?
So let's just say the answer is yes to all the questions.
You are going about that in a bit of a hard way in order to deal with asynchronous requests because it's not just that snippet of code: there is also what's inside the ReadableAPI.js file, right? Also, you are using Promises that can get kind of hairy and you would have already put together two files just to deal with asynchronous request which would be okay if it was just a plain Reactjs application, but you mentioned your approach as an alternative to Redux-Thunk which implies using Redux.
For your approach in the vanilla Reactjs space I would use Axios and implement the async/await syntax, but with Redux involved you don't want to use a Promise.
Now, the action creator I had to make up in the ReadableAPI.js file would not work in a Redux environment because it does not return a plain JavaScript action object and so we would have to use a custom middleware as the error says to do.
So how does a middleware like Redux-Thunk work? Redux-Thunk essentially relaxes the rules around an action creator.
The purpose of Redux-Thunk is not to be passed a request object and it will take it away and go to work for you.
Redux-Thunk is an all purpose middleware that allows us to deal with asynchronous action creators, but it also allows us to do many other things as well.
With Redux Thunk involved, your action creator can return an action object. If you return an action object it still must have a type property and if it is an action object that gets returned it can optionally have a payload as well.
The other thing that Redux-Thunk does is allow you to return either an action object or a function.
If you return a function, Redux-Thunk will automatically call that function for you.
That's it, thats all Redux-Thunk does. However, One thing Redux-Thunk does really well is to manually dispatch an action. That is the key part. With Redux-Thunk we can manually dispatch an action at some point in time in the future.
So we get this new action created and it can be a plain JavaScript object or a function, but when we are dispatching it manually inside of Redux-Thunk or inside of a function it's basically always going to be a plain object.
So we will dispatch this action and it will flow back into dispatch and dispatch will send it right back into Redux-Thunk and Redux-Thunk will ask if it's an action or object.
When it's an object, Redux-Thunk forwards it automatically to all the different reducers.
With Redux-Thunk we can return a function and if we do, that function gets invoked with dispatch and getState arguments and with those two functions we have unlimited power over our Redux store and we can change any data and read any data and at any point in time in the future we can manually dispatch an action and update the data inside of our store.
Where am I getting the dispatch and getState? From the Redux-Thunk library source code:
https://github.com/reduxjs/redux-thunk/blob/master/src/index.js
src/index.js:
function createThunkMiddleware(extraArgument) {
return ({ dispatch, getState }) => next => action => {
if (typeof action === 'function') {
return action(dispatch, getState, extraArgument);
}
return next(action);
};
}
const thunk = createThunkMiddleware();
thunk.withExtraArgument = createThunkMiddleware;
export default thunk;
If you look at the if conditional you see the body of the actual logic that is going on. Did you just dispatch an action? If so, is it a function? If it is, then Redux-Thunk is going to invoke that action with dispatch and getState.
If our action is not a function, Redux-Thunk does not care about it, so on it goes to the next middleware as indicated by the return next(action);, otherwise on to the reducers if there is no middleware to run.
I have a project that uses React and Redux. I have multiple React components that need to use a common method that will scrape data out of the Redux Store, build a request object and fire off a rest request to the server.
I wouldn't want to write the method that does this more than one time. So, should this method be it's own React component, or should I just put it in a common javascript file? I'm not sure what the point of having a component would be if you're not rendering any JSX. On the other hand, if I put it in a common javascript file, is it possible to wire up redux to that file to get access to the states in the store?
Thanks in advance.
Adding the redux-thunk middleware lets you dispatch functions, which then get access to dispatch and getState(). From there you can do anything you want, such as using selector functions to extract pieces of state that you need, and making AJAX calls. The thunk action creators can be passed to components as props, including binding them to auto-dispatch:
function someThunk() {
return (dispatch, getState) => {
const state = getState();
// do anything you want here
}
}
const actions = {doStuffOnClick : someThunk};
export default connect(mapState, actions)(MyComponent);
Further resources:
redux-thunk is described in its repo at https://github.com/gaearon/redux-thunk .
I have a gist demonstrating some common thunk usage patterns at https://gist.github.com/markerikson/ea4d0a6ce56ee479fe8b356e099f857e.
My React/Redux links list has links to articles discussing thunks and side effects in the Redux Side Effects category.
It should not be a Component because, as you said, there is no visual aspect to it.
Create a new action that does just that and dispatch the action from anywhere you need. This action could check the store to see if the action has already happened and then do nothing (or refresh).
The module that uses import {createStore} from 'redux' creates your store. Import the created store in the action module and use store.getState() to inspect the current state of your store.