I am using Redux in my application. One my page, I have 5 controls which subscribe to the store. But in case of certain specific actions, I do not want 2 controls to respond to the change. How can I handle this situation.
I looked at this link https://github.com/reactjs/redux/issues/580 but I could not find anything like store.getState().lastAction.
What is the best way to handle this scenario?
You should have a flag in your state saying if you should update your control or not. One of the base principle of Redux is to not allow client to know how the store is updated. You should only respond to state changes, whatever has changed the state.
But I don't really understand why you have to handle store changes by hand in react ? You should consider using react-redux.
Edit
As pointed in comments, if you need to do some side effects when dispatching actions, you should use some redux middleware such as redux-thunk, redux-saga, redux-observable, redux-loop. The simplest one for beginner is, I think, redux-thunk. It allows you to dispatch a simple function that will be executed and that will be able to also dispatch other actions.
However, to trigger a side effect for each action and being able to filter by action type, please see redux-tap as indicated in comments by #Brandon.
Related
We are developing a React application using Redux to manage the state. In general, Redux serves us well, but in one part of the application, we are using WebSockets to update our app state to allow all the connected users to have the most recent version of the data.
It looks like this: https://i.stack.imgur.com/uNAsk.png
In a regular Redux application, we would have 3 actions: ACTION_LOADING, ACTION_SUCCESS and ACTION_FAILURE to handle HTTP requests. In this case, the state is updating automatically after receiving new data from the WebSocket.
Is it correct to have a Redux action (thunk) to post this data to the server even if it does not modify the state, or is it better to call the service without using Redux in these cases?
In case we create actions, what pattern would you recommend?
Thank you.
I would recommend wrapping it in a thunk for a couple of reasons:
There's nothing fatal about initiating an action that doesn't end up mutating state (for whatever reason).
Even if you aren't doing anything in the case of a successful POST (since all the action will come later via a message from the server), you still might need to dispatch an actions in case the POST fails for some reason.
It allows your components to use one consistent mechanism (action dispatch) rather than sometimes one way and sometimes another.
We know that if a Redux action triggers an API call to a server (whether in Redux middleware or Redux Thunk), it takes time to receive the answer from the server. During this waiting phase, the UI must somehow shows the user that some loading is being done (showing an Spinner for example). In React and React native, a famous trick to handle these common situations is a isLoading boolean flag in the Redux state and of course, a loading action being dispatched. This boolean will be toggled once the answer is ready to be shown, so that I can update the UI.
However, after applying this trick for years, what I've got is an application full of bugs and errors and a super dirty code with a lot of redundant code.
I have checked all the React life cycle hooks to check the order, in which the hooks are called and the process of Redux dispatching. It seems that Redux and React works totally separately. (I know that getDerivedStateFromProps is called once the store has been updated, but it does not solve my problem)
I need a better way to handle these common situations. I don't know if I need to make modification in Redux part of my application, or in the UI, or ...
I'm working on a React+Redux application. I'm calling APIs through Redux actions and storing the response data in the Redux state. But there is a case, Where I don't have to store the API response data in the Redux store.
So the question is, Is there any valid reason to call the APIs through
Redux actions or Should I call the APIs directly since I'm not storing
the response data in Redux store?
It depends on what kind of call you're trying to make, and who's concern it is.
Here are a few cases:
Is this a one-way call to track something?. You can fire an action that gets picked up in a middleware. this is a good case for sending analytics.
This doesn't have to be stored in Redux's store.
Is this a call where some other part of your application will need this data?, then this is a good use case for making an update in the Redux Store so other components when read this and use props to decide what to render etc.
Is this a call where it only concerns one component or isolated part?. You can make this call inside the component in componentDidMount since this doesn't concern anyone else
Alternatively take a look at Sagas, they observe all actions that get dispatched and decide what to do with them in a clean way.
The accepted answer quite well explains the scenario where from API call can be initiated. For better user experience, we always show some spinner or busy sign to inform the user that a request is being made and it has not finished yet. It may happen that API response is not mutating the state, but to let the user know some task is going in the background, we usually update store (for global access) or state (for component level access) with value like isFetching or anything meaningful.
So, it depends on the developer, whether he/she want to show some busy sign or silently perform the API request. Moreover, if they want to show busy sign then, they should decide which part of the application should be aware of the API call. If it is restricted to the component level only, then no need to make the call in actions, otherwise, for global level, yes it should be inside action.
For the sake of uniformity, you should always follow the redux way, even though all the responses are not stored in Redux. It is also a question if you are not using the response from an API call why are you making the call. This argument is counter-intuitive. If you are using the response in some way better do it the Redux way. It is advised to always store the response to a call to Redux and use it, I am sure you are making API calls to do some action on UI.
It may be a naive/not smart question:
I want to keep track of a global state in my app. The user, for example, chooses some options for the app and I want those options to be accessible from any component in my app.
So I trigger some setOptions action and have a reducer for it. This action doesn't need any server call - it's internal to the app.
My question is, does it needs to have its own saga? In my opinion it's not really needed here but maybe it's good practice to do it this way to better keep track of things?
What do you think the better option is?
That's not the use case for redux-sagas. Redux-saga is for async operations. If your intent is to keep a property global, your redux store already has you covered in all ramifications of it.
You already have your reducer setup. So once you dispatch an action in that case the store is updated with the new state by your reducer. I think that's all you need since you're not making a server call whatsoever.
We have a React / Redux application that usually fetches data via the "normal" way - a view calls a dispatcher, the dispatcher calls our server and dispatches an action with the result, which is then put into the state via a reducer.
Now, I'm creating a view that needs to call the server to get a custom URL based on a few properties. It's not global state at all - since it's just this view that's going to be using it.
It doesn't feel right to call the server from the view directly, but it doesn't feel right to put this data in the global state either.
What is the best practice in these kinds of situations?
You could bypass the "biased standard" here and create an action/lib file to do the fetching for you, and then let the result of that promise (or callback) be the input to the dispatch you will continue with.
From the question you ask, I assume you are going to do this for more than one component? If so, I think that the mentioned approach will suffice.
Further, if you are only doing this for one component, it could be enough to just put that logic in the component, or in a parent container (HoC).