some ideas towards and after react 18

[dai-shi]

(This is my personal memo, so it may not be very understandable to everyone. Anyway, putting here in public and see how it goes.)

These are just random notes for now and nothing is actually planned:

• bring useAtomValue and useUpdateAtom into core (rename to useSetAtom) 👉 feat(core): Move useAtomValue and useSetAtom to core #989
  • (core "basic" API is atom and useAtom. core "additional" API is Provider, useAtomValue and useSetAtom)
• extend store to support versionObject (how to deal with async updates) 👉 feat(core): experimental unstable versioned write for limited use case #854
• expose unstable_createStore api and allow <Provider unstable_createStore={createStore}> 👉 feat(core): unstable_createStore #922
• split vanilla bundle and react bundle 👉 No immediate plan
• make async atom value a promise and resolve type on get/useAtom? 👉 breaking(types): refine atom type and other types #713
• move devStore(devContainer) into store with DEV_ prefix 👉 refactor(core,utils,devtools): add dev methods in store #717
• drop write promise feature 👉 fix(core): no async write suspense (BREAKING CHANGE in behavior) #731

[sandren]

It's nice to see some lovely ideas for v2 already! 😀

However, I think each of these ideas that aren't breaking changes (e.g., adding extra hooks to core, exposing createStore API, etc) should be implemented as v1.x minor releases.

Also I second renaming useUpdateAtom to useSetAtom. 👍

[dai-shi]

Thanks for feedback!

It's nice to see some lovely ideas for v2 already! 😀

Note that they are really just ideas. While our focus is v1, I got some ideas that won't fit in v1, so listed them up.
It's nice to see that we can discuss at the early stage.

However, I think each of these ideas that aren't breaking changes (e.g., adding extra hooks to core, exposing createStore API, etc) should be implemented as v1.x minor releases.

I should probably say createStore might be considered after v2 (v2-alpha, or v2.0).
The whole point is we don't know the "concurrent rendering" feature fully.
When react 18 is out and if we are sure createStore API is possible (= compatible with concurrent rendering and so forth), we can consider exposing a new API. While it's technically possible, this idea is conceptually very new.

v2 is not because of some breaking changes, but because of >= react@18 dependency.

"resolve type on get/useAtom" can be in v1, but not necessarily. We would rather need more feedback in v1.

Also I second renaming useUpdateAtom to useSetAtom. 👍

btw, I wouldn't try to make breaking changes, so they would co-exist for quite a while. (not sure how confusing this is.)

[dai-shi]

Things get different if such a shim package is provided for >= react@16.8. reactwg/react-18#84 (comment)
We can keep going with v1.

[dai-shi]

(Hmmm, this is going to be hard to decide. uMS will be replaced by uSES, but it's level 2 support only. I was really hoping jotai to support level 3 in the future and that's why createStore is not exposed currently. But, if we give up level 3 and expose createStore, it will be more useful for some use cases. If level 3 is only possible with context selector, our provider-less mode won't work, anyway. So, I don't think exposing createStore is a nice idea at this point.)

[dai-shi]

On another thought, exposing createStore might be more important than supporting level 3 from the framework-agnostic perspective.

[chj-damon]

more best practices would be appreciated!

[dai-shi]

👉 #683

[dai-shi]

All done. (I will create a new discussion for further ideas.)

[wobsoriano]

Vanilla core package that can be used with other frameworks would be great!

[dai-shi]

It's technically possible, and jotai-jsx is one of PoCs. I will have another project in the future.
It has been in my head, but there's no immediate plan. We have some more tasks before that.
Thanks for your comment anyways.