Feature Request: debounced selectors

[andreafdaf]

Hi! Thanks a lot for this library, it is an awesome breath of fresh air in React state management 🎉

I'm migrating a project to Recoil to see if it fits and there is a use case I've stumbled upon a few times and can't find a straightforward solution to it without adding useless boilerplate and escaping pure Recoil-style. In my use case it comes from async selectors.

Maybe something similar might arise in fast changing sync selectors (and maybe even atoms), where a throttled selector might be used instead.
I would imagine debounce to be mostly a get thing and throttle to be mostly a set thing, but it might just be my POV based on the use cases I have at hand.

Suppose I have something like this:

const someDataState = selector({
  key: 'someData',
  get: async ({ get }) => {
    const param1 = get(param1State)
    const param2 = get(param2State)
    const param3 = get(param3State)
    const param4 = get(param4State)
    const param5 = get(param5State)
    
    const response = await api.readSomeData({ param1, param2, param3, param4, param5 })
    
    return response
  }
})

In some situations those five example params might change almost simultaneously, triggering five calls to api.readData where the first four are useless and only the fifth is the response we want. The one above is just a simple example but I'm finding myself in such situations more often than I would like to. 😢

A simple solution would be to have a debounce parameter on selectors, so that we can just write:

const someDataState = selector({
  key: 'someData',
  get: async ({ get }) => {
    const param1 = get(param1State)
    const param2 = get(param2State)
    const param3 = get(param3State)
    const param4 = get(param4State)
    const param5 = get(param5State)
    
    const response = await api.readSomeData({ param1, param2, param3, param4, param5 })
    
    return response
  },
  debounce: 200
})

And have this selector to only recompute it's get call 200 ms after it's dependencies are settled.
I would imagine the selector to enter a loading state as soon as it starts debouncing and then settle normally.

Right now I'm doing something dirty like the following, but it smells a lot:

const someData = atom({
  key: 'someData',
  default: null
})

const useSomeData = () => {
  const [someData, setSomeData] = useRecoilState(someData)
  const param1 = useRecoilValue(param1State)
  const param2 = useRecoilValue(param2State)
  const param3 = useRecoilValue(param3State)
  const param4 = useRecoilValue(param4State)
  const param5 = useRecoilValue(param5State)
    
  useEffect(() => {
    setSomeData(RecoilLoadable.loading())
    debouncedReadSomeData({ param1, param2, param3, param4, param5 }, setSomeData, 200)    
  }, [param1, param2, param3, param4, param5])
  
  return someData
}

This FR is related to other issues and the problems I'm having might be solved in other ways, for example allowing to set inside get, being able to cancel a selector get, etc. I just find it to be cleaner to have a debounce and a throttle options in the selector/atom

[drarmstr]

Debouncing/throttling selector evaluations or component re-rendering is a fair request, but definitely not trivial. I wonder if a good idea might be to debounce within your api abstraction. Though, that seems difficult because the intermediate states would cache the unresolved promise and could be problematic if you tried to go to that state in the future... Your approach doesn't seem awful, though someData doesn't need to be an atom. You could also debounce from the different param states to a single params-for-query atom which is used by the selector. It's a not uncommon practice to have some atom(s) state for the UI or rapidly changing state and then a process which debounces or commits that state to another committed-atom state used for querying. Another idea to note is that selectors are evaluated on-demand based on a pull mechanism when they are requested by a rendering component. So, you could also consider more traditional React rendering debouncing techniques that would then only cause someDataState to be referenced with the final state after debounced rendering.

[andreafdaf]

Thanks for answering and taking my request into account!

As for your proposed solutions:

• debounce within your api abstraction: as you pointed out this solution has issues, I tried it before the one I wrote above but I think it is a no-go.
• debounce from the different param states to a single params-for-query atom which is used by the selector: I think in the end this solution would look similar to mine but with extra code and less flexibility.
• more traditional React rendering debouncing techniques: this way we are moving our data logic inside the components, which is the wrong direction in my opinion, and it would get hairy if we need to use this same selector in different components.

So in the end I still think debouncing and throttling would be really useful features, all other solutions feel hacky and/or dirty IMHO.

Right now I'm looking to start a debounce before here, enter a loading state and only proceed normally after the debounce is done but I need to study how data flows inside Recoil to make something that actually works as intended.