Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add useQueryState() #23

Open
posva opened this issue Mar 29, 2024 — with Volta.net · 3 comments · May be fixed by #35
Open

add useQueryState() #23

posva opened this issue Mar 29, 2024 — with Volta.net · 3 comments · May be fixed by #35
Assignees
Labels
✨ feature request a new feature request

Comments

Copy link
Owner

posva commented Mar 29, 2024

Allows retrieving the query state by key

  • Should allow passing multiple keys to to match multiple queries and return the aggregated state of these queries
  • How should they combine data, error, and status? Should each have an individual array, an object, a map?
  • If the state doesn't exist, create it?
  • It should handle a reactive version of the matched keys

Same questions for useMutationState()

@posva posva added the ✨ feature request a new feature request label Mar 29, 2024 — with Volta.net
@ElisePatrikainen ElisePatrikainen self-assigned this Apr 28, 2024
@ElisePatrikainen ElisePatrikainen linked a pull request Apr 28, 2024 that will close this issue
@ElisePatrikainen
Copy link
Collaborator

To temporary reply to the questions (which of course can completely be improved, this is rather a first step), in the PR I have just opened (in draft):

  • for the moment, I am returning the data as an array of objects with a similar structure to the query entries
  • if the entry doesn't exist, I create it to have reactivity working on it (there is probably a workaround though)

Also, I am wondering if the composable should be called useQueryState (singular) or useQueriesState (plural), since it can handle the aggregation of several queries? Or an alternative could be provide two composables (useQueryState and useQueriesState).

@posva
Copy link
Owner Author

posva commented May 16, 2024

I think returning the aggregation is fine. But I think that useMutationsState() is more important than useQueryState(). In fact, I'm not sure about the usefulness of useQueriesState() without all of the options as it could start in an incoherent state (no initial data). So I think we should probably just add the mutation's one first and leave this for later

@ElisePatrikainen
Copy link
Collaborator

I am thinking about a use case for useQueryState: allowing accessing the cache of a query without reactivating it. That could be useful in the case of optimistic updates (to access and mutate the cache without potentially triggering a new call). What do you think about that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ feature request a new feature request
Projects
Status: Todo
Development

Successfully merging a pull request may close this issue.

2 participants