So basically you're shifting the re-render from react's reconciler to the DOM. If you want to forgo the virtual DOM in order to improve performance, you could also consider a framework like Svelte or SolidJS.
I am not saying Don't use state. My intention is to reduce the usage of useState where ever it is unnecessary and one more if we are working in any react project which is in mature state there we cannot change the tech-stack so at-least we can improve it by doing few things like this.
On one hand, you're reducing the usage of state, on the other you're making it harder for other maintainers, if there are any. Especially if there are side effects that should influence the state (e.g. a server-side confirmation about the toggle), you'll switch back to state anyways.
You still have a point: don't overuse state - and make your state as dumb as possible. It'll save trouble in the long run.
I see useRef as a way to do internal state updates without causing a re-render. Something you want to retain without impacting renders. When most of the world has moved to Svelte/Solid, then I think most react devs will be happy to move over, but since the job market is not there for it, it makes it less valuable to an individual engineer to invest in it so fully.
Here's an issue: react does not guarantee that the nodes it manages stay the exact same. So if something else causes a re-render, you may lose the attribute if it is also managed by react and thus overwritten by the reconciler.
And as I already stated, the DOM of the changed node will re-render anyways, only the virtual DOM will not precede that update.
If your goal is performance, better avoid unnecessary re-rendering of components. Fine-grained updates should be sufficiently performant already - and if they aren't, your problem is either somewhere else or react is not the solution. Maybe Svelte or SolidJS would be a solution in that case - that's all I'm saying - not that everyone should switch.
That being said, the best thing about react is the tooling, which makes for a developer experience unmatched by most other frameworks.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So basically you're shifting the re-render from react's reconciler to the DOM. If you want to forgo the virtual DOM in order to improve performance, you could also consider a framework like Svelte or SolidJS.
I am not saying Don't use state. My intention is to reduce the usage of
useState
where ever it is unnecessary and one more if we are working in any react project which is in mature state there we cannot change the tech-stack so at-least we can improve it by doing few things like this.On one hand, you're reducing the usage of state, on the other you're making it harder for other maintainers, if there are any. Especially if there are side effects that should influence the state (e.g. a server-side confirmation about the toggle), you'll switch back to state anyways.
You still have a point: don't overuse state - and make your state as dumb as possible. It'll save trouble in the long run.
I see useRef as a way to do internal state updates without causing a re-render. Something you want to retain without impacting renders. When most of the world has moved to Svelte/Solid, then I think most react devs will be happy to move over, but since the job market is not there for it, it makes it less valuable to an individual engineer to invest in it so fully.
Here's an issue: react does not guarantee that the nodes it manages stay the exact same. So if something else causes a re-render, you may lose the attribute if it is also managed by react and thus overwritten by the reconciler.
And as I already stated, the DOM of the changed node will re-render anyways, only the virtual DOM will not precede that update.
If your goal is performance, better avoid unnecessary re-rendering of components. Fine-grained updates should be sufficiently performant already - and if they aren't, your problem is either somewhere else or react is not the solution. Maybe Svelte or SolidJS would be a solution in that case - that's all I'm saying - not that everyone should switch.
That being said, the best thing about react is the tooling, which makes for a developer experience unmatched by most other frameworks.