What I understood from Flux documentation that it recommend re-rendering view for any minor change raised by store. But what if I am using Flux without React that compliments re-rendering complete view by virtual DOM and rendering just diff.
What if I wanted to implement only Flux without React , won’t re-rendering complete view for every dam change in store be performance bottleneck .. ?
Flux does not recommend re-rendering view for minor changed raised by Store, but instead, empowers you to control when your DOM re-renders.
From the Flux Documentation,
The store updates themselves in response to action, but this does not affect the View.
The View updates only when the store emits a change event, which means, Flux gives you total control as to when you wish to update your View.
Also, all the Views do not get updated, only those (controller-views) which listen to specific variable changes inside the Store get updated. This makes your application more performant.
If you wish to follow the same architecture outside React, you can always do that, but it does not mean you will have to update the complete View on all changes inside your store, which implies, it should not become a performance bottleneck.
Your concern is correct: re-rendering the whole view for any state change will destroy your app's performance.
Re-rendering the view works well with React and Flux together because of React's ability to selectively update the DOM. When you change a prop on a component, React rebuilds the entire DOM in memory as a "virtual DOM", without pushing the changes to the actual DOM. Then it applies only the differences between this virtual DOM and the real DOM, making it a very efficient process.
If you want to use Flux without React, you'll need to manage the update process yourself. So, for example, if your state has 50 different values and you change one, you will need to identify the elements associated with that one value and update it accordingly, leaving the others untouched.
Related
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().
I have a question regarding the state management when using redux. the main aim of Redux is to globalize the state of the components so every component in the App can read and update that state.
My question is: When we write React/Redux applications, which design pattern we should use? to define every state in the Redux store? or to only define the states that require to be read by other components in the Redux store, and the rest will be encapsulated inside their relative components?
I think you got my question right? :D
Now, how about components' reusability? doesn't redux make it impossible for the components to be reusable?
& Thank yous 😘
There is no “right” answer for this. There are some Recommendations though -
Some common rules of thumb for determining what kind of data should be put into Redux:
Do other parts of the application care about this data?
Do you need to be able to create further derived data based on this original data?
Is the same data being used to drive multiple components?
Is there value to you in being able to restore this state to a given point - in time (ie, time travel debugging)?
Do you want to cache the data (ie, use what's in state if it's already - there instead of re-requesting it)?
Do you want to keep this data consistent while hot-reloading UI components (which may lose their internal state when swapped)?
From Redux Github -
Question: How to choose between Redux's store and React's state? #1287
dan_abramov - Use React for ephemeral state that doesn't matter to the app globally and doesn't mutate in complex ways. For example, a toggle in some UI element, a form input state. Use Redux for state that matters globally or is mutated in complex ways. For example, cached users, or a post draft.
Sometimes you'll want to move from Redux state to React state (when storing something in Redux gets awkward) or the other way around (when more components need to have access to some state that used to be local).
The rule of thumb is: do whatever is less awkward.
Cheatsheet -
I have a reagent single page application. At the root component, I have a route dispatcher that renders component according to route. Something like:
(defn page []
[(get component-lookup #current-page-name)])
I have a list page and a detail page, where user frequently switches back and forth.
Problem is, switching between these two pages destroys and re-create an entire page worth of components. This slows down page transition noticeably, especially in mobile devices. In contrast, switching from one detail page to another is very fast, as react figured only a few components need to be re-rendered.
My first attempt at optimization is to have both pages rendered all the time, but add display:none whenever they are not visible. This speeds up page transition, but changes the meaning of lifecycle methods. For example, component-did-mount would execute, but the component is not visible and I cannot update its scroll position.
Would there be a better way to do this? Maybe it is possible to unmount a component tree, save it along with its subcomponents and states/virtual dom, to be remounted later with new props?
I don't think you're going to be able to do this without forking react. The lifecycles are inherently tied to modifications to the virtual dom--that's their whole point of existence.
It's a little surprising that the mere rendering of the DOM elements are too slow, unless your page has thousands of dom elements or lots of media. What are you doing during mount? If it is compute intensive, I'd look there to see if you can separate out that logic and cache it so that it is a lightweight process to switch components.
I have been working with Redux for almost a month now. My question is this that I am putting all my app data in the redux store, but should I also put the toggle states that helps me change my UI in redux state or should I simply manage that locally in each page by just doing
this.setState({ showActiveForm : false })
There is no right or wrong answer for this. To help you decide, here are some common rules of thumb taken directly from the redux documentation:
Do other parts of the application care about this data?
Do you need to be able to create further derived data based on this original data?
Is the same data being used to drive multiple components?
Is there value to you in being able to restore this state to a given
point in time (ie, time travel debugging)?
Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?
Another advantage to keeping the majority of your UI state in redux is that you can write more stateless functional components and make use of the performance optimisations they will bring in future versions of React:
This pattern is designed to encourage the creation of these simple components that should comprise large portions of your apps. In the future, we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations.
The current best practice is to use local state to handle the state of your user interface (UI) state rather than data.
Your case is the perfect example of the above. So the state to manage hiding and showing of a component must be within the local state itself and not redux store
Another example of UI data that you could store in local state would be the currently selected tab from a list of options.
A good way to think about when to use local state is to consider whether the value you’re storing will be used by another component. If a value is specific to only a single component, then it’s safe to keep that value in local state.
To elaborate further
Redux is also useful for triggering events for which you need access on multiple components or across multiple routes. An example of this would be a login modal, which can be triggered by a multitude of buttons all across your app. Rather than conditionally rendering a modal in a dozen places, you can conditionally render it at the top-level of your app and use a Redux action to trigger it by changing a value in the store.
Usually, the rule of thumb is that you use a redux store to manage data in your application aka storing items fetched from the server and local react state for ui behaviors, like toggles in your case. But it's not a strict rule, for instance, if you need to toggle something from multiple places it's easier to use redux for that
That depends on how your components are organized. If the state of toggle is used across multiple components then I prefer to manage the state via redux store.
If the the status is local to that component and if it is not used in anywhere else best thing to do would be managing the state within the component. Therefore the component will be self contained.
3 points that i consider when working with react redux
1.keep UI state and transitory data (such as form inputs) in local state.
2.keep data that you intend to share across components in Redux store.
3.Data that you fetch from Server should go to redux store.
So I'm coding in React,
and as far as I understand, every time a user make a local update in a realtime distributed system(such as Firebase, which I'm using) there needs to be a call to update first Firebase, and then if successful, a new object (the old object + the new data we pushed locally) can be sent back from Firebase to the React's Stores and then app will use that object to re-render starting with the top level component of the app.
Yet it feels like my understanding is off because it seems like a complete re-rendering be slow. I think of ajax situations where only the piece that needs to be updated is updated so have smooth updates.
So do I return a whole object and have it re-rendered entirely or just use a success event to go ahead and add that piece of data to the store it belongs to?(which I'm assuming would only cause a re-rending of only the component that is effected by the change?)
In Reactjs, the way to handle this is return the whole object and pass it in to the app the same as for the first response. However, each of your components should implement shouldComponentUpdate to determine whether the new data requires that it update itself. If there's no need, it returns false and that part of the UI does not re-render.
This keeps the app's code simpler since it always does the same thing and you don't have to worry about piecemeal data responses. However the implementations of shouldComponentUpdate can become complex.