Embrace connections to functional programming

[probeiuscorp]

Jotai is a very exciting library because it is a state monad:

const pure = atom satisfies (<T>(a: T) => Atom<T>)
function map<T, V>(anAtom: Atom<T>, fn: (a: T) => V): Atom<V> {
  return atom((get) => fn(get(anAtom)))
}
function join<T>(nestedAtoms: Atom<Atom<T>>): Atom<T> {
  return atom((get) => get(get(nestedAtoms)))
}

Notably, the atom getter is Haskell's monad do-notation (and by extension, JavaScript's own async–await) — compare:

const xAtom = atom(0)
const yAtom = atom(0)
const vAtom = atom((get) => {
  const x = get(xAtom)
  const y = get(yAtom)
  return { x, y }
})

with

const xPending = Promise.resolve(0)
const yPending = Promise.resolve(0)
const vPending = (async function() {
  const x = await xPending
  const y = await yPending
  return { x, y }
})()

and (in Haskell)

xAtom = atom 0
yAtom = atom 0
vAtom = do
  x <- xAtom
  y <- yAtom
  return $ V2 x y

Documentation

I think the fact that Jotai is a monad should be mentioned in the README:

• It will point users to all the knowledge and patterns out there on how to handle monads, such as sequence,
• It's compelling to know 60 years of mathematics and 40 years of programming theory are the foundation of the library,
• It's a theoretical basis for Jotai's unified atom concept over Recoil's split concepts of atoms and selectors.

Quality of life improvement

As a separate wish, I think adding the Functor instance on the atom prototypes would be extremely useful, most of all for curried functions:

const line = (m: number, b: number) => (x: number) => m * x + b
const xAtom = atom(0)
const yAtom = xAtom.map(line(3, 10))

Moreover, .map could be implemented quite a bit more efficiently than the atom–get sandwich as well, if it was worth increasing the internal and testing surface area (which would admittedly be by a lot).

[dai-shi]

Hey, thanks for opening up the discussion.

Documentation

I think I almost understand what is said, but tbh, I'm not super familiar with FP.
So, for now, it's a bit hard for me to add something in README with confident.
Meanwhile, would you please send a PR that adds ./docs/basics/<something>.mdx to describe what you believe to help?

Quality of life improvement

I wouldn't add such capabilities to atom right away, but adding a new util atomWithFunctor would be possible.
How does that sound? Maybe a separate package jotai-fp for a start?

[probeiuscorp]

Yes, that would work and is what I do in my own code for now. However, I don't think naming it map is reasonable in terms of cluttering up the import namespace (I like to call lots of variables map!), and mapAtom is something I've probably already called an atom. For functions where the noun meaning and verb meaning are ambiguous (like in map and key), I've taken to using something like mappedAtom.

So it's usable, but functors are about the fantastic ergonomics, and having to import such a fundamental operation, under a long name, and having to reverse to Verb-Subject-Object in JavaScript's syntax is not quite as nice.

For code size, without adding optimizations for .map, this commit should do it, while also adding a prototype users could mess around with (if that's a plus).

[dai-shi]

Okay, the code increase is minimal. (Adding the prototype is a different story, which I have thought about before, but I'm not sure about pros and cons. Especially performance drawback.)

Another concern of mine is education. We aim at the minimal API surface. I would like to get more feedback on this. (For me if we allow .map, it's hard to deny other methods, which I would like to avoid. So, it's unlikely to happen unless majority of users understand FP...)

In the meantime, please work on the guide in docs, and jotai-fp. mapAtom sounds good.

[dai-shi]

having to import such a fundamental operation, under a long name

Just one thought on it. It's the convention in Jotai ecosystem. I would say it's by design. For example, focusAtom from jotai-optics. This style allows minification, which is important for the frontend code.

[probeiuscorp]

Docs PR is in! #2726

[dmaskasky]

One suggestion is to use with* syntax convention when adding functionality to jotai atoms.

[dai-shi]

mapAtom sounds good.

Actually, there're some use cases without FP context, I'm probably comfortable to add mapAtom in jotai/utils.

[dai-shi]

One suggestion is to use with* syntax convention when adding functionality to jotai atoms.

Naming conventions are hard. We have some verb+"Atom" functions.

https://x.com/dai_shi/status/1550803662292779008

[dmaskasky]

Naming conventions are hard. We have some verb+"Atom" functions.

https://x.com/dai_shi/status/1550803662292779008

The rule I follow is if the function accepts an atom and returns a clone of the atom with some added functionality, then I use the withFoo convention.

Otherwise if the function does not accept a target atom, then I use the atomWithFoo convention.

[dai-shi]

#2726 (review)

@probeiuscorp Can you check this thread? https://x.com/hiddenwaterways/status/1832621724351050117

[probeiuscorp]

Crazy that Twitter doesn't let you see the original post without creating an account...
I don't want to split the conversation, but if that thread is the right place to discuss then I'll put more of my thoughts there.

[dai-shi]

I think it's better to have discussions/responses here and respond with the link to the tweet. Twitter is good for getting quick feedback.

[dai-shi]

Here's another feedback: https://social.treehouse.systems/@jnkrtech/113100237276852916

[probeiuscorp]

From the feedback and with some more thought, I think these are the changes I'll work on tomorrow. I'll make the 2nd paragraph a little more concise to avoid getting into being another monad tutorial, and I'll add a list of links at the current end, pointing to things like Traversables. After that I think a few sections of code samples featuring the traversables would be helpful.

[probeiuscorp]

Another PR is in, #2729. After working on this some more I am less sure about adding .map as a library, as I could see users wanting an "iso" functor instance for free:

function map<T, V>(atom: Atom<T>, fn: (a: T) => V): Atom<V>
function map<T, V>(atom: PrimitiveAtom<T>, fn: (a: T) => V, undo: (b: V) => T): PrimitiveAtom<V>

In which case I could see users wanting to wrap both fn and undo into an object, where then what the fields names should be is way beyond the opinions Jotai should probably take. So, I wouldn't say I'm in favor of adding .map anymore.