Recoil: Proposal for an API change that is based on hooks

[adamkleingit]

Recoil is a great initiative. I'm excited about the idea of a standard state management library for React, that will be heavily adopted in the React community globally.

I would like to suggest 2 changes to the API:

1. Use hooks inside atoms, like how we manage local/context state.

Here is a basic example:

const useTextState = atom(
  {
    // instead of default, we give a function that can call hooks, just like a component/custom hook
    value: () => useState(''),
    key: 'textState',
  }
);

function TextInput() {
  // No need to wrap the subscription hook with useRecoilState
  const [text, setText] = useTextState();

  ...
}

One atom can use other atoms directly (because it relies on hooks):

const useCharCount = atom({
  value: () => {
    const [text] = useTextState();
    return useMemo(() => text.length, [text]);
  },
  key: 'charCount'
});

We can even have side effects inside atoms:

const useTextState = atom({
  value: () => {
    const [text, setText] = useState(() => /* get from local storage */);
    useEffect(() => /* persist to local storage */, [text]);
    return [text, setText];
  },
  key: 'textState'
});

Or, if we already have a custom hook for persistence to localstorage:

const useTextState = atom({
  value: () => usePersistedState('', LOCAL_STORAGE_KEY),
  key: 'textState'
});

And finally, we could also supply selectors to the subscription hook:

function TextInput() {
  // Will only re-render if the selector result is changed
  useTextState(textState => textState[0].length);
  ...
}

Alternative API (value is the first param):

const useTextState = atom(() => useState(''), {key: 'textState'})

Benefits:

• Easier to migrate from local/context state to shared state, because we manage it with hooks the same way
• More freedom inside the atom to use all React hooks - useState, useReducer, useMemo, useEffect or a combination of states that are encapsulated (just like a custom hook)
• Can use existing custom hooks inside atoms (like the usePersistedState example above)
• We could potentially display atoms inside the React devtools just like components and examine their state
• We get the benefits of hooks ESLint rules
• More straightforward way to use one atom from another atom
• Can use selectors as a parameter, like in redux hooks implementation

Cons:

• Pretty big refactor
• Requires a change from React side to support using hooks inside atoms
• Migration of existing Recoil users

2. Use the reference (of the object, or value function) as a unique key, not a string

Here is a basic example:

const useTextState = atom(
  {
    value: () => useState(''),
    // debugName is only for debugging / displaying in the React devtools
    debugName: 'textState',
  }
);

Pros of using references as keys:

• Better reusability because we won't use string keys to identify the atoms. If you introduce a 3rd-party atom there won't be a chance for name clash

Cons of using references as keys:

• Can't serialise/deserialise the entire state tree

I know this is quite different than what you intended, and quite a big change, but if any of the suggestions sparks a positive reaction and makes sense to you I'm willing to help with coding it. I already created a library with a similar API (ReusableJS) that we are using in our company, but I would much rather ditch maintaining another state management library if there was something official from Facebook.

Thanks for your time!

[davidmccabe]

Thanks for your interest, and I'm definitely eager to hear about the ways everybody thinks of improving Recoil.

For 1, I'm not sure I understand how the construct you're proposing is different from just a hook.

For 2, serializability is a key requirement.

[adamkleingit]

For 2. I understand the tradeoff.

For 1. it actually also breaks down to 2 separate things:
1.1. The atom currently behaves similar to a "useState", meaning it has a default value, and returns a tuple of [state, setState].
I'm suggesting to expand it to a function that uses whatever hooks inside - useState, useReducer, useEffect, useMemo, etc.

The main benefits - we could use existing custom hooks inside the Atom, create effects, and a bit more complex constructs.

1.2 The atom currently returns a construct that can be used with useRecoilState.
I suggest to return a hook that already uses the atom. Together with 1.1, this will allow to use one Atom from another Atom, and also provide a selector.

I hope I'm not just wasting your time with this :) It's just that our experience with such an API really proved to be intuitive and powerful among developers who used it.

[davidmccabe]

Thanks for the input, I really appreciate that you'd take the time to explain your ideas more.

[adamkleingit]

No problem, thanks for your time as well!