Open theKashey opened 4 months ago
const {propA, propB, rest} = useMemo(() => {
const {propA, propB, ...rest} = propsC;
return {propA, propB, rest};
}, [propC]);
useEffect(() => {
// some effect not expected executed on every render
}, [rest]);
// ^^ rest is "stable"
Keep in mind that useMemo
has no semantic guarantees. React could decide at any point that it reruns the memoized function because it freed up memory used by the memoized result. The rest
value would change even though propsC
didn't. That's why StrictMode also runs the function passed to useMemo
twice.
it should render Component twice and ensure no useEffect or useMemo is invalidated
I think this would be interesting to try out in an experiment. Could be a PR for starters. At a glance, seems reasonable to expect effect dependencies to be stable between double render. You'd also expect the committed HTML to be stable.
any point that it reruns the memoized function
Not really a problem if React from time to time resets one or another branch. It is a problem if such a reset happens on every render.
You'd also expect the committed HTML to be stable.
This could be a little extension to the definition of a pure function
- not only produces the same output for the same input, but also runs exactly the same effects so React can optimise run once for any number of render calls.
It is very important to have this check at the lowest level (React) as optimisations in other places may only temporarily hide the problem. See https://github.com/reduxjs/react-redux/issues/2160 as an example
Just to keep you in touch - did a dirty spike around the problem and found two models applicable to a given task
A simple solution was able to reveal a few cases where we used createRef
instead of useRef
as well as un-memoized callbacks being directly consumed.
It also resulted in some noise from direct refs operation in hooks like usePrevious
, so I had to switch to 3 renders in a row and compare the second and third in order to minimize the number of problems to tackle.
The downsides of my solution are:
The second solution does not require any modification of React except overriding useEffect
/useMemo
hooks with trackable versions.
useEffect
to create a part of useEffect
+ useContext
context
to cause an update to every component with useEffect
Expectations:
createRef + useEffect
The combination of such "small cycle" and "large cycle" has proven to be extremely effective without any need to Forget things.
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
React Compiler removes the majority of "trashing" effects and eslint is pointing to problems. However this approach is still the simplest measure to find a problem in the code that needs fixing. Simple and powerful.
If Strict Mode is still around, then this feature should be a part of it.
React version: any with StrictMode
Steps To Reproduce
useEffect
with unstable dependencyStrictMode
is not able to help hereuseEffect(() => { // some effect not expected executed on every render }, [rest]); // ^^ rest is "unstable"
useEffect(() => { // some effect not expected executed on every render }, [rest]); // ^^ rest is "stable"
The current behavior
https://react.dev/reference/react/StrictMode
I personally never found this behaviour any helpful. It never helped me find a bug, especially a bug related to useEffect.
The expected behavior
I would assume that
StrictMode
should not try to executeuseEffect
twice - it should render Component twice and ensure nouseEffect
oruseMemo
is invalidated. Ideally, it should cause full application re-render to detect memoization issues spanning across multiple components, like usingchildren
in effect dependencies or passing unstable prop to a component withuseEffect
as such case cannot be detected by isolated re-render.React Forget is going to change the game rules and automatically fix the problems from above, but how one can prove it without having a corresponding testing functionality one can trust? Unfortunately, this is something very hard to implement in the user space, simultaneously something causing incidents (performance as well as reliability) on a weekly basic