best practise using jotai in big project?

[chj-damon]

Now I just treat jotai as state management tool, but I think jotai can do more than that.
I read the docs, and noticed that maybe I can write my logic in the derived atom and I don't need to put them in custom hooks anymore.

simply like this:

const countAtom = atom(1)
const asyncIncrementAtom = atom(null, async (get, set) => {
  // await something
  set(countAtom, get(countAtom) + 1)
})

const Component = () => {
  const [, increment] = useAtom(asyncIncrementAtom)
  // it will suspend while `increment` is pending.
}

but then my question is, how should I organize the atom structure? should I put theme together or split them into serval files?
when should I use atom, and when shouldn't I use it?

all the examples in the doc is too simple. Is there any best practices to demonstate the best way of using jotai?

[dai-shi]

noticed that maybe I can write my logic in the derived atom and I don't need to put them in custom hooks anymore.

Yeah, I noticed that too. Now, I would write all logic in atoms and I wouldn't use custom hooks. (Especially, that would allow me to run the app in my experimental jotai-jsx.)

how should I organize the atom structure? should I put theme together or split them into serval files?

It's still an open question. I think both are valid. I'd prefer splitting atom files and only exporting atoms that are necessary.

Is there any best practices to demonstate the best way of using jotai?

I think we are still at the stage of building best practices. Help wanted.

[merriman-xyz]

Yeah, I noticed that too. Now, I would write all logic in atoms and I wouldn't use custom hooks. (Especially, that would allow me to run the app in my experimental jotai-jsx.)

Any updated thoughts on this?

I've been trying to keep all logic within atoms within my project. I use a lot of action atoms that also call other action atoms.

An example is a queryPersonAtom action atom that sends a GET request to the backend using another action atom getAtom:

export const queryPersonAtom = atom(null, async (get, set, query) => {

  if (query.trim() === '') return []

  const params = new URLSearchParams()
  params.append('q', query)

  return await set(getAtom, { path: `/person-search?${params.toString()}` }) // How to make more explicit?

})

export const getAtom = atom(null, async (get, set, { path }) => {

  const currentUser = get(currentUserAtom)
  const token = `bearer ${currentUser.token}`
  const authConfigHeader = { headers: { Authorization: token } }

  try {
    const { data } = await axios.get(`${baseUrl}${path}`, authConfigHeader)
    return data;
  } catch (err) {
    if (err.response.status === 401) {
      set(handleUnauthorizedUserAtom) 
    } else {
      throw err
    }
  }

})

Usage:

const [,queryPerson] = useAtom(queryPersonAtom)
// or
const queryPerson = useUpdateAtom(queryPersonAtom)
...
queryPerson('Jotai')

Is there a better way to handle this or is this the Jotai way? Or is this totally off-base?

I'm a bit tempted to go back to custom hooks because the syntax isn't as clear as I'd want. I wish:

• there was a more explicit way to indicate an atom is a pure action atom (like actionAtom or the like )
• there was a more explicit way to call actions atoms within an atom instead of set(actionAtom), maybe this is feasible with with a call field in an atom (actionAtom({set, get, call, data} => { const result = await call(getAtom, data); set(resultAtom, result) })
• there was a more explicit way to indicate an atom is a pure action atom when using (perhaps useActionAtom)

Any comments would be helpful.

Thanks.

[dai-shi]

is this the Jotai way?

Yes. At the same time, I see your confusion, and it's totally fine to go with hook based approach.

a pure action atom

Well, the action atom is a by-product of writable derived atom, and it's just a pattern.
So, there's no notion of "action atom" in the library code.

I think you can build almost what you want with the public API.

const ACTION_ATOM = Symbol()
const actionAtom = (fn) => atom(ACTION_ATOM, (get, set, data) => {
  const call = (a, d) => {
    if (get(a) !== ACTION_ATOM) {
      throw new Error('cannot call non action atom')
    }
    set(a, d)
  }
  return fn({ set, get, call, data })
})

[merriman-xyz]

Thanks for the response @dai-shi.

[tarngerine]

++ to putting as much mutation logic into writable atoms! it gives a nice separation similar to MVC where jotai atoms handle Model and Controller, and React FC handles View.

these are some incomplete thoughts, but some best practices i've observed in my own work (two spatial tools: https://sprout.place & https://felt.com)

• start your project off putting all your atoms and writable atoms into one file, i.e. atoms.ts. This is similar to how a lot of typescript projects start off using a single types.ts. i tried prematurely splitting atoms into different concerns but it always came back to bite me. unless tsc times get really long, it's not really worth splitting up. i put all my 'Model' state atoms up top, and all the 'Controller' WritableAtoms below.
• atoms that are only relevant to a single component/subsystem can colocate with the component. a good example i often run into is:

// atoms.ts
// ID of the selected element, used in a lot of places
const selectedElementId = atom<string>("");

// Element.tsx
// Only Element.tsx cares if its selected, and we can reduce rerenders with an atom family
const isSelectedFamily = atomFamily((id) => atom((get) => get(selectedElementId) === id)));

function Element(id) {
  const isSelected = useAtomValue(isSelectedFamily(id))
}

