Ideas for v3

[dai-shi]

Nothing determined. ETA is year 2026.

• Drop old TS versions
• Drop UMD/SystemJS builds
• Module-first package.json
• 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
• Consider dropping INTERNAL_overrideCreateStore if jotai-devtools can have a good DX without it.

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

[dai-shi]

It should be already possible.

const usePeekAtom = (atom) => {
  const store = useStore();
  return () => store.get(atom);
};

[dmaskasky]

You can literally do anything with the new Jotai API. 🦄

type GetterWithPeek = Getter & { peek: Getter }

function atomWithPeak<T>(
  read: (getterWithPeek: GetterWithPeek, options: Options) => T
) {
  const refAtom = atom<{ peek: GetterWithPeek }>(() => ({}))
  refAtom.debugPrivate = true
  const baseAtom = atom<T>((get, options) => {
    const { peek } = get(refAtom)
    const getterWithPeek = Object.assign(get, { peek })
    return read(getterWithPeek, options)
  })
  baseAtom.onInit = (store) => {
    store.get(refAtom).peek = store.get
  }
  return baseAtom
}

[dai-shi]

I don't think the refAtom hack is necessary in this case. Or, I'm not sure if it triggers extra renders.

I would also avoid modifying get. Just a preference though.

function atomWithPeek(read) {
  const peekAtom = atom();
  const baseAtom = atom((get, options) => {
    const getterWithPeek = (a) => get(a);
    getterWithPeek.peek = get(peekAtom);
    return read(getterWithPeek, options);
  };
  baseAtom.unstable_onInit = (store) => {
    const peek = (a) => store.get(a);
    store.set(peekAtom, peek);
  };
  return baseAtom;
}

[dmaskasky]

Looks good.

I don't think enough people are aware of the power of this new api. It might be a good candidate for a blog post or a tweet maybe.

[dai-shi]

It's too powerful and not recommended for most app developers, I'd rather think.