[Ledgers] Add the remaining built-in Ledger kinds #37593

Open
acdlite opened 11:07am on September 11, 2026 wants to merge 447 Ξ” into facebook/react ledgers/5-decode-client from
ledgers/6-kinds

Pull Request Overview

  • Opened on September 11, 2026
  • Status Open
  • Commit count 1 with first commit September 14, 2026

Total Delta

447 Total Diff Delta

Open Days

Open 6 weekdays

Test Delta

0 Diff Delta in Test Files
Breakdown by Phase

How long has this pull request spent in each phase of its lifecycle?

Data pending calculation for pull request

Author avatar

[Ledgers] Add the remaining built-in Ledger kinds

Adds the remaining built-in Ledger kinds.

Ledgers are limited to a fixed set of built-in kinds. There is no generic Ledger constructor, by design. We could consider adding one later if a compelling use case arises.

All the built-in kinds follow certain algebraic properties:


  • Monotonicity. A write in one component must not cancel out a write in a different component. For example, once a bit is set in a Mask ledger, it can never be unset.

  • Commutativity. The order of writes should not affect the final total. This allows us to stream parallel parts of the graph independently, without buffering them to preserve write order.

  • Associativity. Grouping writes into partial totals must not affect the final total. This allows us to accumulate and merge totals incrementally. If a stream is intentionally closed early during partial prerendering, its total describes the portion that was received.

The built-in Ledger kinds are:



  • createBitLedger. Flips a flag from false to true.


  • createMaskLedger. Adds bits to a bitmask.


  • createMinLedger. Tracks the smallest number.


  • createMaxLedger. Tracks the largest number.


  • createSetLedger. Accumulates a Set of scalar values.

There's a caveat regarding Set Ledgers: Sets in JavaScript have an iteration order, but React does not guarantee anything about the order of the entries in the final Set. The order is considered undefined and consumers must not rely on it.

Sets also only support scalar values for now, not objects. This is because object identity is not a good basis for set equality. We may add support for sets of arbitrary values later, though we'll need to consider the identity question again.

No comments have been left on this PR.