How is this code processed in relation to the way it is written in the redux-devtools documentation?
https://github.com/auth0-blog/redux-auth/blob/master/index.js#L10-L12
let createStoreWithMiddleware = applyMiddleware(thunkMiddleware, api)(createStore)
let store = createStoreWithMiddleware(quotesApp)
I'm not sure how to rewrite this to include DevTools but I did find this GitHub link including a pull request to include DevTools, which I've since gotten working. However, I still do not understand how it is being applied and what's going on with the let something = function(param1,param2)(function). I know that with that syntax the return value of applyMiddleware is being sent to createStore, but the createStore syntax takes a reducer, initialState, and an enhancer. How is this being applied here?
import { createDevTools } from 'redux-devtools'
import LogMonitor from 'redux-devtools-log-monitor'
import DockMonitor from 'redux-devtools-dock-monitor'
const DevTools = createDevTools(
<DockMonitor toggleVisibilityKey="ctrl-h" changePositionKey="ctrl-q">
<LogMonitor theme="tomorrow" preserveScrollTop={false} />
</DockMonitor>
)
let createStoreWithMiddleware = applyMiddleware(thunkMiddleware, api)(createStore)
let store = createStoreWithMiddleware(quotesApp, DevTools.instrument())
The syntax confuses me as opposed to the following syntax from the redux-devtools documentation.
What happens to initialState? In the example there is no reference to initialState anywhere.
The store enhancer definition signature looks roughly like this (snipped from the definition of `applyMiddleware):
export default function applyMiddleware(...middlewares) {
return (createStore) => (reducer, preloadedState, enhancer) => {
// snip actual enhancer logic
return {
...store,
dispatch
}
}
}
So, the enhancer definition actually returns a function that takes a reference to the createStore function itself.
Unfortunately, somehow people seem to have copied that very functional-oriented calling pattern from somewhere, which is really hard to understand. Not sure if it was in an earlier version of the docs, or what. Note that that particular usage pattern doesn't allow defining initialState (or, as it's about to be renamed, preloadedState).
So yes, the current definition pattern, and the one that I think is much more readable, is:
const middlewares = [thunk, myMiddleware];
const middlewareEnhancer = applyMiddleware(...middlewares);
const enhancers = compose(middlewareEnhancer, someOtherEnhancer);
const store = createStore(reducer, preloadedState, enhancers);
Related
This is a topic that's been discussed a lot through github issues and by now I've noticed two main opinions: It's not possible or it should not be done at all.
The argument for both sides is that redux is not meant for it, that the .replaceReducer function is only meant for the purposes of hot-reloading (even though redux itself mentions it as a possibility for code-splitting).
The goal
Anyway, what I would like to achieve (ideally) is a system that only sends the relevant slices and relevant redux code for a specific route in NextJs. And (even more ideally) when navigating between pages the store should just get extended and not re-created.
My initial approach
My first idea was to implement a recipe from the link above, attaching and exposing the injectReducer function onto my store during the store setup:
const store = configureStore({
reducer: {
globals,
[rtkqApi.reducerPath]: rtkqApi.reducer
},
middleware: (getDefaultMiddleware) => getDefaultMiddleware().concat(rtkqApi.middleware)
});
store.dynamicReducers = {};
store.injectDynamicReducer = (name, reducer) => {
if (Object.keys(store.dynamicReducers).includes(name)) {
return;
}
store.dynamicReducers[name] = reducer;
store.replaceReducer(
combineReducers({
globals,
[rtkqApi.reducerPath]: rtkqApi.reducer,
...store.dynamicReducers
})
);
};
const makeStore = () => store;
export const wrapper = createWrapper(makeStore);
export const injectReducer = (sliceName, reducer) => store.injectDynamicReducer(sliceName, reducer);
So basically every page would have a globalsSlice, containing the user info and some other global data, and Redux Toolkit Query API slice (which would then be code-split using RTKQ injectEndpoints functionality).
With this setup, each page that wants to inject its own custom slice (reducer) would do something like this:
const SomePage = () => {
const someData = useSelector(somePageSliceSelectors.selectSomeData);
return (
<Fragment>
<Head>
<title>Some Page</title>
</Head>
</Fragment>
)
};
export default SomeRoute;
injectReducer('somePageSlice', somePageReducer);
export const getServerSideProps = wrapper.getServerSideProps((store) => async (context) => {
// Whatever necessary logic we need
});
Initially this seemed to have worked fine, but then when I realized that next-redux-wrapper works by calling the makeStore factory on every request, and I'm manipulating and mutating a global store object, there has to be something wrong with this, ie a race condition that I haven't been able to cause by testing. Also another problem occurres when using Redux Toolkit Query. For example, if I need to get a cookie from the original request (the one that nextjs receives) and then re-send it to another API endpoint that is handled by redux toolkit query, I would need to extract the cookie from the request context, to which I don't have access unless I do something like this:
export const makeStore = (ctx) => {
return configureStore({
reducer: ...,
middleware: (getDefaultMiddleware) =>
getDefaultMiddleware({
thunk: {
extraArgument: ctx,
},
}).concat(...),
});
};
which further implies that I should definitely not be mutating the global store object.
So then I thought alright, instead of manipulating the global store I could try doing it in GSSP:
export const getServerSideProps = wrapper.getServerSideProps((store) => async (context) => {
store.injectDynamicReducer('somePageSlice', somePageReducer);
});
But no luck here, the slice does not get loaded and the state does not get constructed. It is my guess that the Provider in the _app gets rendered before this, but I'm not sure.
In conclusion, I'd like to know whether anyone has tried and succeeded in implementing redux code splitting using RTK, RTKQ and NextJs. Also, I would like to ask an addition question: Is it necessary? What I mean by this is, if I were to not code-split at all, and send all slices on every request, how performance impactful would this be? Also, since I'm not sure exactly how the NextJs bundler works and how code chunking is done: If a certain page receives a slice it doesn't use at all, will it only receive its initial state or all of its logic (all the selectors, reducers and actions)? If not then maybe this isn't so bad, since initial states are just empty objects.
I hope I've presented the problem clearly enough, as it is a very complex problem, but feel free to ask follow up questions if something doesn't make sense.
Thanks in advance.
I followed the tutorial yet this error isn't being solved](https://i.stack.imgur.com/2qNEF.jpg)
I tried to use {} instead of [] but still the same error occurs
your useContext return null. And you try to destructure null. If you don't provide array in context provider value then you can't write:
const [a1, a2] = ....
So probably you miss match useState
const [state, setState] = useState
with context
const context = useContext(Context)
So. Just write:
const balance = useContext(BalanceContext);
console.log('balance context:',balance)
and then you will see what is in balance context.
if is a object then you have to destructure object.
ps.
quick fix to run project:
const [balance, setBalanace] = useContext(BalanceContext) || [];
// balance and setBalance is undefined
I am reading this page getting into react-redux https://redux.js.org/introduction/getting-started
I am very confused looking at the Basic Example which has 12 lines of code(excluding usage, imports, and comments)
Then I read this line on the "Redux Toolkit Example" which below the code states "Redux Toolkit allows us to write shorter logic that's easier to read, while still following the same Redux behavior and data flow." However, this example is 19 lines of code(excluding usage, imports, and comments)
The usage in both examples is 3 lines of code. Could someone explain this to me?
Perhaps when it scales, the redux toolkit example does save more code? Honestly, I find the Basic Example MUCH easier to read and maintain. NOTE: I am a complete newb which leads me to believe the basic example may be better as we ramp up and hire developers. This allows them to ramp up more quickly(but I am only a single data point amongst newbs)
thanks,
Dean
You're right about the lines of code in the example. Perhaps that simple counter example doesn't do justice to how much code Redux Toolkit can save because they aren't adding all the "bells and whistles" in their non-toolkit version.
This section is called "getting started with Redux" rather than "migrating to Redux Toolkit" so I suspect they don't want to overwhelm the user by introducing best practices like action creator functions which aren't strictly necessary. But you're not seeing the "write less code" benefit because most of the code that you can remove with the Toolkit is coming from things that weren't in the example in first place.
Action Creators
One of the main benefits of the createSlice function is that it automatically creates the action name constants and action creator functions to go along with each case in the reducer.
This example is just dispatching raw actions directly with string names store.dispatch({ type: 'counter/incremented' }). Most devs would not do this because of how fragile and inflexible it is.
An alternate version of the non-toolkit example, what you would see in most code, looks more like this:
// action name constants
const INCREMENTED = 'counter/incremented';
const DECREMENTED = 'counter/decremented';
// action creator functions
// usually most take some arguments
const incremented = () => ({
type: INCREMENTED,
})
const decremented = () => ({
type: DECREMENTED,
})
// reducer function
function counterReducer(state = { value: 0 }, action) {
switch (action.type) {
case INCREMENTED:
return { value: state.value + 1 }
case DECREMENTED:
return { value: state.value - 1 }
default:
return state
}
}
If you want to include typescript types it gets even worse.
Immutability
The reducer itself could get really lengthy if you are trying to do immutable updates on deeply nested data.
Here's an example copied from those docs on how to safely update the property state.first.second[someId].fourth
Without Toolkit
function updateVeryNestedField(state, action) {
return {
...state,
first: {
...state.first,
second: {
...state.first.second,
[action.someId]: {
...state.first.second[action.someId],
fourth: action.someValue
}
}
}
}
}
With Toolkit:
const reducer = createReducer(initialState, {
UPDATE_ITEM: (state, action) => {
state.first.second[action.someId].fourth = action.someValue
}
})
configureStore
The Toolkit configureStore actually does save a step vs the Redux createStore function when you are combining more than one reducer. But again this example fails to show it. Instead the Toolkit version is longer because we set a reducer property rather than just passing the reducer.
A typical Redux app uses the combineReducers utility to combine multiple reducers as properties on an object:
import {createStore, combineReducers} from "redux";
const rootReducer = combineReducers({
counter: counterReducer,
other: otherReducer
});
const vanillaStore = createStore(rootReducer);
With the Toolkit you can just pass your reducers map directly without calling combineReducers.
import {configureStore} from "#reduxjs/toolkit";
const toolkitStore = configureStore({
reducer: {
counter: counterReducer,
other: otherReducer
}
});
Which is roughly the same amount of code. But it also includes some default middleware which would be extra lines in the non-toolkit example.
it's action:
export const someAction = createAction('SOME_ACTION')
Is there a way to fix it?
Invalid number of arguments, expected 0
dispatch(someAction({key: 'val'}))
Okay, I found how, you just need to add function prepare by second argument like this
export const someAction = createAction('SOME_ACTION', prepare)
well, after this the next warn in saga
Unresolved variable type someAction.type
function* watch() {
yield takeLatest(someAction.type, getOneClientWork);
}
OMG!
As for your second problem: Try
function* watch() {
yield takeLatest(someAction, getOneClientWork);
}
But in general, those are TypeScript warnings that come from your IDE applying TypeScript to pure, untyped JavaScript code - in the hopes of giving you better autocompletion and hints. Unfortunatley, stuff like that goes wrong a lot of times.
So if you were writing TypeScript, you'd write
export const someAction = createAction<PayloadType>('SOME_ACTION')
and if you don't do that, it goes back to the default behaviour:
export const someAction = createAction('SOME_ACTION')
// defaults to
export const someAction = createAction<void>('SOME_ACTION')
and would mean "this takes no payload".
Now your IDE blindly applies TypeScript there, uses the default void and you end up with warnings that don't really concern you.
My work is based on these directions: https://redux-observable.js.org/docs/recipes/AddingNewEpicsAsynchronously.html
So I am having an issue with getting this test to execute the epics, am I missing something? In any case the code explains what is going on...
I would expect my call of to store.dispatch({type:'GO'}) to chain all of my epics. I see my reducer is wired up but the Epics do not get called.
fyi I need this to work to test what I think is a bug. In my actual application when I dynamically load a new epic using epicLoader$.next(<someepic>) the dynamically loaded epic is now called twice... but I can't prove that until this test works.
As a workaround I have manually added the epics that I wanted to add dynamically and it is working fine but this isn't possible past my POC phase. I'll need to load the epics from separate files that will be pushed to the app.
Help me Obi wan...
import 'rxjs/add/operator/mergeMap';
import 'rxjs/add/operator/mapTo';
import 'rxjs/add/operator/do';
import { Observable } from 'rxjs/Observable';
import {combineReducers, createStore, applyMiddleware} from 'redux';
import { createEpicMiddleware,combineEpics } from 'redux-observable';
import { BehaviorSubject } from 'rxjs/BehaviorSubject';
test('dynamicly loading epic calls it twice',done => {
let epic1 = (action$)=>action$
.ofType('GO')
.do((action)=>console.log('epic1',action))
.mapTo({type:'EPIC1'});
let epic2 = (action$,{epicLoader$})=>action$
.ofType('EPIC1')
.do((action)=>console.log('epic2',action))
.do(()=>epicLoader$.next(epic3))
.do(()=>epicLoader$.next(epic4))
.mapTo({type:'EPIC2'});
let epic3 = (action$)=>action$
.ofType('EPIC2')
.do((action)=>console.log('epic3',action))
.mapTo({type:'EPIC3'});
let epic4 = (action$)=>action$
.ofType('EPIC2')
.do((action)=>console.log('epic4',action))
.do(()=>done())
.mapTo({type:'EPIC4'});
const epic$ = new BehaviorSubject(combineEpics({epic1,epic2}));
const rootEpic = (action$, store, args) =>
epic$.mergeMap(epic =>
epic(action$, store, args)
);
const epicMiddleware = createEpicMiddleware(rootEpic,
{ dependencies: {
epicLoader$: epic$,
}});
const reducer =(state = {},action)=>{
console.log('reducer',action);
return state;
};
const store = createStore(
combineReducers({
reducer
}),
applyMiddleware(epicMiddleware)
);
//start up the chain of events.
store.dispatch({type:'GO'});
});
I think I see two issues with the provided code:
Providing object to combineEpics instead of just arguments
You're passing an object to combineEpics, but it's supposed to just be plain old arguments. This is different than combineReducers
// bad
const epic$ = new BehaviorSubject(combineEpics({epic1,epic2}));
// good
const epic$ = new BehaviorSubject(combineEpics(epic1,epic2));
Support for passing an object has been discussed here: https://github.com/redux-observable/redux-observable/issues/58. It hasn't been supported yet because the keys would be meaningless, unlike with combineReducers.
This actually does throw an error when the rootEpic is subscribed to, but it's unfortunately swallowed because of a outstanding bug in rxjs
destructuring of store instead of the third dependencies argument
// bad
let epic2 = (action$,{epicLoader$})=>action$
// good
let epic2 = (action$,store,{epicLoader$})=>action$
Once these are fixed, it appears to work as desired:
I did notice that epic4 is listening for EPIC2, which you might have actually meant to listen for EPIC3 maybe?