RFC: Granular Subscription State

[palacharlanarendra]

This RFC proposes a way to reduce unnecessary re-renders by allowing components to subscribe only to the specific parts of state they actually use. The idea is to track property access within a selector and re-render only the components that depend on the changed value, rather than re-rendering entire subtrees.

The goal is to improve performance and developer experience in large React applications without changing existing mental models or requiring heavy memoization. The proposal outlines how this could work using a dependency map and a useGranular hook that integrates with useSyncExternalStore.

I’m opening this to start a discussion on whether this direction aligns with React’s long-term performance goals, and whether it makes sense as an experimental API or an external package first. Feedback on potential pitfalls, API shape, or integration considerations would be appreciated.

File added:

text/0000-granular-subscriptions.md

Looking forward to thoughts and discussion.

[meta-cla]

Hi @palacharlanarendra!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[slorber]

This has been discussed in other RFCs and issues already, see:

• RFC: Context selectors #119
• Skeleton for store facebook/react#33215
• https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more#concurrent-stores

[palacharlanarendra]

This has been discussed in other RFCs and issues already, see:

• RFC: Context selectors #119
• Skeleton for store facebook/react#33215
• https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more#concurrent-stores

Thanks for sharing these references I’ve reviewed #119, the Store Skeleton PR, and the recent Concurrent Stores work. Those proposals focus on how stores integrate with React, mainly through selectors or new primitives.

This proposal is different:
it explores automatic per-property dependency tracking, where components re-render only for the exact fields they access, without selectors or atoms.

Zustand, Redux, Jotai, etc. all rely on manual slicing or atomization.
This RFC focuses on render granularity, not state modeling, so it addresses a different layer of the problem.

Happy to refine the idea further based on this direction.

[josephsavona]

Thanks for your interest and taking the time to write an RFC. As others have noted, this substantially overlaps with ongoing work - the compiler and concurrent compatible stores in particular.

There is also a key missing piece to your proposal, which is the mechanism by which the theoretical automatic tracking would occur. If I’m reading user.address.city, how do we actually record the component->data dependency? There are many answers all with significant tradeoffs. We are deeply familiar with the tradeoffs involved in this space, and have done considerable research in this area. See https://www.youtube.com/watch?v=zyVRg2QR6LA

So to summarize: we’re working on things in this space. But we don’t plan to ship an API exactly as proposed.

[palacharlanarendra]

Thanks for your interest and taking the time to write an RFC. As others have noted, this substantially overlaps with ongoing work - the compiler and concurrent compatible stores in particular.

There is also a key missing piece to your proposal, which is the mechanism by which the theoretical automatic tracking would occur. If I’m reading user.address.city, how do we actually record the component->data dependency? There are many answers all with significant tradeoffs. We are deeply familiar with the tradeoffs involved in this space, and have done considerable research in this area. See https://www.youtube.com/watch?v=zyVRg2QR6LA

So to summarize: we’re working on things in this space. But we don’t plan to ship an API exactly as proposed.

Thanks for the clarification this helps a lot.

Regarding the missing mechanism: I’ve been experimenting with one possible userland implementation of automatic dependency tracking using a Proxy-based approach. Specifically, it uses:

1. deep path tracking on property access,
2. per-path subscriptions for components, and
3. notifying only components whose accessed paths change.

It’s very early and purely experimental, but sharing here in case it’s useful as a reference while I continue learning about the tradeoffs involved:

https://github.com/palacharlanarendra/granule.js

No expectation of review just exploring this space in userland to better understand how these ideas behave in practice.