Proposal for an API change that is based on hooks about recoil

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

[davidmccabe]

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

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

[adamkleingit]

No problem, thanks for your time as well!