Ideas for v3

[dai-shi]

Nothing determined. ETA is year 2026.

Plan for v3

• Drop old TS versions
• Drop UMD/SystemJS builds
• Module-first package.json
• Drop React < 18
• Do not use use in useAtomValue (migration path: add { use: true } option which is true by default in v2, and warns it)
  • New idea 👉 feat: add allowTearing option in useAtom and useAtomValue to avoid double render on initial mount. (fix #1137) #3133 (comment)
• Move atomFamily util to jotai-family package (deprecate it during v2)

Not sure

• Drop CJS too?
• Drop delay option in useAtomValue (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 INTERNAL_overrideCreateStore if jotai-devtools can have a good DX without it.

Not for v3

• 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.

[sebinsua]

@dmaskasky Regarding atomWith* to with* is that purely a naming change or is the idea for these functions to receive atoms and return atoms so they are kind of high-ordered wrappers?

[dmaskasky]

@dmaskasky Regarding atomWith* to with* is that purely a naming change or is the idea for these functions to receive atoms and return atoms so they are kind of high-ordered wrappers?

The latter. So you can do

const countAtom = atom(0)
comst countWithLoggerAndStorage = withLogger(withStorage(countAtom))

[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.

[marcebdev]

I'm not sure on feasibility but being able to have some .peek like functionality (not that naming has to be this, but to have an example) maybe even something like

const peekForm = usePeekAtom(myFormAtom)

function formSubmit() {
  const formState = peekForm()
  ...
}

When a value can be explicitly checked on a specific event call (like form state on onSubmit) it would be really nice & beneficial because you wouldn't have to subscribe the parent to the state at all.

[marcebdev]

@dai-shi would you happen to have an example of how the atomWithPeek util would be used? I'm trying to give it a shot and realize I don't really understand how the read argument works, or at least how I end up being able to peek the actually works. Ended up trying

const testAtom = atom('hello world')
const peekableAtom = atomWithPeek((get) => get(testAtom))

...

const peek = useAtomValue(peekableAtom)

I think I don't have the types correct atm but I got to something like this. I couldn't use the Getter type directly bc it would complain that .peek doesn't exists on getterWithPeek.peek

export function atomWithPeek<T>(read: Read<T>) {
  const peekAtom = atom<PeekAtom<T>>()

  const baseAtom = atom((get, options) => {
    const getterWithPeek = <Value>(a: Atom<Value>) => get(a)
    getterWithPeek.peek = get(peekAtom)
    return read(getterWithPeek, options)
  })

  baseAtom.unstable_onInit = (store) => {
    const peek = <Value>(a: Atom<Value>) => store.get(a)
    store.set(peekAtom, peek)
  }

  return baseAtom
}

[dmaskasky]

https://codesandbox.io/p/devbox/unruffled-taussig-yj7q5f?workspaceId=ws_C9Ksjj78sgjEf6XMmWZ1Fr

[dai-shi]

@marcebdev FWIW, I'd recommend usePeekAtom as a straightforward solution.
#2889 (reply in thread)

[marcebdev]

Thank y'all both so much! Honestly I didn't even realize useStore just works with the Provider I thought you could only use it with createStore so I just tried it and that worked well and was super simple too!

[organize]

I've found useAtomCallback helpful when I want "atom scope" non-reactively:

const formSubmit = useAtomCallback(
 useCallback((get, _set) => {
  const form = get(myFormAtom)
  ...
 }, [])
)

It's particularly useful when dealing with a lot of dependencies and requiring setters. It also allows me to arbitrarily batch set calls (as long as you don't also get the atom you're setting).

[himself65]

Do not use use in useAtomValue (migration path: add { use: true } option which is true by default in v2, and warns it)

If remove the use, I think it would looks weird?

const value = use(useAtomValue(atom))

[dai-shi]

Yeah, but I don't think it's too weird. It's not yet widely used, but use is still new.

[dai-shi]

https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more#concurrent-stores
I'll wait for it...

[dmaskasky]

I read the page but I still don't understand what has been planned in terms of functionality.

[a10nik]

Drop React < 18
Do not use use in useAtomValue

BTW use() is only available since react v19. Folks with v18 should be fine as long as { use: true } exists but once it's obsolete we should either drop v18 as well or recommend a use() polyfill, right? Likely, this one? https://github.com/dai-shi/react18-use

[dai-shi]

Yes, that's what I did in valtio.

[organize]

For useAtomValue, I find myself wanting for a couple of things:

1. The ability to pass in a custom equality check in place of Object.is
2. The ability to pass in an ad-hoc selector (e.g. (value: Value) => Out)

The first one seems simple implementation-wise, but I'm not sure of the implications. Use cases are a bit niche, but it might be reasonable band-aid in some cases.

Second one less so. Basically, I just want to avoid re-renders, but having to write tons of selectAtom/focusAtom is slightly tedious, and while I can write a home-brew hook for this, it should be a fairly common use case.

Any thoughts? Does this make any sense?

[dai-shi]

I assume both are niche, or not typical. I'd suggest creating your home-brew custom hook. Or, if you would like to create a third-party library, it'd be an option.

(The rationale is that Jotai is developed to avoid such selectors (or custom equality function) with atoms.)

[iwoplaza]

Consider dropping unwrap util (migration path: recommend loadable or jotai-derive)

Currently, both unwrap and loadable use their own internal cache for tracking the status of Promises, which means if we want to inspect if an async atom has already fulfilled or not, we always need to wait a tick before getting its value. I wanted to implement a way to inspect eager atoms in this way for jotai-derive (now jotai-eager), but that would essentially be duplicating what unwrap and loadable already do, just with a shared Promise cache.

For now, I reimplemented unwrap and loadable in jotaijs/jotai-eager#13, with a few changes:

• Shared Promise cache, so they can share information about their statuses and reduce unnecessary suspensions.
• Renamed unwrap to withPending, with the ability to provide a pending fallback (just like unwrap) that can be based on the previous value, the pending promise, or the value of another atom.
• Removed memoization from withPending. This is because it wasn't obvious that the second argument to unwrap has to be stable in order for it to not return a new atom on every call. The name change to withPending was also motivated by trying to discourage devs from running it in hot paths, as it's understood that with* calls create a new atom.

Since jotai-eager's loadable has the same behavior as jotai's loadable for vanilla atoms, it would be possible to drop both loadable and unwrap utils in Jotai v3.

[dai-shi]

Yeah, that's one idea. btw, that reminds me of using attachPromiseStatus instead of WeakMaps.

[wojtekmaj]

Regarding dropping CJS - I don't think this should even be a question. 99,9999% of Jotai users are using some kind of bundler, all of which support ESM just fine. The remaining 0,0001% would be users using pure ESM modules, in which case... Well... They're using ESM modules :D

[dai-shi]

Quite a few users may use Jotai in SSR, and they use it without knowing it. Recent Node.js versions are capable of importing ESM from CJS, so it will be fine.