I have a reducer whereby I am retuning the appropriate state when an action is dispatched. Now I am calling an API at regular intervals so the result will trigger an action again and again. So what I want is that if the reducer state already has data then another reducer doesn't show the state as loading while the call is sent. It must maintain its loading state when receiving data the first time only. I hope I am able to explain it properly
Here are my code snippets
Loading state reducer
const loading = (state = false, action) => {
switch (action.type) {
case 'GET_AUDIT_DATA': // here I want to return true only when there is no data available
return true
case 'GET_AUDIT_DATA_RECEIVED':
return false
case 'GET_AUDIT_DATA_ERROR':
return false
default:
return state
}
}
Combining reducers
const allReducers = combineReducers({
auditData: AuditData,
auditLoading: AuditLoading,
modifiedOrders: ModifiedOrders
});
export default allReducers;
Reducer returning data on action triggered by superagent
const auditData = (state = [], action) => {
switch(action.type) {
case 'GET_AUDIT_DATA_RECEIVED':
console.log(action.data);
return action.data;
case 'GET_AUDIT_DATA_ERROR':
return action.err;
default :
return state;
}
}
export default auditData;
So initially the auditData doesn't contain any data, only after the first success call it returns the data. When this is called at the same time loading state reducer is called and it should return true in GET_AUDIT_DATA action only when the audit data reducer doesn't contain any data.
Also is returning just the current obtained data from auditData the right way to go or I should do it differently. Basically I want to overwrite the current data with the new one.
You can call getState() over a store to get the list of reducers and the current state inside the reducers.
Import the store into auditLoading (use store to get values. Don't mutate the store)
store.getState().auditLoading will give you the state of auditLoading reducer.
This approach is similar to the callback provided by redux-thunk. In which (dispatch, getState) => {} will be returned to the action.
The best way to proceed is to send to Loading state reducer an information to know if the other reducer already have data. To have at the end:
const loading = (state = false, action) => {
switch (action.type) {
case 'GET_AUDIT_DATA':
if(!action.dataAlreadyInitialized){
return true
}
case 'GET_AUDIT_DATA_RECEIVED':
return false
case 'GET_AUDIT_DATA_ERROR':
return false
default:
return state
}
}
You should have access from your action function to the application state and do:
dispatch({
type:'GET_AUDIT_DATA',
dataAlreadyInitialized: appState.auditData.length > 0
});
The accepted answer is fine (pass in the data length through the action) but can get laborious if it's a piece of information that is widely used. There is another solution that is sometimes preferable for something like 'current user' that might be used by every action.
According to the Redux FAQ https://redux.js.org/faq/reducers it is perfectly acceptable to add a third argument to the reducer function. I.e.:
Loading state reducer
const loading = (state = false, action, noData) => {
switch (action.type) {
case 'GET_AUDIT_DATA':
return noData
case 'GET_AUDIT_DATA_RECEIVED':
return false
case 'GET_AUDIT_DATA_ERROR':
return false
default:
return state
}
}
Combining reducers
Unfortunately it means we have to write code to combine the reducers, rather than use the combineReducers shortcut. But it's not too hard, you just call each reducer and create a new object if anything changed:
const allReducers = (state = null, action) => {
const auditData = AuditData(state?.auditData, action);
const auditLoading = AuditLoading(state?.auditLoading, action, !state?.auditData?.length);
const modifiedOrders = ModifiedOrders(state?.modifiedOrders, action);
return (auditData !== state?.auditData ||
auditLoading !== state?.auditLoading ||
modifiedOrders !== state?.modifiedOrders) ?
{ auditData, auditLoading, modifiedOrders } : state;
});
export default allReducers;
Notice the third argument passed to the AuditLoading reducer. No change is required to the other reducers, or to the code that invokes the action. Which is nice!
import store from '../../../redux/store'
console.log(store.getState().loginReducer.accessToken)
Through this statement we will get state of accessToken
Related
After processing the action that comes to the reducer function, i change the type of action according to the operation i do. Would it be a problem if we think that the reducer functions should be pure? To ensure that the reducer function does not grow, and that the incoming data makes the excess change on the state once.
a simple example showing what i mean:
const lineReducer = (state = [], action) => {
switch (action.type) {
case 'ADD_LINE':
action.type = 'INC';
return [...state,action.payload];
case 'UPDATE_LINE':
return state.map(vehicle => vehicle);
case 'TAKE_VEHICLE_IN_LINE':
action.type = 'DEC';
return state.filter(vehicle => vehicle.id !== action.payload);
default:
return state;
}
}
const lineStatsReducer = (state = 0, action) => {
switch (action.type) {
case 'INC':
return state + 1;
case 'DEC':
return state - 1;
default:
return state;
}
}
compineReducer({
line: lineReducer,
stats: lineStatsReducer
});
In this way, my component, which deals with the number of vehicles, is not rendered whenever vehicle data comes.
Yeah, definitely do not mutate action objects like that. It goes against the principle that reducers are supposed to be pure functions, and it's also going to make it a lot harder to trace how and why state is actually updating.
Instead, you should have both reducers listening to the same action type, and independently updating their state appropriately in response. This is easier if you model actions as "events" conceptually.
I have seen 3 forms of reducers:
// Form 1
function reducer(state, action) {
if (state === undefined)
return state = [];
// handle action.type
// ...
}
// Form 2
function reducer(state, action) {
if (state === undefined)
state = [];
// handle action.type
// ...
}
// Form 3
function reducer(state = [], action) {
// handle action.type
// ...
}
Are they all the same? Form 1 and Form 2 differ by Form 1 immediately returning the initial state without looking at and taking care of action.type at all.
And I think Form 2 and Form 3 are exactly the same, using default parameter value.
Can any claim be substantiated by any official docs or specs? It think it means, the very first time a reducer is called, action.type won't be anything meaningful.
In a Redux reducer, if state is not defined, can you immediately return the initial state?
yes, we can.
But for this, you don't need to check for undefined or any other non-empty check.
switch default statement will handled it very smoothly.
function reducer(state, action) {
switch(action.type){
//rest case
default:
return state;
}
}
// Form 2
function reducer(state, action) {
switch(action.type){
//rest case
default:
return state;
}
}
Redux initializes it dispatches a "dummy" action to fill the state. Please check this docs
Reducers are not allowed to return undefined under any condition, It can return null if necessary
Technically all three are same, as first time the reducers will called with dummy, state is no longer undefined at Form 1. On subsequent call, it will be called with meaningful action from your application code and as state = [] at that time, it will check the action.type
You may simply use: createReducer from redux-starter-kit
Which is also been used in this demo from microsoft
A utility function that allows defining a reducer as a mapping from action type to case reducer functions that handle these action types. The reducer's initial state is passed as the first argument.
The body of every case reducer is implicitly wrapped with a call to produce() from the immer library. This means that rather than returning a new state object, you can also mutate the passed-in state object directly; these mutations will then be automatically and efficiently translated into copies, giving you both convenience and immutability.
#param initialState — The initial state to be returned by the reducer.
#param actionsMap — A mapping from action types to action-type-specific case redeucers.
Usage
export const LocalStorageReducer = createReducer<Store['localStorage']>(
new LocalStorage(), // <= where you define the init value of this state
{
storeLocalStorageInput(state, action) {
return state = {...state, [action.payload.item]: action.payload.value};
},
clearLocalStorageInput(state, action) {
return state = new LocalStorage();
},
}
);
export const reducer = combineReducers({
localStorage: LocalStorageReducer,
...
type of createReducer
(alias) createReducer<LocalStorage, CaseReducers<LocalStorage, any>>(initialState: LocalStorage, actionsMap: CaseReducers<LocalStorage, any>): Reducer<LocalStorage, AnyAction>
import createReducer
sample of state
export class LocalStorage {
/**
* Editing plan id in planner pages
*/
planId: string | undefined;
/***
* Touched id list
*/
touchedIdList: Array<string>;
constructor() {
this.planId = undefined;
this.touchedIdList = Array<string>();
}
}
There are already developed methods to do those things by libs, no need to manually do it again in most situation.
I have some experience working with React and Redux
Frankly, Till now, i have been usually just copying-pasting the code without comprehending what is happening.
I was thinking about how reducer works (while trying Vuex) and that lead me to following question
import {
MEETUP_GROUP_DATA_SUCCESS,
MEETUP_GROUP_DATA_LOADING,
MEETUP_GROUP_DATA_ERROR,
GOOGLE_PROFILE_LOGOUT
} from "./../config/type.js"
const intialState = {
meetupProfileData: null,
meetupProfileLoading: null,
meetupProfileError: null,
}
export default function (state = intialState, action) {
switch (action.type) {
case MEETUP_GROUP_DATA_LOADING:
return {
...state,
meetupProfileLoading: true
}
case MEETUP_GROUP_DATA_SUCCESS:
return {
...state,
meetupProfileLoading: false,
meetupProfileError: false,
meetupProfileData: action.payload,
}
case MEETUP_GROUP_DATA_ERROR:
return {
...state,
meetupProfileLoading: false,
meetupProfileError: action.payload,
}
case GOOGLE_PROFILE_LOGOUT:
return {
...state,
meetupProfileLoading: null,
meetupProfileError: null,
meetupProfileData: null,
}
default:
return state
}
}
Here notice our const intitalState
Now, Suppose an action is dispatched. This will make redux call this function
export default function (state = intialState, action) {
Here our state is equal to initialState. So every-time we dispatch an action our state should be equal to intialState? since we are saying state = intialState
So what is the use of ...state here? If you are going to answer by saying that it makes copy of previous state then please mention how would our state have copy of previous state because every time an action is being dispatched our state is being equal to initial state and our initial state have all the parameters as null
The parameter state = initialState means that state defaults to initialState, if it was not provided. Redux will call your reducers once in the beginning to "initialize" your state, meaning it will call your reducer with null or undefined. Since you're setting the state to initialState in this case and returning that, Redux will receive the initial state you've set up.
All subsequent calls will use the new state - so when your reducer receives an action that will change something, you need to return the whole state again with the relevant updates.
Returning { ...state, somethingToUpdate: "foo" } means you're essentially copying the state variable into a new object, overwriting the somethingToUpdate key with "foo".
Basically, Redux only calls your reducers and if your reducer receives an action it does not care about, it needs to return the current state. If you happen to return nothing (maybe forgot to add the default: return state in the switch), the state gets undefined again and will reset to the initialState due to the default parameter provided in the function signature (state = initialState).
This statement
export default function (state = intialState, action) { }
says initialize it with intialState for the first time.
...state
Is like copy state and after that we are changing values while returning state/object.
In redux store I have set initial state to some value as shown below:
const search_initial_state = {
FilterItem:18
}
I am changing this state value in another function manually
But after click on reset button I want to set "FilterItem" state to it's initial value.(i.e. 18)
If i understood you correctly, you want to reset only one value to its original/initial value.
Define an action creator that dispatches action type of RESET_FILTER_ITEM and then whenever you want to reset filter item dispatch this action.
const resetFilterItem = () {
return {
type: "RESET_FILTER_ITEM"
}
}
and your reducer will look like this after implementing reset case
const myReducer = (state = initialState, action) => {
switch(action.type){
case "OTHER_CASE":
return {...state}
case "RESET_FILTER_ITEM":
return {
...state,
FilterItem: initialState.FilterItem
}
default:
return state
}
}
Hope this will help you.
Reducers will update their state when an action has been dispatched for them to process. So likewise, you have to dispatch an action that tells your reducer to return the initial state.
//Reducer code
const initialState = {}
const myReducer = (state = initialState, action) => {
switch(action.type){
case "FILTER_ITEM":
return {...someUpdatedState}
case "RESET_ITEM":
return initialState
default:
return state
}
}
Your reducer will return a new state depending on the action type.
So just define an action creator that dispatches action type of RESET_ITEM or something else you may want to call it. Then use it when you want to reset.
const resetItem = () => {
return {
type: "RESET_ITEM"
}
}
I am using react-redux (for the first time). I have a component into which users put a 'startDate' and an 'endDate'. These should then be stored in the redux store, so that they persist.
I have the following action creator:
export const setDates = dates => ({
type: "SET_DATES",
payload: dates
});
The following reducer:
const dates = (state = {}, action) => {
switch (action.type) {
case "SET_DATES":
return action.payload;
default:
return state;
}
};
export default dates;
The state is set conditionally (i.e. only if the start and end dates actually make sense) like this:
handleSubmit = () => {
if (this.state.startDate <= this.state.endDate) {
store.dispatch(setDates([this.state.startDate, this.state.endDate]));
window.location = `/search/${
this.state.location
}&${this.state.startDate.format("DDMMYYYY")}&${this.state.endDate.format(
"DDMMYYYY"
)}&${this.state.guestCount}&${this.state.offset}&${this.state.count}`;
} else {
console.log("HANDLE ERROR");
}
};
The problem, according to the chrome redux dev-tools, is that when the submit is triggered, the store does indeed change to the new dates, but it then seems to be immediately overwritten to the empty state. By modifying the reducer to take state = {dates: 'foo'} as its first argument, I can get the store to persist 'dates:foo'. This suggests to me that, for some reason, the reducer is being called twice - once with an action of type "SET_DATES", which works, and then again, immediately, with an action of unknown type (confirmed by console.log-ging action.type), which causes it to return the default state.
So I'm pretty sure I know what the problem is, but I have no idea why it would do this.
I Already commented, but anyways. The problem is that you reload the page. It reloads redux, and it boots up from initial state, which is probably an empty array. Here is a great video from one of the brains behind redux.
https://egghead.io/lessons/javascript-redux-persisting-the-state-to-the-local-storage
It all boils down to subscribing to the store state changes, and saving it / loading the state back from storage of your choise.
Try changing you reducer like this
const dates = (state = {}, action) => {
switch (action.type) {
case "SET_DATES":
return Object.assign({}, state, {
action.payload
});
default:
return state;
}
};
export default dates;