Feature request: SimpleMemoComponent fast path for React.memo with custom arePropsEqual

[barryam3]

#13903 added the SimpleMemoComponent tag and created the fast path for components created by React.memo where component is just a function and the default props comparison is used. The PR description says:

We could make it so that this also works with custom comparer but that means we have to go through one extra indirection to get to it. Maybe it's worth it, donno.

This is a feature request for making the fast path work with a custom props comparison.

I'm use custom props comparison extensively. I'm struggling to measure the overhead of the slow path -- here's my attempt -- but I'm concerned it may be significant. This also has the side effect of creating an extra node in React DevTools, which makes debugging harder.

[aelric1]

Interesting! A potential middle ground could be to use the fast path when the custom arePropsEqual is a pure function reference (i.e., arePropsEqual === Object.is || shallowEqual) and fallback otherwise. This might avoid the extra indirection in common cases.

[barryam3]

The challenge is that the current implementation replaces the fiber type with the underlying component function, at which point the compare function is lost. By setting the fiber type to SimpleMemoComponent its treated as a FunctionComponent from then on except that we call updateSimpleMemoComponent which uses the default shallowEqual comparison. At the point where you allow a second comparison function, you need a way to tell which one you are using.

I think the simplest way to do this would be to attach the compare function to the component function itself: https://github.com/facebook/react/compare/main...barryam3:react:compare-on-function?expand=1

Perhaps a more principled way to do this (not defining a property on a function, and one that the user has access to) would be to pass around the MemoExoticComponent object. This requires a lot more changes. I tried prototyping this but am getting some tests failures https://github.com/facebook/react/compare/main...barryam3:react:memo-compare-fast-path?expand=1 my guess is some code where Fiber.type is a function is creating a new Fiber where Fiber.type is a funciton, but my change expects it to be a MemoExoticComponent object

[aelric1]

Thanks for the detailed explanation!

I agree that attaching the compare function directly to the component function is a clean and practical short-term approach, especially since it's under user control and avoids deeper changes to the Fiber system.

For the more principled solution (passing around the MemoExoticComponent), I think you're right — the main challenge seems to be when Fiber.type is a plain function. Some internal paths probably expect it to be a function rather than a Memo wrapper, which would cause the shape mismatch and lead to test failures.

One idea to explore could be to preserve the compare function on a symbol property (like Symbol.for('react.memo.compare')) attached to the component function or memo object, and use that symbol in the update path logic. This avoids naming collisions and keeps it out of the public API surface.

Let me know if you'd like help testing or iterating on the prototype. Happy to dive into it!

[barryam3]

I did some benchmarking for the options:

• Write path benchmark
• Read path benchmark

Write path:

Method	Speed
defineProperty	Slowest (42ns)
weakMap.set(component, compare)	5x faster (7ns)
component[symbol] = compare	5x faster
component.compare = compare	15x faster (2ns)

Read path:

Method	Speed
weakMap.get(component)	slowest (5ns)
component[symbol]	3x faster (2ns)
component.compare	3x faster

This is actually making me lean toward the Weak Map solution. The savings for using a property is only about 3ns per re-render, and 5ns per initial render. This doesn't seem worth the risk of attaching a property to the user's component function, which the user could then potentially get at, intentionally or unintentionally. And if we want to make the property non-enumerable, we pay an additional cost of about 35ns on the initial render to use defineProperty. Even then, the property can still be gotten at via getOwnPropertyNames.

Here's the Weak Map implementation: main...barryam3:react:memo-fastpath-weakmap

[github-actions]

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!

[barryam3]

I have a PR out for this: #34540

[github-actions]

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!