Are referential-type values as default props in object destructuring optimized by React Compiler?

[bk-tho]

@eslint-react/eslint-plugin includes the rule no-unstable-default-props:

Prevents using referential-type values as default props in object destructuring.

When using object destructuring syntax you can set the default value for a given property if it does not exist. If you set the default value to one of the values that is compared by identity, then each time the destructuring is evaluated, the JS engine will create a new, distinct value in the destructured variable.

This harms performance as it means that React will have to re-evaluate hooks and re-render memoized components more often than necessary.

To fix the violations, the easiest way is to use a referencing variable in module scope instead of using the literal values.

Is this still useful with React Compiler or will it optimize for these cases?

[bk-tho]

Just tested it in Compiler Playground. The compiler leaves it as is. Seems like a potential opportunity for the compiler?

[aniruddhaadak80]

Hi there! Taking a look at your issue regarding Are referential-type values as default props in object destructuring optimized by React Compiler? in the context of reactwg/react-compiler...

When working with the React Compiler (React Forget), this type of behavior usually stems from how the compiler analyzes hook dependencies and component boundaries. Make sure that:

1. Your code strictly adheres to the Rules of React. The compiler bails out or behaves unexpectedly when it detects rule violations.
2. In certain cases, explicitly defining memoization boundaries or isolating the hook/component into its own tightly-scoped file helps the Babel plugin successfully parse the AST.
3. Verify your ESLint eslint-plugin-react-compiler rules are green before compilation, as the compiler relies heavily on those guarantees.

Hope this helps clarify the expected boundaries! Let me know if you have a minimal repro I can test against.