So far I am loving React, but there is one part of my application (and unfortunately a crucial part) that I have hit a bit of a hiccup with.
When an item mounts or flushes updates to the dom, I need to do specific checks around the finalized HTML before I continue (for example, if the component's dom nodes are overflowing the container I need to move it to the next container).
The problem with this is shouldComponentUpdate is called for all of them before any of them have componentDidUpdate. This means I have to wait until all components flush to the dom, before I iterate through them in order to calculate from top to bottom if they overflow their outer container, and if so I need to change some things up causing all components after that one to be forced to update.
For example if my parent has 20 components and the 3rd component overflows, I have to wait until all 20 components are flushed to the dom before I move the latter 17 components to the next container, just to repeat until all components fit inside their containers.
What I would love to happen is that the first component flushes, I check if it overflows, then the 2nd component flushes, then I check if it overflows, etc... That will drastically decrease how much is flushing to the dom.
Is this at all possible with Reaact?
If you are curious on the why behind this question, you can see this question
No, it's not possible to directly cause React to sequentially call shouldComponentUpdate between component DOM flushes. In fact, that could dramatically and negatively affect the performance gains often realized by new React code by flushing all DOM changes between each call.
Instead, I believe you'll need to move to a model where a container component iteratively renders the children components either on- or off-screen and then lays out the children appropriately. The parent component would need to use the callback componentDidUpdate to measure children after they have rendered. Then, using setState for example, trigger the addition of a new child until the loop was complete. Eventually, all children will be rendered. This technique should operate relatively quickly and isolates the DOM and measuring of components as much as possible (rather than impacting the entire page for example). If you could render the children to an off-screen component/DOM element for measurements, it may be slightly faster. In fact, if you could render all the children off-screen in a single pass for measurements, that might be ideal.
Related
This question was asked manier times whenever we change a dom , like
Method 1 :
document.getElementByID('root')="hello"; even for changing one dom element , the browser rerenders the whole dom and state of the other elements like input text boxes will be lost, and recomputes styling and layouts (.ie reflows and repaints )
It is fine till now.
Method 2:
What react does is it keeps a virtual dom which is a copy of real dom, whenever a state changes, it rerenders entire new vdom in memory and does diffing and identifies which nodes to be updated in real-dom and react updates only that part in real-dom ,thus saving time not re-rendering entire dom.
My Question is at the end of the day either we update the realdom using method 1 or by using a vdom , finally dom is getting updated which in turn should make the browser compute the whole layout and styles again, why people say it helps to update only some part of the UI?
** Please kindly refrain from answering the same diffing concept, vdom concept, updating the required parts concept,or repaint and reflow process i.e dom tree css tree and rendering engine etc...**
# My question is how vdom can stop browser repainting and reflowing when ultimately dom is getting updated which in turn makes reflow and repaint whole tree?
picture about what I am trying to ask:
Ignore my grammar, and correct me where ever I am wrong at concepts of dom, vdom, repaint and reflow.
VDom will generally not save you any repaints/reflows compared to well-written DOM manipulation.
The main benefit of it is that it that it allows for a declarative component API. You describe what the component is, and React figures out how to render it efficiently without re-generating extraneous DOM elements. The html changes will generally be smaller using this approach.
Performance benefits here are somewhat of a red-herring. Yes, Reacts vdom has optimizations such as batching renders, but these are optimizations for the vdom, not for the browser. Browser DOM operations are already very fast.
I have a situation where I can have a lot of forms, thus a lot of components to render.
So, I'm using memo to try to avoid re-rendering everything every time.
I pass the index to each of my child component.
When prepending, all the elements see their index doing +1 and thus, they all re-render again and again. Is there a way to avoid that ?
Here in the picture, all the element in the form 30 re-rendered, and I want to avoid that (pretty slow when all the teeth are selected)
I have create a React component that renders it's children into grid markup. Since the component is stateless and the grid markup will never change, is it ok to return false from shouldComponentUpdate?
My only concern that I of course don't want to prevent the children from re-rendering but only the grid component.
Stop renders at the source using shouldComponentUpdate
Take a look at this nested Component structure:
By default, if an Update is triggered in A, then all the other children will also go through their updates. This can easily cause a performance issue, because now we have many Components going through each step of the process.+
By adding logic checks in shouldComponentUpdate() at A we can prevent all its children from re-rendering. This can improve overall performance significantly. But keep in mind, if you prevent A from passing props down to the children you may prevent required renders from occurring.
So, Answering your question, if you prevent element A from re-render it will cause a cascade effect and will affect your grid component.
I have a large React component with scrollbars. I'd like to make some small changes to a few components when it scrolls (basically to keep the left-most column of a table stuck to the left side of the screen).
Normally I'd pass props indicating the component's scroll position down to the components that need to update when it scrolls, but re-rendering the whole component when it scrolls makes the whole thing massively laggy. But the whole thing doesn't really need to be re-rendered -- only a few small parts of it to make sure they stay in the right part of the screen
Is there a good way to re-render only a small part of a component, or is there another way of dealing with frequent updates to large components like this?
Implementation might get a bit hairy but have you had a look into shouldComponentUpdate? (docs)
You could probably track the scrolling and use it to skip updating on the pieces you don't want to update - eg. pass an isScrolling prop to some children and skip update if it's true, or only update if the scoll distance has changed by a certain amount or a certain amount of time has passed.
Depending on the visual effect you want another option is to replace the content of the slow part with a placeholder which is more easily rendered when the isScrolling prop is set - we do something similar with an isLoading prop and loading GIFs, which works well.
According to the docs, one should avoid having multiple components with state. I am in the situation where I want to make a text box that automatically expands vertically as the user writes, and for that I'm using this trick http://www.impressivewebs.com/textarea-auto-resize/, which means I need to get the height of a component. Now, I've been playing around with it a bit, and it doesn't seem feasible to pass a ref to my parent component which contains state, so the easy way out would be to keep a piece of state in the component with the textbox, and then use the ref from there.
This got me thinking, how exactly do multiple state components negatively affect my app? Is it only maintainability / comprehensability? Or are there actual performance issues with it? I've noticed a lot of open source react components that you would just plug in to your app keep state, meaning if you use open source components, chances are you will have several state components in your app.
It's totally ok to use local state for this kind of tricks on DOM. It's even better approach, than to share such implementation details to parent components.
In general, use this places for state:
Application-wide data in stores outside React (redux, flux-store, observables)
Form temporary data can be placed in store also. But if don't need it anywhere else except form, it's better to place this data in form component.
Tricks on DOM, short living and very local state can be placed in component that just need it
are there actual performance issues with it?
No. If you'll place all your state in components, your application will become even faster. Because when you update local state, only this component and it's childs updates.
But you shouldn't do that, because it kills maintainability.
lot of open source react components that you would just plug in to your app keep state
If component doesn't allow you to control it through the props - it's bad component. Usually open source components written to be easier to use, so they provide nice defaults, that allow you to just place component to your application, and be happy with that.
For example, Tabs component usually controlls selected tab using local state. But also it takes selectedTab and callback onSelect, so you can control it by yourself.
Stupid components (like your textarea component) should not have state with data. But they can have their own UI state.
In this case you can easily keep textarea height in state of stupid component.