Discuss useRef usage

[thaisguigon]

https://react.dev/reference/react/useRef

useRef is a React Hook that lets you reference a value that’s not needed for rendering.

As discussed with @magrinj and @emilienchvt, we would like to reassess how we can use this hook for better performance. Right now it is mostly only used for manipulating the DOM with HTML element refs but it could be useful in other cases where we want to keep reference to a value without triggering re-renders.

[magrinj]

I completely agree. While useRef is often used for referencing mutable DOM elements, its utility goes far beyond that. As pointed out in the React documentation, it can be used to maintain a reference to a value that does not affect the render output. This can include values from a setInterval operation, timers, or other data sources that need to persist across multiple render cycles.

The major advantage here is that changes to these references do not trigger component re-renders, which can significantly improve performance in scenarios where the reference is updated frequently but the view does not need to be refreshed.

Beyond this, I think useRef could be beneficial in scenarios involving complex calculations or tasks that we wouldn't want to repeat unnecessarily due to re-renders. For example, we might store the results of such computations in a ref, ensuring that we only perform them once and use the stored result thereafter.

In essence, we can look at useRef as a mechanism for storing "memory" or "state" that doesn't affect the render output but might be important for the logic of our components. This can open the door to more performant and efficient components. Looking forward to exploring this further with the team!

[magrinj]

cc @charlesBochet @lucasbordeau

[charlesBochet]

pHappy to discuss it,
My opinion is that we should avoid it except when using it to manipulate DOM reference and rare cases:
To me:

• useRef is very similar to useState. If we do need to do complex computations useCallback (+ useState) can achieve the same output.
• they are rare cases where we need it (I think setInterval is one if you want to be able to clearInterval)
• if we are using it to prevent a variable change to trigger a re-render of a complex component, we can extract this variable to another component that would live beside the complex component. (see GenericEntityTableData for instance)

As this is introducing a second way to do things we can do with setState with the same complexity (TBH, I personally think that useRef API actually complexifies code reading but this is subjective), I would strongly advocate to have one way of doing things. This will help keeping the codebase uniform, and prevent discussions on either we should use useRef or useState in "THIS" specific cases (which will likely never ends are they are similar). Keeping clear coding conventions is an important winning condition on this project.

In a nutshell, I would really push to keep only using useState (+ useCallback) on the project, except if there is no easy way to do so. Do you have a particular example into mind where you would really need useRef or it it significantly more convenient?

@lucasbordeau has refactored the whole table component (which is by far the most complex we have), there are no more re-render on table, it's performant and no useRef have been used

[magrinj]

Appreciate your perspective on this @charlesBochet. While I understand your concern for keeping the codebase clean and streamlined, I believe that useRef could provide us with certain advantages in specific contexts.

useRef does indeed share similarities with useState and useCallback. However, there are a few key distinctions that make useRef a good way to go in some case:

1. Non-triggering of re-renders: useRef does not cause a re-render when the referenced value changes. This can be a significant performance optimization in scenarios where a value changes frequently but doesn't impact the rendered output.

2. Persistence of data: The useRef hook provides us with a way to persist data across the entire lifecycle of a component. Unlike local variables which get wiped out after every render, a ref persists without causing additional renders.

3. Broad applicability: Beyond DOM elements, useRef is ideal for holding any mutable value, especially those that do not influence the component’s output. This could include interval IDs, timers, Promises, external mutable sources, computed values from heavy operations, and more.

A practical example of using useRef could be when we perform an expensive computation or an API call on the first render and want to keep this value for the entire lifecycle of the component. If the component re-renders due to unrelated prop or state changes, the value in useRef would still persist, thus avoiding unnecessary recalculations or repeated API calls. This can lead to significant performance improvements, especially in components that re-render frequently.

As for the refactor by @lucasbordeau, it's a really great job! However, the shared state management in that case involves different considerations and might not directly apply to all situations where we could potentially benefit from useRef.
In this refactor we're using a lot of recoilState, that are also using useRef internally in the same way we suggested above:
https://github.com/search?q=repo%3Afacebookexperimental%2FRecoil%20useRef&type=code

