Allow wildcard usage

[lauri865]

There's benefits to using useQuery without granular updates from mutations (e.g. auto-serialized queryKeys for filtering, etc.).

I believe thus by making the no wildcard rule less strict, we could make the library more useful.

I would be fine if e.g. all wildcard queries would get invalidated upon a mutation to the underlying table or any relation.

Not using wildcard would just make mutations more granular. But it doesn't have to be so binary, does it? (lmk if I'm missing something)

A console.warn in development would be enough to inform the devs about wildcard use, but no need to throw errors.

(Talking from react-query perspective, not sure about SWC considerations)

[psteinroe]

I also have a use case where this should be allowed: head: true queries with count. I did not touch the code base for a while so it will take a while for me to go that deep again and figure out how we can allow wildcards.

[lauri865]

Tried to understand the code flow, and this is what I pictured together:

• Build updateFetcher
• Build the select list for return: buildNormalizedQuery
  • This may or may not have a bug: parseSelectParam is not called if query doesn’t exist (and query is not required); otherwise would already throw an error here
• If we have selectQuery, query runs with returning columns
• If we returned data, we attempt an upsert
  • Gets all the cached queries, regardless of the table
  • Tokenise filters (=actual filters and columns names)
    • return (query: string, opts?: PostgrestQueryParserOptions)
    • Based on query string, returns column paths
  • Replaces columns with new data
  • Revalidates queries if needed

A few problems:

• Processing all queries in the cache, even if we don't need to
• Wildcard error is too eager, runs against unrelated queries
• Multi-step process, some queries get already excluded in earlier steps, so changing logic for them is difficult

Some thoughts:

• Why not store the relations in the queryKey, so we can quickly scope into the relevant queries that relate to the mutated table in one go without having to process the whole query cache?
• What actually prevents merging new data with wildcard queries? We can merge what we know and invalidate the queries if needed. Or if we have a wildcard query, we could return all the rows from the mutation even, and use that to populate the cache.
• The logic could probably be simplified by not doing all the complicated cases, and enabling developers to adopt the logic themselves (really relevant in few cases where mutation and view is side-by-side, and there optimistic cache could make even more sense).

Probably a lot I didn't understand in the code base. Wondering now if a fresh stab at this with a simpler model would make more sense at this point for us. As a developer, I want to achieve base case automated cache invalidation first, and then make things progressively better.

[rohankm]

I need the * selector also

[jpsaccount]

Same

[adamwett]

temporary fix:

export const queryFields = <T extends object>(): string => {
    return (Object.keys({} as { [K in keyof T]: T[K] })).join(',');
};