Ideas for v3

[dai-shi]

Nothing determined. ETA is year 2026.

• Drop old TS versions
• Drop UMD/SystemJS builds
• Drop React < 18
• Drop delay option in useAtomValue (deprecate it during v2)
• Do not use use in useAtomValue (migration path: add { use: true } option which is true by default in v2, and warns it)
• Move atomFamily util to jotai-family package (deprecate it during v2)
• Consider dropping unwrap util (migration path: recommend loadable or jotai-derive)
• Consider dropping setSelf option if .unstable_onInit can replace all utils, and "actions in value" pattern
• Consider dropping .onMount if withMount util works in v2
• Consider dropping signal option if withSignal util works in v2

[ryansobol]

Perhaps consider adding aliases for the useAtomValue and useSetAtom functions that more closely align to the concept of read and write atom config functions. For example:

• useAtomValue aliased to useAtomRead
• useSetAtom aliased to useAtomWrite

Benefits:

• Would ease the onboarding for newcomers trying to construct a mental model for atom config functions
• Would ease code reviewing for all trying to understand the expansion/contraction of component behavior to/from the useAtom function
• Would allow for experimenting with new names without breaking existing code, deprecating and providing a migrator tool when appropriate

[dai-shi]

Naming is hard. There will be pros and cons. At a glance, useAtomRead is confusing to me as I would expect it returns the read function. Thanks for the suggestion, but I don't believe we should change this.

[dmaskasky]

How about:

• migrating all atomWith* utilities in jotai/utils to with*?
• moving dev store methods to createDevStore under jotai-utils

[dai-shi]

If I were to take those ideas, my plan would be to do these during v2,

• providing with* utils by jotai-utils package
• moving deriveDevStore to jotai-devtools package

Note that major version bump of libraries is nothing fancy. It's best if people wouldn't notice anything with migrating.

[dmaskasky]

If we decide to do both, I think we should probably make both available in v2 and deprecate both original apis. Then remove them completely in V3. It would be less api for the user to grok and less for us to maintain.

[a10nik]

What about reducing the coupling with react? It's an optional dep already, what about taking a step further and extracting the react-specific logic into a separate package? It might pave a path for the other framework integrations to follow. BTW, are there any plans to start advertising jotai as a multi-framework solution? Are there any react/Suspense-specific hacks in the core logic now?

I've seen Vue integration discussed in #1811, however the 3rd-party package mentioned there jotai-vue seems dead

[dai-shi]

Are there any react/Suspense-specific hacks in the core logic now?

Not particularly (except for one I would like to refactor). But I don't have any such plans either. I'd say it's more about our React-first mental model for Zustand, Jotai, and Valtio. (So, it's not just about Jotai.)

Unless there were a huge demand (like if Astro said they would pick it as their official state management solution), I wouldn't go that direction.

the 3rd-party package mentioned there jotai-vue seems dead

That actually tells the demand.

[dai-shi]

I don't mean I never thought about it. I created https://www.npmjs.com/package/jotai-core for that purpose.

What I mean is the decision wouldn't come from looking at React users. So, my question is if there will be dedicated long-term contributors and users for jotai-vue, jotai-svelte and so on.