• one thing i do often is write a custom hook to quickly make using a frequently used atom/writableatom faster (so I don't have to import both the atom and the useAtom/useUpdateAtom/useAtomValue). another benefit to this is that you can group multiple related writable atoms/atom states into one shared hook

// writable atoms, don't export these
const selectElementAtom = atom(null, ()=> ...)
const toggleElementAtom = atom(null, () => ...)
// export the hook, so you only have to import one thing
export function useSelectElement() {
  return {
    select: useUpdateAtom(selectElementAtom),
    toggle: useUpdateAtom(toggleElementAtom)
  }
}

some other best practices im still figuring out, curious to hear other peoples patterns!

[dsacramone]

some other best practices im still figuring out, curious to hear other peoples patterns!

Hey @tarngerine ,
I love your expressiveness in your usage of Jotai. Since its been a few months, I am curious if you have updated your patterns/usage? I'd love to hear them. Perhaps if you have them in a gist/github? I am currently thinking of jotai, but the patterns of usage that i have seen for large websites just isn't there... I mean, I haven't seen any. The patterns I've seen usually revolve around a "todo" or "counter", which are not helpful beyond a rudimentary implementation. Curious how your patterns have changed over time. - Thanks

[tarngerine]

towards the end of my last project we actually started migrating towards using valtio instead of jotai (thankfully they can be used in concert so last i remember it was half - half) because the useState style setter/getter while "reacty" ultimately ended up being much more verbose and annoying to write out. valtio allows you to write much cleaner "vanilla JS" code and felt often more predictable (i often ran into hard-to-repro jotai bugs where a derived atom wouldn't update — haven't run into one in valtio yet).

[dsacramone]

Thanks for your response. If I may ask additionally --
What kind of patterns are you using with Valtio? Also, do you have any concerns with managing proxy state in a large app with multiple devs -- since anything can be proxied, you could run into an issue of a dom being put in, and then proxied up and down it? Also, do you find using "derive" for catching reactive updates (derived/computed state) a lot of boilerplate or are there other ways you use to get that computed state in react?

Also, are you allowing devs to set the state anywhere, or do you use a pattern in which setters (in a file) need to be adhered to, else you could global being set all over the app, and never be none the wiser?

[tarngerine]

on the question of when to use atom/when not to, this is something i've discussed often with my friends — in particular, one pattern i see a lot is how to capture some state from one component and pass it to a newly created component

this specifically comes up in drawing tools type interaction — select a Text Tool, then create a new Text Element. This new Text Element should autofocus — but how does the newly created Text Element know if it's actually just created, or if it's only being remounted (i.e. on refresh)

one way would be to use an atom, i.e. const justCreatedElementIdAtom = atom<string>("")

and in TextElement, we just look at if the ID matches

const isJustCreatedFamily = atomFamily((id) => atom(get => get(justCreatedElementIdAtom) === id))
function TextElement(id) {
  const shouldFocus = useAtomValue(isJustCreatedFamily(id));
  return <textarea autoFocus={shouldFocus} />
}

however, it might feel overkill, because it doesn't REALLY need to be reactive, as it'll only ever happen once to an element. the alternative here would be to make this justCreatedElementId not an atom, but a simple module variable let justCreatedElementId = ""

and then we just check it on mount to focus the element imperatively, or we could use a shouldFocus useState locally

function TextElement(id) {
  const textareaRef = useRef(null);
  useEffect(() => {
    if (justCreatedElementId === id) textareaRef.current?.focus();
  }, []);
  return <textarea ref={textareaRef} />
}

this is def one of those situations where I'm like "is an atom appropriate?" and it always comes back to "does it need to be reactive? or can it simply be checked imperatively"

[xadh00m]

I´m wondering how to model the lifecycle of atoms.

Using React contexts all contained state (e.g. in useState hooks) is removed as soon as we stop rendering the context provider. This comes in handy if you have an app with two pages where one page e.g. needs a websocket connection to the backend (and some additional state) which can be wrapped up in a Page1Context and a completely different context for the second page. When switching between both pages the page state (including the websocket connection etc.) is created/removed accordingly.

Atoms on the other hand look like global entites which are never GC´ed. Do I miss something?

[dai-shi]

Even if atom configs are defined at module level, they don't hold values. It's <Provider> that holds values. Essentially, it's just based on React Context. Please try using Jotai's Provider where you would use React Context Provider.

[xadh00m]

@dai-shi Thank you for the tip. I wasn´t aware of the tight coupling with React Context. This makes sense especially for bigger projects.

Does Jotai require a context bridge for react-three-fiber ?

[dai-shi]

If we use a default store (called Provider-less mode), then we don't need the context bridge (and we don't get much benefit from Context either).

If we use a Provider, it doesn't work with r3f. (we once provided a context bridge function, but removed before v1.)
For the future, hopefully #861 will be a solution in such use cases.

[chj-damon]

I didn't get a good idea about dealing with other hooks from third-party libraries, such as react-navigation.
for example, I need to do some logic and then navigate to other screens. I can use const navigation = useNavigation() which useNavigation is a custom hook from react-navigation library. I can do this in custom hooks, but as we discussed above, If we write all these logic in derived atoms, how can I do that? because Hooks can only be used in hooks.

[dai-shi]

If we write all these logic in derived atoms, how can I do that?

Yeah, this would require a library such as react-navigation to provide non-hook APIs.
For example, jotai/query uses react-query's non-hook APIs. So does jotai/urql.
Essentially, jotai's atom definitions are framework agnostic.

[chj-damon]

https://reactnavigation.org/docs/en/navigating-without-navigation-prop.html
now I can do it!

[dizzyjaguar]

Hey is there a "TL;DR" summary, of the best practices? Or any consensus?