I try to implement a customReducer to manage my own custom state in React-Admin. I have looked through the documentation. I can see where to register the reducer in the <Admin>, but I don't see where to really dispatch the reducer to store the state.
I also wish to know how to retrieve my state from the Redux store. What dataProvider is appropriate for this?
Please could someone share a code snippet to do this?
Thanks
First - reducers are not dispatched - probably you have meant actions.
After adding the customReducer you interact with the store in the usual way any redux store is accessed: throught hooks if functional component useSelector() useDispatch() or through the connect HOC in a class component.
Related
I want to be notified if I forget to handle an action type in my reducers. I could make a reducer with a whole list of action types to check against, but that doesn't stop me from forgetting to modify reducers in the first place.
Edit: I am using multiple reducers with combineReducers.
There will always be at least one unhandled action type: INIT. In dev mode, redux will dispatch an action with a random type and also outside of dev mode, you should not act on that action (that is the reason it's random in dev mode).
Really: it is okay to dispatch actions that are not handled by reducers (yet). Actions should describe what is going on in your application, not necessarily be thought of "calling a change in state".
But adding to that: If you write modern redux, it is also pretty uncommon that this happens by accident. You might want to look into modern redux with redux toolkit - the last link is a good start and the official redux essentials tutorial would be a good place to follow up on modern redux patterns.
Also take a look at the redux style guide.
Yes that's is possible. You can throw an error if no action type is matched.
Use this at the end of the reducer function. (but Don't set default type)
throw new Error("Action not matched");
I'm asking for better understanding.
I am now using firebase and firestore as backend for a project. I know it is highly recommended to use a state management library such as redux or mobx as the single source of truth for application state. However, firestore is realtime database, what are the reasons then, to store the real time data from firestore in a state store prior to using in in the application ?
It doesn't matter what is the backend you use. You don't have to use redux and you shouldn't use it unless you need it and that depends on the application size and architecture. Ask yourself those questions:
Will you be able to lift the state up to a shared parent component
between the children that needs the same slice of state !? If yes,
you don't need redux.
Will you have to pass the state many levels down the component tree
until it becomes annoying because a deeply nested component needs it
!? If yes, you may need redux.
From redux website:
In general, use Redux when you have reasonable amounts of data
changing over time, you need a single source of truth, and you find
that approaches like keeping everything in a top-level React
component's state are no longer sufficient.
You can read more about it here: When should you use redux?
I love Redux, but to use it, I have LOTS of additional code scattered all over my application: connect, mapDispatchToProps, mapStateToProps etc etc
It appears to me however that I should be able to both dispatch to the store and get any value from the store via a global window level reference to the store object. If I did this, it would cut alot of code out of my application.
So the question is, what is wrong with this approach? Why NOT do all my Redux disptach and state access via window.store?
I wrote a long Reddit comment a while back about why you should use the React-Redux library instead of writing store code by hand.
Quoting the main part of that answer:
First, while you can manually write the code to subscribe to the Redux store in your React components, there's absolutely no reason to write that code yourself. The wrapper components generated by React-Redux's connect function already have that store subscription logic taken care of for you.
Second, connect does a lot of work to ensure that your actual components only re-render when they actually need to. That includes lots of memoization work, and comparisons against the props from the parent component and the values returned by your mapStateToProps function for that component. By not using connect, you're giving up all those performance improvements, and your components will be unnecessarily re-rendering all the time.
Third, by only connecting your top-level component, you are also causing the rest of your app to re-render unnecessarily. The best performance pattern is to connect lots of components in your app, with each connected component only extracting the pieces of data it actually needs via mapStateToProps. That way, if any other data changes, that component won't re-render.
Fourth, you're manually importing the store into your components, and directly coupling them together, thus making it harder to test the components. I personally try to keep my components "unaware" of Redux. They never reference props.dispatch, but rather call pre-bound action creators like this.props.someFunction(). The component doesn't "know" that it's a Redux action creator - that function could be a callback from a parent component, a bound-up Redux action creator, or a mock function in a test, thus making the component more reusable and testable.
And finally, the vast majority of apps built using React and Redux use the React-Redux library. It's the official way to bind the two together, and doing anything else will just confuse other developers looking at your project.
Also, per the Redux FAQ entry on importing the store directly:
While you can reference your store instance by importing it directly, this is not a recommended pattern in Redux. If you create a store instance and export it from a module, it will become a singleton. This means it will be harder to isolate a Redux app as a component of a larger app, if this is ever necessary, or to enable server rendering, because on the server you want to create separate store instances for every request.
Summarizing all that:
Better performance
Lower coupling via dependency injection of the store
Better testability
Better architecture
I'd also suggest you read through my two-part post The Tao of Redux, Part 1 - Implementation and Intent, and The Tao of Redux, Part 2 - Practice and Philosophy. These two posts discuss the history and intent behind Redux's design, how it's meant to be used, why common usage patterns exist, and other ways that people may use Redux.
I'm building a synthesizer which has a piano-style keyboard UI input.
The keyboard note on/off events can happen quite frequently, these are used to update different parts of the UI and to trigger audio.
What is the frequency threshold which Redux can handle events? For example, if an event occurs 60 times per second which needs to update some aspect of the UI, how would one handle that using Redux patterns ?
I'm fine with doing this event-ing outside of Redux store entirely if Redux doesn't handle this use case.
Redux doesn't have any magic built into it, it's just an immutable state handler, so whatever javascript can do, redux can do.
What you want to take care of are dom operations, and in your case I'm assuming sound operations.
so your optimizations would be more on the react side, not redux.
if you want help with that, share your relevant react code here.
In general, the place to start optimizing react is shouldComponentUpdate
EDIT:
Here are some links I've found that might give some guidance / inspiration:
https://github.com/xjamundx/react-piano
https://github.com/DanielDeychakiwsky/react-piano
Okay so ive been having a hard time understanding middleware and the applyMiddleware in redux and routerMiddleware in react-router-redux. Can some one explain to me what exactly it is in simple terms.
Thank you.
It's just a simple layer, which can transform / validate / logg data after dispatch(someAction(data)) but before handling this action.
Common usages for middlewares is:
redux-thunk - middleware for handling async actions
redux-logger - Logging middleware for each action dispatch
You also can validate / prevent some actions if they are wrong or not acceptable in current state
You can transform some data before handling it in action
You can make some additional requests there, to mix it with dispatched data, but it's a bad practice
You can imagine some other use cases, if you need to do something after each dispatch. For example you can store copies of your current store/state, to be able to revert data in future.