Implement native map and bind functions for RecoilState

Having a correctly implemented map and bind for a type allows for very powerful abstractions and data transformations.

I have an implementation that given a recoil value it creates a selectorFamily that accepts a lifted function (via constSelector), which then fetches the dependencies, and then returns the new value.

Bind we somewhat get for free as recoil automatically flattens recoil values, so it’s the same logic as map.

I’m not terribly confident that this can’t somehow cause name conflicts at some point, and having a native implementation of these functions would be great.

I think this also ties in a bit with #314 as ideally the mapped value wouldn’t cause a re-render when the parent changes if the resulting output didn’t change (such as a simple number atom that had something like this applied: myAtom.map(x => x * 0)

[drarmstr]

@Shmew - The AST Explorer is a great tool for testing out AST rules for ESLint. The rules also need tests with ESLint Tester using Jest. The tricky part is probably just determining if we are in the context of a render function or effect. Perhaps we could start more conservatively and cover any function…

[BenjaBobs]

I get where you’re coming from there, but at the same time I think it’s quite well stressed in the React documentation that calling non-hooks inside the body of your render function will not lead to a good time. So I wouldn’t expect it to be much of a surprise to anyone.

The only real point of contention here is that this will still have a performance detriment when used inside useEffect. The question then is why are they even using recoil there? You can’t share the recoil value, and they can just use useMemo for caching a transformed result.

I agree with you about the usage, I just worry that it will seem too intuitive for people to use it that way and not bother checking up on how it should actually be used. I think it should at least be addressed in the documentation then.