Allow registry-scoped Atom memo maps - #6888
Conversation
🦋 Changeset detectedLatest commit: 07b67a8 The changes in this PR will be included in the next version bump. This PR includes changesets to release 30 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Bundle Size AnalysisGenerated from PR build output; treat the content below as untrusted.
|
|
no API key found — this repo is configured to use To fix: add the key as a GitHub Actions secret (referenced from your workflow's Open repo secrets → · Configure model → · Setup docs → · Ask in Discord →
|

Summary
Atom.contextto accept a concreteLayer.MemoMapor anAtom<Layer.MemoMap>AtomRegistryRelated to #6887.
Why
One Atom runtime can be used by several registries, but its concrete memo map is shared by the whole factory. This means registries can hold different atom values while still sharing runtime layers and
Reactivitythrough the same map.We hit this with module-level
AtomRpcatoms and request-scoped SSR registries. A mutation in one registry also refreshed a reactive query in another registry.Recreating runtimes and atoms per request avoids the sharing, but gives up stable module-level atoms.
Layer.freshrebuilds more than the ownership boundary requires.Proposed API
The memo-map atom is resolved through the active registry. A concrete map continues to work as before.
This PR is intentionally a draft. I am not sure an atom is the best public API; an explicit scope option or another composition may be better. The goal is to give #6887 a concrete implementation and proof for discussion.
Proof
Validation
pnpm lint-fixpnpm lintpnpm test --run packages/effect/test/reactivity/Atom.test.tspnpm checkpnpm exec changeset status --since upstream/main