Skip to content

[Due for payment 2025-08-11] [Due for payment 2025-07-28] [Due for payment 2025-07-18] Remove the initialValue option from the useOnyx hook #65022

@roryabraham

Description

@roryabraham

Proposal: Remove the initialValue option from the useOnyx hook and enforce fallback value handling via default JS destructuring, supported by a custom ESLint rule.

Background

Historically, the initialValue parameter was used in the withOnyx HOC to provide the initial value while the data was loading from the onyx, and it was carried over to the useOnyx hook to maintain parity. Meanwhile, a new pattern — using default value destructuring — has become more common across the codebase and is generally more intuitive for developers.
Besides that, in most of the cases right now the new inline empty object/array (e.g., = {} / = []) are used as the defaults.

Problem

When both initialValue and default value destructuring are supported, it causes inconsistent developer experiences, which prevents us from having a single, predictable pattern for setting fallback values in useOnyx.

Additionally, the new inline empty object/array as defaults introduce unstable references, which can cause unnecessary re-renders and performance issues.

Solution

  1. Remove the initialValue parameter from the useOnyx hook and standardize on default value destructuring for fallback behavior.
  2. Standardize destructured defaults to use primitives and reference-stable constants such as CONST.EMPTY_OBJECT and CONST.EMPTY_ARRAY instead of literal {} or [] values. This will help to avoid unnecessary React re-renders.
  3. Introduce a custom ESLint rule to disallow inline empty object/array defaults inside the useOnyx hook.

These change will simplify our hook usage, reduce inconsistent behavior and re-renders, and make fallback logic more explicit and easier to maintain.

Note: I've looked through all of the cases, where initialValues are used and noticed just one place where these updates can affect the logic, but it should be possible to easily fix it.

Issue OwnerCurrent Issue Owner: @mallenexpensify

Metadata

Metadata

Labels

Awaiting PaymentAuto-added when associated PR is deployed to productionImprovementItem broken or needs improvement.WeeklyKSv2

Type

No type
No fields configured for issues without a type.

Projects

Status
Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions