So I need to implement this function that checks the Redux variable in interval, say 5 seconds. My issue is that this variable is the content of a large, editable text; so subscribing to it normally causes app lags (because every typed letter is a variable's change).
Does anyone have an idea how to overcome it? I can post some code if you want, I just thought it's rather a theoretical problem..
Maybe I can render this component just every 5 seconds to avoid it being connected constantly?
Related
Webpack has an option that is called aggregateTimeout, this is explained as:
aggregate any other changes made during this time period into one rebuild
So the idea is, how can I bundle multiple changes within time period e.g. 1 second; to a single state update?
For example I have an editor in my react app, it updates the state each time the user types text on the editor, but I found that it makes the app a little laggy. So I want a timeout that ignores text inputs within, let's say 500ms, and it only updates after 500ms passed since the last time the user did text input.
How can I implement something like the case? Thanks.
In React: Does changing state n times also triggering render n times too?
Is there any way to ignore some state changing based on the max browser fps rate?
I'm not sure using useTransition. It seem on experimental stage.
I recommend reading this article about batch update if you mean by different state object changes. But basically, no. It doesn't guarantees triggering render n times following state change.
As for limiting it using browser fps rate - it's an interesting question. I guess it can be implemented using requestAnimationFrame the way libraries like use-debounce are implemented
You are right that there are too much words. The only remaining question now is:
Why is it considered to be normal to fetch data in cDM method if it is called after rendering and will cause an extra re-rendering and re-drawing after data has been fetched? More to it - user will see screen flickering.
I've spent two hours reading SO and other articles and still have questions. I'd like to get a better grasp of things and reassure them that my understanding is correct.
It all started with learning hooks and thinking about the difference between useEffect and useLayoutEffect. I learnt that useEffect should be used when things which it does don't affect what is shown to user (some background job) and useLayoutEffect is fired "synchronously before painting" - so, for example, should be used when I want to show a list on screen and data for it is fetched form somewhere else. Thus, if I fetch data in useLayoutEffect it will fetch the data first, and only after that update state and show the screen with that data to the user. If I used useEffect it would show to the user an empty list first (because it is asynchronous and doesn't stop painting) and then re-paint it after data is received. Confusing part is that it says that useLayoutEffect, the same as useEffect, is called after the rendering has finished. I explain why it doesn't make any sense to me in the last paragraph.
Another confusing thing is that it says that useEffect should be used in the same place where cDM or cDU methods are called. But I've been fetching data in cDM method since I started using react.
Does it mean that I did it wrong all the time? Because I should have done it where useLayoutEffect is fired. And this brings me to the next paragraph.
The most confusing thing - a relationship between rendering, painting and cDM method. It says that cDM is called after the rendering has finished. It also says that "rendering has finished" means that DOM, layout, sizes, styles - everything is calculated and ready to be painted by the browser. I understand it in a way that at this point it makes no sense to do anything that would change what is shown to a user - because it is all already calculated! Shouldn't there be a hook that is called before rendering? For example, I call this hook to fetch data for some list which is shown on screen. Only after data is fetched rendering should occur because now react knows how many elements are on the list and how much space will it take and so on. I mean what's a point in making rendering before you know all your data? Isn't react forced to recalculate everything after data is fetched?
I really hope you will help me to understand these things. Thank you.
I have two context types: (1) productsContexts & (2) rangeContext.
rangeContext is nothing more than preset ranges from a json file so as to group the products according to each respective range.
Below is an illustration of a side-box component that groups products
according to those preset ranges and it also illustrates the problem:
The first visit to that page, everything works fine, but click off and then re-visit the page and the previous data remains and then doubles itself, 3rd time, it is triple, and so on.
I did nothing with the rangeContext data but pass it along to a local variable for mapping data manipulation. I did not save anything to the context itself.
Here is what I have tried to do to solve this problem; all have failed:
I passed the rangeContext to state first, then on componentWillUnmount, I initialized state.
I Object.assign() the rangeContext to the local variable instead of directly passing the context to the local variable.
I took the context completely out of this component and used it in it's parent, and passed it to this component as props.
Nothing is working. While the hard data does not change, the range component never gets initialized on unmount and revisiting the page just carries forward what was in the range in the last visit and adds to it.
I know I probably did not do a great job explaining, but I know the problem is related to the context and I sure do not want to hit the database again, as I already did that for an earlier component.
Does anyone recognize the problem and have a solution?
Thanks
UPDATE:
I moved contextTypes for ranges out of the side-box component.
Using redux flux, I dispatched for the range-actions in side-box's parent and passed the ranges to side-box as props. The problem went away, but I am not happy. I need someone to tell me why this is the right things to do, as ...
I had already called range-actions in a previous component, so why not put it in contextTypes instead of calling redux again?
Where as I only had 3 lines of code on side box, I have the same amount of code lines since now I am calling propTypes, but now I also have
MORE LINES of code in the parent calling redux, something I had already done for the range data in a previous component.
I would greatly appreciate someone telling me if I am still doing this
all wrong, or why it is right I had to add 26 more REDUNDANT lines of
code calling redux flux?
I have an application which receives messages from a server every 1 second and via socket.io these messages are broadcast to a react component.
My react component is using a flux style architecture, so it calls an action when a message is received which adds (or updates) a record in a collection in a store.
My component monitors changes on the store and then updates the UI when it changes. In this case, it draws a marker on a map.
The problem is that due to the frequency of the updates my component redraws all markers every second, which I don't want.
I'm looking for an approach to allow my map component to respond to changes in a collection in a store, but not have the state update every second.
I thought I could have a collection for the raw data, and then only update the networkGPS collection selectively in my store, but the component seems to change based on any property in the store as they all seem to be part of its state.
In summary I'm looking to:
Collect data every 1 second in raw form and add this data to a store.
Bind a component to a collection in this store which I update only when changes require a UI redraw.
What I think I need to do:
Either:
Avoid putting the raw data into the state of the store (at the moment I'm unsure how to declare a collection which is not part of the state)
OR
Make my component more clever as to when it redraws, so it doesn't try to redraw on each state change.
I'm not sure which is the most appropriate solution for the problem, any info would be gratefully receieved.
Sorry if the question is a little unclear, I'm new to react / flux. Please do ask for any clarifications.
EDIT
At the moment I am getting round this issue by storing an array of the items (map markers in this example) I want my component to display in the component itself :(
When the state changes and render is called, I intercept the state properties, decide if anything needs to change in the collection of markers and only amend them if needed. If no changes are needed, the collection in the component stays the same and no redraw is performed.
This is not ideal, I feel like I should be able to allow my component to respond to only specific state changes but I've not found it yet, still looking for a better answer.
There are a couple of ways to approach this:
1) Use shouldComponentUpdate to compare old props and new props, re-rendering only the new marker states.
2) Switch to a cursor-based state tree that automatically triggers renders only for views that are bound to the specific parts of the state tree that have changed. I believe Baobab is one such library. See also Om (written in ClojureScript) and probably a number of other Flux implementations.
Given the impact of #2 my vote would be to go the route of #1.
I am not quite sure what's the problem that you face with updates every second.
However, the one place where you can queue the updates is between the socket.io and calling the action.
Instead of calling the action every second, you could queue the updates before sending it across to react.