Good practice to separate mutations from components

[KrysKruk]

Hi!

We're currently using Recoil and we're having really hard time with it. Our product is CRM-like so number of different atoms and logic is quite complex.

Our main concern is that components should not be able to change particular atoms because data is very often distributed between different atoms and it should not be a component responsibility to understand these relations in logic.

I couldn't find any helpful patterns or good practices in the Jotai documentation for such case.
From what I understand, atomWithReducer gives dispatch function but it still changes particular atom. It doesn't look like a solution to update multiple atoms.

I was experimenting with createStore which allows to update atoms outside of React. Here is an example:

const store = createStore();

const countAtom = atom(0);

async function incrementCountAtom() {
  await wait(500);
  store.set(countAtom, p => p + 1);
}

function App() {
  const count = useAtomValue(countAtom);

  return <button onClick={incrementCountAtom}>{count}</button>
}

This is of course a very simple example but such action could potentially fetch some data and update multiple atoms.

Would such approach work from your experience? Are there any other recommended ways?

[dai-shi]

Store API is exposed for certain use cases, but I wouldn't recommend it in this case, because everything is within the React world.

If I understand your problem correctly, the "Jotai" way is using write-only atoms. (It's just one practices and not all Jotai users are required to follow.)

const countAtom = atom(0);

const incrementCountAtom = atom(null, async (get, set, arg) => {
  await wait(500);
  set(countAtom, p => p + 1);
});

function App() {
  const count = useAtomValue(countAtom);
  const incrementCount = useSetAtom(incrementCountAtom);

  return <button onClick={incrementCount}>{count}</button>
}

AFAIR, Recoil doesn't allow this pattern.

[KrysKruk]

That looks good. Reading the docs I didn't truly understand how wrote-only atoms are powerful especially when they can update other atoms which is not possible in Recoil.

For a purpose of keeping all mutations in one place I could keep them in one file (although I need to use useSetAtom for each action separately) or I could make it more Redux-like:

const countAtom = atom(0);

type Action = { type: "increment" };

const dispatchAtom = atom(null, async (get, set, action: Action) => {
  await wait(500);
  switch (action.type) {
    case "increment":
      set(countAtom, (p) => p + 1);
      break;
  }
});

function App() {
  const count = useAtomValue(countAtom);
  const dispatch = useSetAtom(dispatchAtom);

  return <button onClick={() => dispatch({ type: 'increment' })}>{count}</button>
}

or, something like:

const countAtom = atom(0);

const actionsAtom = atom(null, (get, set) => ({
  async increment() {
    await wait(500);
    set(countAtom, (p) => p + 1);
  }
}));

function App() {
  const count = useAtomValue(countAtom);
  const { increment } = useSetAtom(actionsAtom)();

  return <button onClick={increment}>{count}</button>
}

which looks more elegant, but the useSetAtom(actionsAtom)() is kind of hacky?

Also both solutions with keeping all mutations in a single atom won't work if I want to self-call (set(dispatchAtom, { type: "increment2" }); or set(actionsAtom).increment2() doesn't work) so I guess it's better to keep them separately.

In Recoil we were experimenting with selector and getCallback but it doesn't really work when things get complex and one action wants to call another.

Thank you for your help. Jotai looks great!

[dai-shi]

but the useSetAtom(actionsAtom)() is kind of hacky?

Yes, that's too hacky. It wouldn't be guaranteed to work for the long term.

If you really want that actions pattern, using the Store API would be better.
But in general, incrementCountAtom and dispatchAtomare more recommended patterns.

[alirezamirian]

I'm migrating a project from recoil to jotai (which has been more pleasant than I thought so far), and I'm facing issues converting a pattern, where I have a recoil selector, which implements an interface to abstract away state management for a unit of functionality.
Example:

const editorManager = selector({
  key: "editor.manager",
  get: ({ getCallback }): EditorManager => {
    return {
      openPath: getCallback(openPathCallback),
      closeTab: getCallback(closeCallback),
      closePath: getCallback(closePathCallback),
      closeOtherTabs: getCallback(closeOtherTabsCallback)
    };
  },
});

This is useful because:

• editor manager object is created only once and is cached, since it doesn't make any call to get
• it encapsulates editor state management into a single object, decoupled from components
• I can access editorManager in react components or in recoil callbacks

Since jotai doesn't have an equivalent of getCallback function, I'm having a hard time converting this pattern.

I can of course just export those callbacks in form of (get: Getter, set: Setter, ...) => ... functions and use them both in react components and in other callbacks, but it becomes unnecessarily verbose.

Another solution would be the write-only pattern suggested in this thread, but the caveats are already mentioned above.

