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

Mutation: Access mutated data #3937

Open
snapsl opened this issue Jan 18, 2025 · 11 comments
Open

Mutation: Access mutated data #3937

snapsl opened this issue Jan 18, 2025 · 11 comments
Assignees
Labels
enhancement New feature or request question Further information is requested

Comments

@snapsl
Copy link

snapsl commented Jan 18, 2025

Description

Currently, riverpod gives access to the mutated state using ref.listen()/ref.watch().

@riverpod
ref.listen(todoListProvider.addTodo, (_, addTodo) {
   switch(addTodo.state) {
      ...
      _=> defaultHandle();
   }
});

Suggestion

Riverpod should enable us to access the mutated data directly, e.g. the data of a addTodo mutation would be the newly added todo.
If the mutation is in a success state, the data is available via the data property.

SuccessMutationState(:final data)
@rrousselGit
Copy link
Owner

Isn't that already the case?

@rrousselGit rrousselGit added question Further information is requested and removed needs triage labels Jan 18, 2025
@snapsl
Copy link
Author

snapsl commented Jan 18, 2025

If I understand it correctly, the SuccessMutationState currently holds the updated notifier.state.
I suggest not restricting mutation.data to notifier.state, but rather providing access to the mutated data directly.

E.g. a addTodo mutation for a List<Todo> notifier.

Currently:

SuccessMutationState(List<Todo> value)

Proposed:

SuccessMutationState(Todo value)

@rrousselGit
Copy link
Owner

How would Riverpod know what that is?

@snapsl
Copy link
Author

snapsl commented Jan 18, 2025

How would Riverpod know what that is?

Can you elaborate?


Benefits:

  1. This could align Riverpod with Tanstack implementation for mutation
  2. Direct access to mutation data
ref.listen(todoListProvider.addTodo, (_, addTodo) {
   switch(addTodo.state) {
      SuccessMutationState(value: Todo todo) => showSnackbar(content=Text("Added ${value.name}")),
      _=> null,
   }
});

@rrousselGit
Copy link
Owner

How would Riverpod know what that Todo is? It only has access to the List<Todo>. How do you get a single Todo from that?

@snapsl
Copy link
Author

snapsl commented Jan 18, 2025

Hopefully I get your question correctly. 😀
From an API perspective, the mutation function could return the updated todo allowing Riverpod to access it internally.

@riverpod
class Todos {
   Future<List<Todo>> build () asnyc => ...;
   
   @mutation
   Future<Todo> addTodo(Todo value) async {
      final newTodo = client.addTodo(value);
      return newTodo;
   }
}

@rrousselGit
Copy link
Owner

@mutation
Future addTodo(Todo value) async {
final newTodo = client.addTodo(value);
return newTodo;
}

But then Riverpod won't know how to update the state, as Todo is not assignable to List<Todo>

At minimum we'd need:

addTodo(todo) {
  final newTodo = client.addTodo(value);
  state = [...state, todo];
  return newTodo;
}

@snapsl
Copy link
Author

snapsl commented Jan 18, 2025

This looks good to me. I don't see a way to not explicitly update the state.

Note: Should an error in a mutation.state automatically result in an error in notifier.state?

@rrousselGit
Copy link
Owner

That'd require changing how mutations works.
But maybe

Note: Should an error in a mutation.state automatically result in an error in notifier.state?

No, I don't think that makes sense

@snapsl
Copy link
Author

snapsl commented Jan 18, 2025

Note: Should an error in a mutation.state automatically result in an error in notifier.state?

No, I don't think that makes sense

Agreed. I also do not think that this should be the default, but it might be something that some users want. This could be a annotation flag.

@rrousselGit
Copy link
Owner

We can revisit that later. That's not something I'd ship in the initial release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants