lHello everyone, here is the problem.
We have a grid component with some filtering enabled. When the filtering is applied, if a certain callback-prop exists, it is called with the filtered data as an argument.
The problem is this. If said datagrid is wrapped by a parent component and the parent component saves the filtered data in it's state, it causes the parent to rerender, but also the datagrid. However, when the datagrid renders it runs it's filtering logic, which causes the callback(which is setState() call) to run.
So, to avoid the loop I introduced a variable to the parent component class and save the data there, but it doesn't seem so good to me.
Another option would be redux, just add a new action and dispatch it when the filtering runs.
Any other ideas?
Since you're also asking for other ideas, may I suggest React hooks. They allow finer-grained control, such as multiple states, reducers, memoized callbacks, effects that are only called when inputs change, etc.
Related
I am unsure as to whether I should change my approach on how I render the components. I depend on a lot of modals that causes unnecessary re-renders when showing/hiding the modals.
This is a basic idea of how my components are currently being rendered:
I have cases where I can re-use the components (such as Component X in Component C and D), however there are cases (Component A3/B3 and Component E3) where the structure is completely different making it difficult to reuse the component. The problem I am encountering is slow UI due to multiple re-renders.
I display the modals based on state variables declared in their corresponding parent component. When changing the parent's state variable to display the modal causes the parent to re-render, and thus all of its children too. So as an example if I want to display the Create/Edit modal in Component A1, this will cause Component A, A2 and A3 to also re-render which is quite unnecessary. I have made use of the useMemo and useCallback hooks (https://reactjs.org/docs/hooks-reference.html#usememo) to help reduce the load, but I am unsure if this is the right approach? It feels like I am depending too much on the useMemo and useCallback hooks just to display a modal.
The idea behind the modals is to delete/edit/create a record that will display in the table (located in a different component). This is by design and I cannot change this.
To manipulate the data I am passing a callback function to each modal component. The modal component sends through the data being changed in the modal to the callback function where the data can be manipulated on the parent component.
This is a case for React.memo. It is like the useMemo hook, but for components, and prevents re-renders of the component unless its props change:
const MyComponent = React.memo(function MyComponent(props) {
/* render using props */
});
If your component renders the same result given the same props, you can wrap it in a call to React.memo for a performance boost in some cases by memoizing the result. This means that React will skip rendering the component, and reuse the last rendered result.
If this doesn't solve the issue because your modals and components share the same props, then it's probably time to reconsider the structure of your state so that you can separate it according to the concerns in your application.
Alternate approaches for independent use of "global" state include the context API, and various atomic state libraries like recoil and effector.
I've got a complex component which does all its rendering in a render function. There are multiple parts to this, and different bits of the view get rendered - one of these things is a filter bar, showing the filters that have been applied.
What I'm noticing happening, is if I apply a filter which in turn presents this bar, it causes everything else to be fully re-rendered. This is causing a number of other issues and I need to try and stop it from happening.
I've never come across this issue when using normal templates as Vue seems to handle these very intelligently, but I have no idea how to tackle this. The only thing I can think of is setting a key on each thing I don't want re-rendered but not sure if this will a) solve the problem, and b) be possible for the content that is passed in through a slot
Has anyone else faced this issue, and if so how can it be solved?
I had a similar issue when using vuetify text inputs in a complex component which was causing the app to slow down drastically.
In my search I found this link which was specific to vuetify:
high performance impact when using a lot of v-text-field
then found out that this is actually a vue thing from this GitHub issue:
Component with slot re-renders even if the slot or component data has not changed
and there is plan to improve this in it is tracked here (vue 3 should resolve this issue):
Update slot content without re-rendering rest of component
so after reading through all these I found some workarounds that helped me a lot to boost the performance of my app, I hope these will help you as well:
divide that complex component into smaller ones specially when there is some bit of code that changes data that bounds to template causing re-rendering (put them in their own component)
I moved all data layer control to the vuex store, instead of using v-model every where and passing data as events and props, all the data is updating in the store through an action and read from the store through a getter. (from data I mean somethings that is being looped in the template in a v-for, API results, and so on... all of them is being set, updated and read through the store. my components still have the data object but only for the things related to the style and template control like a boolean to control a modal or an imported icon which is used in the template and alikes)
lastly I wrote a function called lazyCaller which its job is to update the values in the store with a delay (when immediate data update isn't necessary) to avoid rapid updates comping from something like a text input (with out this every key stroke trigger the value update action)
In our experience, thinking about how the UI should look at any given moment, rather than how to change it over time, eliminates a whole class of bugs.
From React Docs
From my understanding, this means that React only updates what's necessary, rather than destroying and re-constructing the entire DOM tree again. Am I wrong?
Can anyone please help me understand the quoted statement?
Thanks.
From my understanding, this means that React only updates what's necessary, rather than destroying and re-constructing the entire DOM tree again. Am I wrong?
If you want to know the short answer, I have to say it is true, React will update the necessary elements in DOM whenever it needed.
But if you want to know how it's done, and when React will update the DOM and its element I have to it is varying to different several things, like project architecture, using proper methods (proper hooks in functional component eg. useCallback, useMemo, and so on) and so on.
When it truly gets rerender then?
As far as I know, there are two ways React finds out when to rerender the DOM.
Passing elements to ReactDOM.render
Update a state
What is ReactDOM.render?
This will call the render() method from react-dom (Where we usually import it as ReactDOM) and it will render a React element into the DOM in the supplied container and return a reference to the component (or returns null for stateless components). Also if the React element was previously rendered into the container, this will perform an update on it and only mutate the DOM as necessary to reflect the latest React element.
What does state mean?
The state object is where you store property values that belong to the component. So when you got a component and that component has their own specific variables where changing them should affect the DOM you should use it, then whenever state gets changes the component will be updated.
So what I even talk about project architecture and this stuff, when I didn't mention anything about it above?
Let's say we got a project with one parent component and 3 child component just like this:
Component 1
- |- Component 2
- - |- Component 3
- - - |- Component 4
So whenever you a state in Component 4 all of the DOM elements will be get rerendered, why then? Because Component 4 is a child of Component 3 and so on, so when the child state gets change it will force the parent to rerender then the whole DOM will rerender once per state change.
Final Note
So, at last, we should be always considered a good architecture and hierarchy for our project or when it necessarily use built-in methods like useMemo to avoid such a thing.
I have a large array that I am using in a component (component A) with *ngFor with a nested *ngFor.
Component B initialises a jquery plugin which registers a document mousemove event handler, I am using this.zone.runOutsideAngular to init the plugin and I am calling this.ref.detectChanges() in the callback as I need to update the UI on mousemove inside the component B.
Component A is not a child of component B.
As soon as the component A is rendered change detection becomes very slow. the array does not change and I am using the ChangeDetectionStrategy.OnPush strategy for component A but when I fire ref.detectChanges() inside component B, ngDoCheck gets called on component A and I can see a noticeable jank on mousemove.
Is there a way to tell angular to completely ignore the large array of items in component A and allow me to handle when the UI should be updated? I thought that using ChangeDetectionStrategy.OnPush would give me what I need but I have tried removing all #Input()s from component A and anytime I call this.ref.detectChanges() inside component B it is still firing ngDoCheck and it is obvious that this is very slow.
I can scroll through the list of items no issue, but it is when I am triggering the detectChanges inside the mousemove on component B that is causing the issue. I know I could manually update the DOM but I think this would just be a workaround as it would only address the jank on mousemove and not the issue around the change detection being slow.
I have got to the bottom of this issue.
The problem was that inside component A for the nested *ngFor I was using a child component to render each sub item which meant that although I was using the ChangeDetectionStrategy.OnPush strategy, it still required a ref check for each item.
I have now moved the html from the child component into component A directly and this has had a huge impact on performance.
this.ref.detach() to remove the detector from from the tree completely, that should stop the checking. Then you can still call detectChanges to do it manually, and reattach to bring it back online.
Maybe also debouncing the mousemoves (rxjs debounceTime()) might help, unless you really need to track every mousemove?
One more optimization if you already didn't, add trackBy: yourTrackByFn to the ngFor(s).
I've created a JSfiddle
In this fiddle, initially a list of checkboxes is rendered based on the props which are passed to the component.
On clicking the Re-render button, the same component is rendered with a different set of props.
Now, please follow the below steps-
Load the jsfiddle
Check any of the checkbox (let's say I check the 2nd and 3rd checkbox)
Click Re-render button
Even after rendering the component with new props, the state of checked boxes which you checked remains unchanged (2nd and 3rd are still checked)
Why does it happen?
How can I re-render the component with new set of props such that the state of checkboxes do not persist.
Because React's diff algorithm is smart. The conditions to rerender a new component are:
either the component has a different key (Different Keys)
or it actually is a different HTML element (Different Node Types)
Here's a working example: http://jsfiddle.net/lustoykov/ufLyy3vh/
The thing is - neither condition to rerender your input element is satisfied, so React really reuses the old input. What I've done is to generate a new key for every input element on each rerender. React assumes this is a new element because the key changes and the input gets rerendered with the correct value.
The Math.random() is necessary in order to make sure you generate different keys, it's like: Hey, React, this element has changed - please rerender it.
However, I would argue against this approach with different keys, because it is against React's philosophy. Why would you use React if you rerender the same element every single time? That's the core of React - not to rerender when the component is the same. Instead, you should use onChange handler to update only the values of your inputs without explicitly rerendering the whole input component.
Have a look how to work with React forms.