When I've been developing in pure React.js, I was used to store some data into Redux and set some component to listen to changes in Redux (with useSelector (source). But now I am doing facing the same problem but in different technology. In Remix there's no useSelector with Redux. Yes there is possible to use useState but it have to be under one parent compopnent but I don't have this structure. So is there any solution to force component to re-render when some independent state changes?
Thanks
I've tried to call some function to force re-render but that's not 'nice' solution. I've even thinked about storying data into localStorage/cookies but when they change, components doesn't update (I understand why it doesn't force re-render but I've tried it...).
Redux should still work normally even with Remix, as it's just a state manager. It's entirely possible that all you have is a configuration issue with Redux (I personally dislike Redux for how needlessly complex it into use)
You could try React's own Context for storing state that could be used by several components. Other proven state managers are the likes of jotai or zustand.
Even regular state could work because there's always a root component in remix: i.e. root.tsx.
It's hard to understand what you're trying to achieve. Other ways to update various parts of the UI is using nested routes and . You can access parent and child page data with useLoaderData().
Related
My application depends mainly on one async method: my get-all-images function. And my app have like some components that will affect this method (ex: there's a search button on header, a add component, and a delete component). And I want to know what's the best way to make this function run again. ContextAPI?
This a is schetch of my app:
I think if the app is simple, it would be faster to do with useContext React Hook. You just put your state and setState in there, and then, get them in whatever component you need. But when your application gets bigger, it's getting hard to track the state and where it is updating. For that reason, there is Redux.
Usually when you have this scenario, a common approach is using what you said, a React ContextAPI, with this you can correlate the components into the main state aid avoiding multiple re-renders with passing props.
Another approach, since your project need to have this "brain state" is to use solutions like recoil , redux or mobx to create a flux architecture inside of it and manage better how the components handle each state.
I am building a web app where redux is configured and app is fairly large.
Now I want to store some user preferences which will be available as part of an API respopse.
As this data is required to the majority of components I am planning to store data in the context and wrap application using the context.
I have Few questions regarding approach.
Will considering context impact the performance?
As Redux is already configured which internally uses the Context. So should we continue to use redux for user data.
Is it good practice to use Redux and Context together.
Context and Redux are very different tools that solve different problems, with some overlap.
Context is not a "state management" tool. It's a Dependency Injection mechanism, whose only purpose is to make a single value accessible to a nested tree of React components. It's up to you to decide what that value is, and how it's created. Typically, that's done using data from React component state, ie, useState and useReducer. So, you're actually doing all the "state management" yourself - Context just gives you a way to pass it down the tree.
Redux is a library and a pattern for separating your state update logic from the rest of your app, and making it easy to trace when/where/why/how your state has changed. It also gives your whole app the ability to access any piece of state in any component.
In addition, there are some distinct differences between how Context and (React-)Redux pass along updates. Context has some major perf limitations - in particular, any component that consumes a context will be forced to re-render, even if it only cares about part of the context value.
So, yes, you can use them both in the same app, in the same way you can use a hammer and a screwdriver together on the same construction job.
For more details, see my posts:
Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux)
React, Redux, and Context Behavior
A (Mostly) Complete Guide to React Rendering Behavior
Will considering context impact the performance?
Since you want to share user preferences that (I guess) do not change often, you could use a React context to share that data.
But performance issues arise when you put multiple different data in one React context that update at different rates. This is because every component that uses the context will be rerendered even if the part of the context it is interessted in did not change. In this case you can split the context and use one context for each part of the data.
Since you want to use the context to share an application state, you should use Redux. In Redux you use selectors to select a part of the application state. This useSelector hook is implemented in a way that it only triggers a rerender of the component if the selected part changes. You can even pass it an equality function if you want to change the way state change is detected.
As Redux is already configured which internally uses the Context. So should we continue to use redux for user data.
I would say: yes, continue with Redux.
Since you already use Redux you should not spread your application state management over different concepts. Put the user settings in the Redux store (like any other application state) and don't handle them special.
Is it good practice to use Redux and Context together
Well, Redux is based on the React context. So if you use Redux it is already a good practice.
If you mean using both for application state management, I think you should go the Redux or the React context way. Mixing them makes it harder to understand where state is managed.
**Is it OK to Using a component state for just to handling form data, while the main data and other stuff of the application will be stored in the Redux store?
I don't want to use redux-form instead manually dispatch it to the reducers**
Redux comes into the picture when we want to manage the state across different component. It provides a centralize store where state of all the components are managed.
When talking about forms, in most cases form data is only limited to the component is which is being used. So, in that type of scenario there is no need to link them to centralized store using redux. A simple way is to store them in the component state and get it processed. Afterwards, you can store the output of that in redux store according to your needs.
It is okay to do that. You can keep a local state in the component. state = {} in class components, const [localState, setLocalState] = useState() for functional components.
Or you can use custom hooks for handling your local state needs. Check out useInput or useForm custom hooks that are developed by the community.
Yes of course. Some things go best in component state, some go best in a parent component, some go in Context, and some go in Redux. There is little use in putting everything in Redux, it just causes a lot of boilerplate and every component tries to update when the store changes.
You put things in Redux when different components that are at different places in the HTML tree use the same data, and it changes during the app's lifetime (things like the user's language don't change often and go in Context). You use it when you want to store your app's state to restore it later (which exact menus are currently open or closed is usually not that important) and when you want to keep track of state changing using the Redux dev tools.
I have a component which has some local state (form validation error messages). This component does not get its state from a parent, nor does it passes these values to any of its children.
My application uses Redux for global state management. Should I push this state to be managed via Redux, or keep using local state for this particular component.
The simple answer is NO. -Simply because you already have all the necessary data in the only relevant component where you're actually using it.
Redux (react-redux) is used for app level state management.
So, here comes the longer answer -If you at some point decide that you need the data in various components and also that they need/ should be accessible at any point, Redux is definitely a great option.
It all really depends on the amount of data and the need for effectively passing the data throughout the entire app.
On the other hand, if you only have to pass data between Parent - Children components, Redux could be an overkill, because you can still achieve it using just React by passing (exchange) values between various components via props.
So, if you only need that data inside only that component (Component level state), Redux it's a no-go because it's pretty large and it wouldn't be of any use for your case.
Sounds like the data is only needed for this component, so you don't need to push it to the Redux state.
Yes, if you take the way of an immutable state and connected components and you would avoid unecessary re-render.
In this case, you can connect your field to it's state, and rerender the error message only when an error occur.
I would not save this to Redux state.
Unless you require this data elsewhere.
I've been learning Redux and a part I'm unclear of is, how do I make a determination between using react state vs redux store and then dispatching actions. from my reading so far it looks like I could use React state in place of Redux store and still get things done. I understand the separation of concerns with using Redux store and just having 1 container component and the rest of it as stateless component but how do I make the determination of when to use React state Vs redux store is not very clear to me. Can someone please help?
Thanks!
If the state doesn't need to be shared with other components, or the state doesn't need to be keep when the component is unmounted, then you can just put it in the component's state.
You can think that the Redux store is the database of front-end, if you have something like product data fetched from an API, then the Redux store is the right place; if you have a dropdown component, which takes a isOpen prop, then the parent of that dropdown can just keep dropdownIsOpen as a component state.
For more information, here is the answer from Dan: https://github.com/reactjs/redux/issues/1287
Also you said
only 1 container component and the rest of it as stateless component
This is incorrect. You can have several container components. A container component can also contain another container component.
From book:
First of all, we should always keep in mind that only the minimal
amount of data needed should be put into the state. For example, if we
have to change a label when a button is clicked we should not store
the text of the label, but we should only save a Boolean flag that
tells us if the button has been clicked or not. Secondly, we should
add to the state only the values that we want to update when an event
happens, and for which we want to make the component re-render.
Another way to figure out whether the state is the right place to
store information is to check if the data we are persisting is needed
outside the component itself or by its children. If multiple
components need to keep track of the same information, we should
consider using a state manager like Redux at the application level.
There are a few things that need to be grasp
State of component: If you want to keep state-specific to your HOC then use state. Now in the function component, we use useState.
State of redux: If you want to share data throughout the application use redux state.
Store of redux: It's nothing but a database for the redux library. In the case of redux, we can have only one store. To use multiple stores we can use Flux but it will make things more complicated.
You're absolutely right. Redux (and flux architecture in general) are only formalism tools to help for building large apps. They're not necessary at all.
There's actually an interesting post called You might not need redux by Dan Abramov, the creator of redux that might give you a better answer than I do: https://medium.com/#dan_abramov/you-might-not-need-redux-be46360cf367#.7093fm1z8
If state is needed only for that particular component then prefer to use react state.
For example using state for UI actions
If any state you want to use across the component/project then go with redux state.
For example API response data etc
For detail understanding refer this link
https://spin.atomicobject.com/2017/06/07/react-state-vs-redux-state/