Can the terminology around "useRecoilRefresher" be improved?

[richardanaya]

Caveat: i'm not a recoil expert.

One of the things that was a stumbling block for me was that the refresher actually didn't reset the a selector. It just cleared the cache until it was used again (which is obviously super useful). What confused me I think was it wasn't an imperative refresh (which might actually be something you all want to do at a later date). Is there some better name for this function?

It seems like its actual behavior is something more likely named "useRecoilClearCache", which could be useful for certain behavior in the future perhaps for selectively clearing parts of the cache rather than the entirety.

Example would be to clear caches older than a certain date, certain keys of a selector family.

[noritheduck]

Hi richardanaya, not sure what they mean by “imperative refresh”…. When a selector is “refreshed” it clears the cache, but it should also cause components subscribing to it to also re-render and thus re-evaluate the selector. Let me know!

[richardanaya]

You might not have subscribers on the screen though I think is my point. If no subscribers it doesn’t refresh until much later (I.e not an imperative refresher)

[drarmstr]

If there are no subscribers, then no-one would actually use the results of the query. Selectors are evaluated based on actual demand. Note that if latency is your performance concern, then there is a pre-fetching pattern you can use to explicitly issue queries and cache results for anticipated usage.

[richardanaya]

You’re correct. My issue isn’t with prefetching it’s with the naming. In your scenario the naming might mislead someone into thinking you don’t have to do some prefetch pattern because the name implies a refresh will occur, but in actuality a cache is just cleared.

This issue is about a name matching the reality of what is occurring.

Right now the name is based on an optimistic side effect that might occur.

I’m suggesting the name reflect an outcome that will definitely occur.

[drarmstr]

You’re correct. My issue isn’t with prefetching it’s with the naming. In your scenario the naming might mislead someone into thinking you don’t have to do some prefetch pattern because the name implies a refresh will occur, but in actuality a cache is just cleared.

This issue is about a name matching the reality of what is occurring.

Right now the name is based on an optimistic side effect that might occur.

I’m suggesting the name reflect an outcome that will definitely occur.

Hmm, though just saying "clear cache" would imply that it wouldn't actually cause components that are subscribing to it to actually rerender and refresh the selector. The timing of initiating the query could be argued as a performance/implementation detail. The observable effect for the user is the same with either an eager or lazy re-evaluation.

[richardanaya]

though just saying "clear cache" would imply that it wouldn't actually cause components that are subscribing to it to actually rerender and refresh the selector.

That’s correct because getRecoilState/getRecoilValue causes refresh, not the useRecoilRefresh. That’s why I’m suggesting it should by called useRecoilClearCache.

[richardanaya]

Consider for example you are navigating between various sections of a website, and want to free up memory that’s being used by the selectors holding data no longer being viewed in any screen.

It would make linguistic sense to useRecoilClearCache unused selectors you want to free up. Not useRecoilRefresh selectors you never intend to use again.