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)
• Drop setSelf option (deprecate it during v2)
• Rename delay option in useAtomValue to unstable_delay (will be deprecated in the future)
• Drop loadable util in favor of unwrap (deprecate it during v2)
• Move jotai/babel to jotai-babel package

Not sure

• Drop CJS too?
• 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.

[wojtekmaj]

I'm concerned about dropping setSelf. I have a complex set of atoms that work together to create kind of "atomWithStorageWhileRevalidate" - optimistically loading user data from localStorage while at the same time loading the latest data from the server. Without setSelf, I don't see the possibility of it working.

My code:

const defaultCurrentUserState = atomWithDefault<User | null | Promise<User | null>>(
  (_get, { setSelf }) => {
    async function getUser(): Promise<User | null> {
      const response = await (networkGet('/api/users/current').catch(
        () => null,
      ) as Promise<User | null>);
      localStorage.setItem('user', JSON.stringify(response));
      return response;
    }

    const rawLocalStorageValue = localStorage.getItem('user');

    if (rawLocalStorageValue) {
      // Update the user in the background while we return the cached value
      getUser().then((nextValue) => {
        if (!isEqual(nextValue, rawLocalStorageValue)) {
          setSelf(nextValue);
        }
      });

      try {
        return JSON.parse(rawLocalStorageValue) as User | null;
      } catch {}
    }

    return getUser();
  },
);

export const currentUserState = atom<
  User | null | Promise<User | null>,
  [SetStateAction<User | null>],
  void
>(
  (get) => get(defaultCurrentUserState),
  async (get, set, nextValueOrSetter: SetStateAction<User | null>) => {
    const nextValue =
      typeof nextValueOrSetter === 'function'
        ? nextValueOrSetter(await get(defaultCurrentUserState))
        : nextValueOrSetter;

    localStorage.setItem('user', JSON.stringify(nextValue));
    set(defaultCurrentUserState, nextValue);
  },
);

[dmaskasky]

I was going to recommend moving the side-effect to onMount or to an atomEffect, but I noticed you have the side-effect on every read. Since overwritten atom is set after its read, its marked as dirty and recomputeDependents is causing an additional network request.

When reading the atom when the server has a different value:

1. atom read
2. network request
3. atom write (since not equal)
4. atom read (because recomputeDependents)
5. another network request <---- EXTRA

I don't think this is the behavior you want, particularly that your state update is triggered by atom read, which will not trigger again even if the backend state has changed. This is because the value is cached and atomRead is only recomputed when dependents have changed.

But if this code works for you then perhaps this edge case isn't important. If that is the case, either using onMount or atomEffect would be a good fit. Here's atomEffect reimplementation.

import { atom } from 'jotai'
import { atomWithDefault } from 'jotai/utils'
import { withAtomEffect } from 'jotai-effect'

async function fetchCurrentUser(signal?: AbortSignal): Promise<User | null> {
  const response = await (networkGet('/api/users/current', { signal }).catch(
    () => null,
  ) as Promise<User | null>)

  localStorage.setItem('user', JSON.stringify(response))
  return response
}

function readCachedUser(): User | null | undefined {
  const raw = localStorage.getItem('user')
  if (!raw) return undefined
  try {
    return JSON.parse(raw) as User | null
  } catch {
    return undefined
  }
}

const defaultCurrentUserBaseAtom = atomWithDefault<
  User | null | Promise<User | null>
>(() => {
  const cached = readCachedUser()
  if (cached !== undefined) return cached
  return fetchCurrentUser()
})

const defaultCurrentUserState = withAtomEffect(
  defaultCurrentUserBaseAtom,
  (_get, set) => {
    const cached = readCachedUser()
    if (cached === undefined) return

    const controller = new AbortController()
    const { signal } = controller

    ;(async () => {
      const nextValue = await fetchCurrentUser(signal)
      if (signal.aborted) return
      if (!isEqual(nextValue, cached)) {
        set(defaultCurrentUserBaseAtom, nextValue)
      }
    })()

    return () => {
      controller.abort()
    }
  },
) as typeof defaultCurrentUserBaseAtom

export const currentUserState = atom<
  User | null | Promise<User | null>,
  [SetStateAction<User | null>],
  void
>(
  (get) => get(defaultCurrentUserState),
  async (get, set, nextValueOrSetter: SetStateAction<User | null>) => {
    const nextValue =
      typeof nextValueOrSetter === 'function'
        ? nextValueOrSetter(await get(defaultCurrentUserState))
        : nextValueOrSetter

    localStorage.setItem('user', JSON.stringify(nextValue))
    set(defaultCurrentUserState, nextValue)
  },
)

[wojtekmaj]

Wow, this DOES work perfectly! Thank you SO much! I absolutely did not expect that from you 😅