In conclusion, for me, while useState and useCallback should be our go-to in most cases, let's also consider useRef as a performance optimization tool in specific scenarios. I believe using the right tool for the right job can result in a more robust and efficient codebase.

[emilienchvt]

From the react documentation, community threads and various articles, useRef is a valid implementation of a data container that can be used throughout the component's lifecycle, improving performance by preventing re-renders (unlike useState).
That being said, it introduces mutability, coming with some pitfalls (also detailed in the doc). There is also a risk that using it as a state or derived state brings us to force re-renders, defeating the purpose of key react features.

I tend to agree we should restrain its usage to:

• Manipulating DOM elements when necessary
• Carefully scoped performance improvements (examples: setting a recoil scope id, detecting first mount of a component)

On storing the result of complex calculations, I tend to agree with @charlesBochet 's point to have it in a separate component as it prevents re-renders and brings code separation without the inconvenience of useRef.

Also, on the point that recoil is using refs, IMO it is great that we can leverage the perf optimisation of refs with a nicer API (note that recoil's selectors are also a way to handle complex calculations for derived state).

[lucasbordeau]

useRef can be used :

• for state management (instead of useState and state management libraries)
• to avoid re-renders
• to hold mutable values

State management

We can already cover 100% of any use case with a state management library and React state management.

Even setTimeout ids, even if it may not be as localized and easy to do.

useRef is very low level compared to a state management library, this can lead to unwanted side effects :

• complex and unanticipated (maybe even unwanted) patterns
• creation of a complete homemade state management library
• multiple iterations of patterns living side-by-side in the codebase
• no clear way to do things, leading to unnecessary discussions about how to code specific use cases

While I understand the need for a more "flexible" way to play with state and re-renders in React, I think it's always a tradeoff, and what you gain in flexibility and "freedom" you lose in maintainability and scalability of the codebase.

People of all skill levels need to be able to contribute, relying on a robust and known state management library is essential to help everyone contributing.

They can look for answers on internet for problems that are already shared with the state management library's community.

While we don't have a standard state management library as of 2023 for React, state management is and will remain a core part of frontend development.

Going back to a low-level way to handle it because we don't have a standard trend to follow can be understandable but will actually cause more problems than using a non "approved" library.

Recoil is using useRef under the hood, and they abstract it for us behind an API. We are often surprised to see how libraries does their magic under the hood and it's not always an example to follow for a business application codebase.

We can cover all the use cases where we need to be "out" of React's loop to avoid re-renders with useRecoilCallback for example.

We can also use React's contexts for const values, to avoid initializing Recoil atoms that are just read only state.

Re-render management

• the essential point is to seek the root cause of the re-render, which generally occurs in unoptimized high level components and providers : authentication, Apollo, router, etc.
• using temporary ways to prevent it like memo() or userRef certainly works at the feature level but always leads to technical debt.
• when re-renders are properly handled from the root level down to the lowest component, we don't need to rely on "re-render breakers"
• re-render can be avoided for a great part by calling "glue" initialization hooks or useEffects in a sibling component, next to the hierarchy of components that is experiencing unwanted re-renders.
• using useRecoilCallback, family selectors and family states from Recoil, which are basically concepts shared with every state management libraries : manipulating and slicing state without causing re-renders.

Mutable values

It's not clear here why we would need to store values out of React.

We can certainly do it through many ways :

• plain JavaScript global variables
• memory store libraries / in memory DB
• local storage
• etc.

useRef feels a bit like a static property of a class, but we've seen that class components and too much OOP doesn't fit well with React and frontend development in general.

All those ways share the same inherent problem : manual synchronization with React and the render loop, which leads to state management, see above.

Conclusion

While useRef can certainly be used for doing what can already be done with more appropriate and known patterns, there's no clear reason here why we would need to use it except to "try" a new thing, which can be exciting and would be indicated in a state management library codebase, but not for a business application codebase like Twenty.

Although we shouldn't need any useRef at all except for talking with HTML, we should be tolerant with useRefs that are currently used but let's keep in mind that they could be removed, for the reasons described above.

State management is one of the most tedious topics in front end development. Let's keep it simple by following clear and opinionated patterns that are already shared with the community so that everybody can contribute easily.

[FelixMalfait]

Closing as there hasn't been any activity recently so the topic seems to be settled!