My main question is if there has been some thoughts about offering something similar to getCallback in Read interface, to allow for creating atoms that can hold actions instead of state?

[dai-shi]

but it becomes unnecessarily verbose.

If it's just verbose, I think you can create a reusable wrapper function.

My main question is if there has been some thoughts about offering something similar to getCallback in Read interface, to allow for creating atoms that can hold actions instead of state?

Yes, for that purpose, we have setSelf (it's not the same as what Recoil provides with the same name), but it's considered primarily for library use (ex. jotai-zustand). You can use it, but the API is a little bit tricky.

[alirezamirian]

Thanks! setSelf was actually helpful in creating an atom with "actions", though it turned out even hackier than I thought as I couldn't set self synchronously. I may still not have the right mindset in Jotai as I'm fairly new, but I have to say it's a little unintuitive the way an atom's setter is the only way to access a set function and create actions that can change state. I'd love to see if something like recoil's getCallback will be considered to be added to the atom's Read signature.

[dai-shi]

atom (read function) must be declarative or pure, so returning actions as state isn't typically recommended. atoms must be update from set. To overcome this designed limitation, we introduced store api.

It's tricky but here's one idea.

import { atom, createStore, Provider } from 'jotai';

const storeAtom = atom(undefined);
const Root = ({ children }) => {
  const store = createStore();
  store.set(storeAtom, store);
  return <Provider store={store}>{children}</Provider>;
};
const atomWithCallback = (fns) => atom((get) => {
  const store = get(storeAtom);
  if (!store) { throw new Error('Root component is missing'); }
  const set = (a, v) => store.set(a, v);
  return Object.fromEntries(Object.entries(fns).map(([key, fn]) => [key, (...args) => fn({ set })(args)]));
});

[alirezamirian]

I implemented another variation of such reusable construct with an API more similar to what I wished was available out of the box, an additional getCallback property in atom read options:

const myAtom = atomWithGetCallback( (get, { getCallback }) => ...)

Implementation

type GetCallback = <Args extends unknown[], Result>(
callback: (get: Getter, set: Setter, ...args: Args) => Result
) => (...args: Args) => Result;

type ReadWithGetCallback<Value, SetSelf = never> = (
get: Getter,
options: {
  readonly signal: AbortSignal;
  readonly setSelf: SetSelf;
  readonly getCallback: GetCallback;
}
) => Value;

const atomWithGetCallback = <Value>(read: ReadWithGetCallback<Value>) => {
return atom((get, options) => {
  const getCallback = get(getCallbackAtom);
  return read(get, { ...options, getCallback }); // write function could also be just passed here to support writable atoms too, but it's omitted for type definition brevity
});
};

const getCallbackAtom = atom<GetCallback, [], { get: Getter; set: Setter }>(
(_get, { setSelf }) => {
  return (callback) => {
    return (...args) => {
      const { get, set } = setSelf();
      return callback(get, set, ...args);
    };
  };
},
(get, set) => ({ get, set })
);

---

atom (read function) must be declarative or pure, so returning actions as state isn't typically recommended

Exposing set function to Read interface directly would definitely not make sense as atom's read function must not have side effects. But creating callbacks that will have access to get/set API doesn't violate that principle. It allows for encapsulating certain pieces of logic (that need to set or non-reactively get the state) in atoms.

https://recoiljs.org/docs/api-reference/core/selector#returning-objects-with-callbacks

But anyway, I'm happy I could achieve almost the exact same API I was looking for, with a userland implementation using setSelf.

[dai-shi]

Yeah, that looks much better.

[dmaskasky]

I'm not super familiar with Recoil, but it sounds like you are asking for a pull-based approach to encapsulating all your business logic in the data layer. You can do this using atomEffect. Does this work for your use-case?

import { atom } from 'jotai';
import { withAtomEffect } from 'jotai-effect';
import React from 'react';
import { useAtomValue } from 'jotai';

// ========================
// 1) Core State Atoms
// ========================
export const tabListAtom = atom<string[]>([]);
export const activeTabAtom = atom<string | null>(null);
export const logsAtom = atom<string[]>([]);

// ========================
// 2) One Atom (with Effect) per Editor Action
//
// IMPORTANT: Instead of doing `set(openTabAtom, openTab)`,
// we do `set(openTabAtom, { fn: openTab })`.
//
// Then, whenever we need to call that function, we destructure
// it, e.g. `const { fn } = get(openTabAtom)` or
// in a derived atom: `get(openTabAtom).fn(...)`.
// ========================

// 2.1) openTab
export const openTabAtom = withAtomEffect(
  atom<{ fn: (path: string) => Promise<void> }>({ fn: async () => {} }),
  (get, set) => {
    const openTab = async (path: string) => {
      // Simulate async operation
      await new Promise((resolve) => setTimeout(resolve, 200));

      const currentTabs = get(tabListAtom);
      if (!currentTabs.includes(path)) {
        set(tabListAtom, [...currentTabs, path]);
      }

      set(activeTabAtom, path);
      set(logsAtom, (prev) => [...prev, `Tab opened: ${path}`]);
    };

    // Instead of `set(openTabAtom, openTab)`, do this:
    set(openTabAtom, { fn: openTab });

    return () => {
      set(logsAtom, (prev) => [...prev, 'Cleanup: openTabAtom disposed']);
    };
  }
);

// 2.2) closeTab
export const closeTabAtom = withAtomEffect(
  atom<{ fn: (path: string) => Promise<void> }>({ fn: async () => {} }),
  (get, set) => {
    const closeTab = async (path: string) => {
      // Simulate side effect
      await new Promise((resolve) => setTimeout(resolve, 100));

      const currentTabs = get(tabListAtom);
      set(tabListAtom, currentTabs.filter((t) => t !== path));

      const active = get(activeTabAtom);
      if (active === path) {
        set(activeTabAtom, null);
      }

      set(logsAtom, (prev) => [...prev, `Tab closed: ${path}`]);
    };

    // Instead of `set(closeTabAtom, closeTab)`, do this:
    set(closeTabAtom, { fn: closeTab });

    return () => {
      set(logsAtom, (prev) => [...prev, 'Cleanup: closeTabAtom disposed']);
    };
  }
);

// 2.3) closeOthers
export const closeOthersAtom = withAtomEffect(
  atom<{ fn: (path: string) => Promise<void> }>({ fn: async () => {} }),
  (get, set) => {
    const closeOthers = async (path: string) => {
      const currentTabs = get(tabListAtom);
      set(tabListAtom, currentTabs.filter((t) => t === path));
      set(activeTabAtom, path);
      set(logsAtom, (prev) => [...prev, `Closed all tabs except: ${path}`]);
    };

    // Instead of `set(closeOthersAtom, closeOthers)`, do this:
    set(closeOthersAtom, { fn: closeOthers });

    return () => {
      set(logsAtom, (prev) => [...prev, 'Cleanup: closeOthersAtom disposed']);
    };
  }
);

// 2.4) logMessage
export const logMessageAtom = withAtomEffect(
  atom<{ fn: (message: string) => void }>({ fn: () => {} }),
  (get, set) => {
    const logMessage = (msg: string) => {
      set(logsAtom, (prev) => [...prev, `Log: ${msg}`]);
    };

    // Instead of `set(logMessageAtom, logMessage)`, do this:
    set(logMessageAtom, { fn: logMessage });

    return () => {
      set(logsAtom, (prev) => [...prev, 'Cleanup: logMessageAtom disposed']);
    };
  }
);

// ========================
// 3) Derived "EditorManager" Atom
// ========================
export interface EditorManager {
  openTab: (path: string) => Promise<void>;
  closeTab: (path: string) => Promise<void>;
  closeOthers: (path: string) => Promise<void>;
  logMessage: (message: string) => void;
}

export const editorManagerAtom = atom<EditorManager>((get) => ({
  // Destructure the object's `fn` property instead of taking the entire object.
  openTab: get(openTabAtom).fn,
  closeTab: get(closeTabAtom).fn,
  closeOthers: get(closeOthersAtom).fn,
  logMessage: get(logMessageAtom).fn,
}));

// ========================
// 4) Usage in a React Component
// ========================
export function EditorUI() {
  const manager = useAtomValue(editorManagerAtom);
  const logs = useAtomValue(logsAtom);

  const handleOpenTab = () => manager.openTab('my-file.txt');
  const handleCloseTab = () => manager.closeTab('my-file.txt');
  const handleCloseOthers = () => manager.closeOthers('my-file.txt');

  return (
    <div>
      <button onClick={handleOpenTab}>Open Tab</button>
      <button onClick={handleCloseTab}>Close Tab</button>
      <button onClick={handleCloseOthers}>Close Others</button>

      <h3>Logs:</h3>
      <ul>
        {logs.map((log, i) => (
          <li key={i}>{log}</li>
        ))}
      </ul>
    </div>
  );
}

[alirezamirian]

Thanks for the elaborate suggestion @dmaskasky! Yeah I guess effect can also be used like you suggested. Not sure if it would have any advantage over a write-only atom for each action.

[dmaskasky]

It depends on your use-case ad preference. The Jotai way is push based. jotai-effect makes pull based available if it makes sense.