coming from this proposal
Background
Selectors in react-native-onyx are functions that allow to subscribe a subset of data from storage, providing performance benefits by only re-rendering components when the selected data changes, rather than when any property in the entire object changes. They transform, filter, or extract specific data and support type-safe operations on both individual keys and collections.
Recently we merged a couple of improvements to useOnyx, including the memoization working properly with stable references. However, most of our codebase still uses inline selectors, which prevents us from taking advantage of these optimizations.
Problem
When using selectors in useOnyx, if you define the selector as inline function directly in the options object, then the memoization system breaks causing unnecessary re-computations and re-renders on every component update.
Solution
Make selectors first-class citizens in E/App by organizing them according to their usage scope:
- Shared selectors: if a selector is reused across multiple components, define it in a dedicated selectors/ directory so it can be consistently imported and reused.
- Local selectors: if a selector exists purely for the needs of a single component or hook, define it in the same file outside the component where it’s used to avoid unnecessary abstraction.
- Contextual selectors: if a selector relies on additional data from the component itself, define it as a useCallback inside the component, with the relevant data passed as dependencies.
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~021965762166257784585
- Upwork Job ID: 1965762166257784585
- Last Price Increase: 2025-11-10
Issue Owner
Current Issue Owner: @TMisiukiewicz
coming from this proposal
Background
Selectors in react-native-onyx are functions that allow to subscribe a subset of data from storage, providing performance benefits by only re-rendering components when the selected data changes, rather than when any property in the entire object changes. They transform, filter, or extract specific data and support type-safe operations on both individual keys and collections.
Recently we merged a couple of improvements to useOnyx, including the memoization working properly with stable references. However, most of our codebase still uses inline selectors, which prevents us from taking advantage of these optimizations.
Problem
When using selectors in useOnyx, if you define the selector as inline function directly in the options object, then the memoization system breaks causing unnecessary re-computations and re-renders on every component update.
Solution
Make selectors first-class citizens in E/App by organizing them according to their usage scope:
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @TMisiukiewicz