React: Component Hide/ Show vs Destroy/ Recreate - javascript

Usually when we create conditional components, we do
{ condition ? <Comp1 /> : <Comp2 /> }
My question is, what is better approach?
Hide/ Show components using CSS?
Destroy/ recreate components?
My assumption is, Hide/ Show would be a little better as you will have to go not through creating components again. Just repaint and reflow.
One scenario I can think of that would be an issue with destroy/ recreate would be when you save internal states. This can be achieved using a state management system by passing props. The thing I'm not sure is, if we keep stale components in VirtualDOM and if these components are heavy, like a grid, it will affect the performance but it might still be less than creating the entire component again. So does it makes sence to destroy components?
Not considering React.memo hook, as a caching + recreate will be better. So for a non-hooks based application, what would be a better option?

In my opinion, cuz when React to do DOM diff, it will reduce useless DOM count. If u using class to control that, React will do some extra work

Related

How to React controllable/default-uncontrollable scroll pos

Is there any way to create a react component having controllable and/or default-uncontrollable scrolling pos?
I created a react component having overflow=scroll/auto.
Everything is done using ref=elmRef trick and manipulating through useEffect.
Is it able not to use ref anyway? I want to make a purely react way.
I feel using ref is like a jquery way. The manipulation is done after actual dom component rendered, and might trigger the second render at startup if the manipulation causing to modify any states. There is a state that the value depend on the scroll position. Rendering dom twice is wasteful performance.
Here the visualization of the component i created:

How can I allow a Vue component to manage its own transitions?

By this I mean, when mounted, the enter animation is ran, and when removed, the leave animation is ran. I have a transition that needs to animate a number of elements within it on enter and leave, so I want to move all the code into its own component, then
<template>
<transition #enter="enter" #leave="leave">
<!-- component -->
</transition>
</template>
---
<CustomComponent :key="indentifer" :indentifer="indentifer" />
Full example of my attempt: https://codesandbox.io/s/znq6l8p94p
As far as I am aware this is only half working because of the appear, i.e. it's just mere coincidence.
I feel like the only way I can solve this is by doing all the animation and state management in one component, as in a component that knows about the old and new sentences or use a transition-group, rather than just leaving Vue to manage that for me via my use of the key attribute. Am I perhaps misunderstanding how best to do transitions in Vue, should the animation all ways reside with the parent of a component?
After writing this out it feel like what I actually want is lifecycle hooks like transition-group offers, but which call the child components methods directly.
My current understanding is that during v-on:leave the component is no longer reactive, and you should only be doing manual dom-manipulation...
Instead, my solution was to create a component that handled the adding and removing of the elements via a watch and then passed the array through to my component in props.

Compare the performance between hiding React components with css and state management

If I have a React component and I want to hide it. At the moment, I am taking two approaches:
The state management way
render() {
return (
<div>
{ this.state.showComponent && <Component/> }
</div>
);
}
The CSS way:
render() {
return (
<div>
<Component className="hide-with-CSS"/>
</div>
);
}
I assume that the former way will remove/add the component based on the current state while the latter way just "hides" it. So my questions are:
Which method would produce a better performance?
Is there another way to efficiently hide an element?
CSS solution will be faster for toggling between show and hide.
However, if this.state.showComponent is initially false, then the non-CSS way avoids mounting Component initially, so initial rendering will be faster.
Furthermore, when this.state.showComponent is false, the parent component will be more responsive to other events since it has one less component to render/re-render (when parent re-renders, Component gets re-rendered too even if its props didn't change, unless it's declared as pure or implemented shouldComponentUpdate).
The non-CSS approach is simpler as well since it doesn't involve CSS (whereas the CSS approach requires state management too to toggle the classname).
I'd therefore recommend the non-CSS approach.
To hide or show element in both cases you will need to keep an update some state variable like showComponent and based on its value you got two options:
do a conditional rendering
toggle component CSS class
So the question is - what will work faster CSS or react mounting/unmounting mechanism?
Of course, CSS is going to be faster as it only changes the styling of HTML elements while let say we have a big component with a lot of children - React will have to create initialize these objects, run lifecycle methods, Javascript will have to allocate memory for them and then modify the actual DOM tree (which is an expensive operation).
However, I would argue this will be only a slight performance issue in the majority of cases.

Render all possible elements or render on request

