[idea] add pending to store.unstable_derive

[dmaskasky]

Summary

Improves capability of unstable_derive store api. Pending is a good candidate to represent a transaction primitive. These changes make it possible to have fine-grained control over the atom lifecycle.

Details

• Adds createPending to StoreArgs
• Shares pending with all StoreArgs
• Adds flushPending to StoreArgs

Check List

• pnpm run prettier for formatting code and docs

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
jotai	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 12, 2024 1:50am

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[github-actions]

Preview in LiveCodes

Latest commit: 2fcca60
Last updated: Dec 12, 2024 1:49am (UTC)

Playground	Link
React demo	https://livecodes.io?x=id/FV69V987V

---

See documentations for usage instructions.

[dmaskasky]

prevPending is the in-context upstream pending. For instance, unsubscribe's invocation of createPending receives subscribe's pending.

[dai-shi]

This is pretty close to our rejected idea (ref #2741), so I have a big hesitation.
Technically, it's good and makes things flexible, but my concern is if developers other than you can understand it. Unless we have urgent use cases, I believe we shouldn't rush. (Just curious if this helps jotai-scope.)

In any case, my plan for this is after we finalize "sync effect". So, converting to draft for now. (already converted. 😄 )

[dmaskasky]

Just curious if this helps jotai-scope.

Yeah, I was thinking that too. I think I prefer this pattern over some sort of hooks pattern for low-level store api.

[dmaskasky]

This is pretty close to our rejected idea (ref #2741), so I have a big hesitation.

The big difference in my mind is that pending gives a place for extra details about the transaction to be processed. The difficulty we had with the earlier idea with passing originalAtomState was that the notion of from was a bit opaque.

Say we had A -> B -> C. C's from would be B, but originalAtomState would be A's state.

Now with flushPending, we are free to implement our own linked list or whatever.

This might be something to consider if the need ever arises.