Accept glob pattern or RegExp in trigger()

[nicolasschabram]

Thanks a lot for releasing this library! I'm just starting to play around with it but it seems like it's quite a simplification over what we're currently doing in our apps to fetch data.

I was wondering about one thing though: After a successful POST request you commonly need to revalidate some related data. If I got it right, you either do that with the revalidate() function that is returned from useSWR() or by calling trigger() with a key. The latter seems like a shortcut in cases where it'd be tedious to pass revalidate() around between components. However, in cases like these chances are that I also don't know the exact key (maybe because there's a bunch of dynamic parameters in there).

What do you think about also accepting something like a glob pattern or a RegExp as an argument to trigger() and then revalidating all the matching (and currently visible) queries? That way you could do trigger("/projects*") or trigger(/\/projects.*/) instead of the more specific trigger("/projects?page=3&perPage=100").

(I haven't checked out the implementation of SWR so please let me know if I have incorrect assumptions about the internals!)

[nicolasschabram]

I just saw that #78 is kinda related. Feel free to close if it's the same thing!

[shuding]

Yeah accepting glob pattern or RegExp is a good idea, but it will be unnecessary to add it as an option after giving you the full control of the cache.

[sergiodxa]

I think this could now be solved with the exposed cache, get all cache keys, filter based on a glob and then call mutate against them without data to revalidate them or call cache.delete to delete them altogether

[JulianG]

Hello!

I think I see the point in not bloating the library with features that can be done by combining the existing feature set, but

I don't think we can rely on the exposed cache for this: (let me know if I'm wrong) (I was wrong)

You may want to only revalidate "active" or visible queries only. For example, if I update "/users/42" and now I want to revalidate also "/users/", "/users/42" and any other "visible" users but not every user in the cache. Assuming other users would still be revalidated when/if they're requested again.

Also it may not be desirable to rely on the cache for this: (this is just opinion)

I think 'trigger' is s feature not directly related to the cache. As a library user I would like to be able to call 'trigger' without necessarily knowing how the cache works internally.

[shuding]

I think 'trigger' is s feature not directly related to the cache. As a library user I would like to be able to call 'trigger' without necessarily knowing how the cache works internally.

I like your take @JulianG and this is also my opinion about why I personally don't want cache APIs to be documented for now. Because ideally they should be covered by some other high level APIs or plugins. It's dangerous for end users to touch the cache.

(I'd close this PR, it's kinda unrelated to the topic)

[nicolasschabram]

I ended up with this by the way:

function revalidate(matcher: string | RegExp) {
  cache
    .keys()
    .filter(key => key.match(matcher))
    .forEach(key => mutate(key));
}