So I have an app that has a right sidebar whose visibility is toggled via a button. In that sidebar there can be one of several things [at a time] - chat, help, search. I was looking at some plain HTML from apps which have a similar feature and noticed that they have all nodes rendered, but are just hidden via CSS.
Since I need to do the same thing, I was thinking whether this would be a good idea to do with React. But then I realized that React elements have a state which when updated calls the render method. So I can use the state to store both whether the sidebar is opened, and what is inside the sidebar.
Is that the React way of doing things? Is it better to have all nodes rendered even if they are not visible, or is it better to have the nodes rendered on request via state changes?
My feeling is that only rendering what is visible would be the more standard React way, but in this case, this is mainly a performance decision. If you render everything and just toggle visibility with CSS, the first render will take longer (but the time difference may not be relevant or even noticeable). If you render only the part that's visible, React needs to do a small rerender every time the sidebar content changes. (This may also not be noticeable time.)
My recommendation would be to try both, if you want to test the performance. But I think you won't go too wrong either way.

How to preserve a component's instance while moving it to another parent component in react?

Suppose we have two sibling react components called OldContainer and NewContainer. There is a child component inside OldContainer that contains a <video> tag, and the video is currently playing.
The user can now drag the child component (with the video) and drop it in the NewContainer, and they expect the video to keep playing while it's being dragged and after being dropped.
So the video appears to stick to the mouse position, and when dragged and dropped in the new container, it animates to its new position (again, it doesn't get paused).
How would you implement this? Can we implement this in a pure way (in line with the spirit of pure functions)?
Clarification: I could have used some other element instead of a video tag for explaining this problem. A NumberEasing element would be a better example, since it would require the props and state of the component to be preserved during and after the interaction.
Update 1: Code examples obviously would be nice, but what I'm mainly looking for is just a general description of how you would approach this problem in a "functional" way. How do you keep your view code simple and easy to reason about? Who handles the drag-and-drop gesture? How do you model the data that's fed into the views?
Take a look at this library : react-reverse-portal
What is it that you want to preserve? Is it Javascript objects that the component holds as state, or is it state in the DOM (like how long a video has played, or text selection in an input box)?
If it's just Javascript objects as state, you're better of moving the source of that state to another service (something like Flux). That way, it doesn't matter if the component gets recreated because it can be recreated with the state that was there before.
EDIT
The way to keep your view code simple and easy to reason about is to not keep state inside your components. Instead, all data that the component needs should be passed into the component as props. That way, the component is "pure" in that it renders the same output given the same props. That also makes the problem of wanting to reuse a component instance a non-issue, since it doesn't matter when the same input gives the same output.
For drag and drop, I'd suggest looking at: https://github.com/gaearon/react-dnd.
How you model the data you pass to view components is up to you and the needs of your application. The components shouldn't care, they should just expect to get data passed as props, and to render them. But the popular approach to dealing with this is of course Flux, and there are many libraries that implements Flux in different ways.
SECOND EDIT
Regarding if you have a subtree with hundreds of components that you want to move: I'd still start off by making the state external (pure components), and render that tree in a new place. That means that React will probably recreate that entire subtree, which is fine. I wouldn't deviate from that path unless the performance of it turned out to be horrible (just guessing that it might be horrible isn't enough).
If the performance turned out to be horrible, I would wrap that entire subtree in a component that caches the actual DOM tree and reuses it (if it gets passed the same props). But you should only do this when absolutely needed, since it goes against what React tries to do for you.
THIRD EDIT
About gestures: I'd start out with listening to gesture events in componentDidMount, and in the event callback call setState on the component with the coordinates it should have. And then render the component in render with the coordinates given. React won't recreate the component when you call setState but it will re-render it (and diff the output). If the only thing you changed was the coordinates, it should render fast enough.
If that turns out to be too slow, like if the subtree of that component is huge and it becomes a bottleneck to recreate the subtree of vDOM, I'd reposition the DOM node directly in a RAF-loop outside of Reacts control. And I'd also put a huge comment on why that was needed, because it might seem wierd for some other developer later.
Create a new variable using const or var. Put the instance of data using rest spread operator, update the necessary data to pass and send the data to the component without mutating the state of component.
Just like:
const data = {
...this.state.child,
new_data : 'abc'
}

Categories

Resources