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
Please Provides an architectural example of MVC + latest riverpod generator #3119
Comments
For example: I have A page, A controller, in A controller store a lot of data and update data methods (string Boolean model class, update string update model class to get data), such a structure with the latest syntax generator should be how to achieve, Could the official provide a similar example in the document |
a.controller file
This is how I define and update data in getx. Now I'm trying to switch to riverpod. How do I implement this in the latest riverpod generator |
This example looks like it only maintains todo data, and I have a lot of data in one controller, todolist, movieDetailData..... Do you want to create a provider for each data? |
Generally yes. Riverpod doesn't promote putting too much things into a single object |
To begin with, Riverpod isn't trying to respect MVC |
How is this different from storing a lot of data in controller in getx? Is there a performance gap? Can you describe it in the documentation |
The design of Riverpod leads to a significant amount of code duplication and a massive workload |
I've reviewed the documentation multiple times but still have questions. Specifically, I'm unsure about monitoring state changes while accessing the notifier in a widget. The notifier offers many useful methods and properties, unlike the state. Also, I'm uncertain about the appropriate placement for utility objects such as streams, custom utilities, and caches. Should these be included in the notifier? Furthermore, I'm unclear about the optimal time for initializing these utilities. Would it be during the constructor or the build method? Additionally, I'm concerned about potential issues if the notifier is rebuilt. |
You're not supposed to "listen" to notifiers.All listenable state should be placed inside the "state" property |
Thank you for your response. I'm still a bit unclear, though. Are you suggesting that all utilities, since they're not listenable, should be placed in the notifier? And for listenable utilities, should they be included in the state? Additionally, I'm not actively listening to notifiers. In a relational model, we often need to access objects from other providers. I utilize conventional getters to fetch objects by ID from other providers, avoiding repetition. This is one reason I need to access the notifier while also listening to the state. Could you please provide more insight on this, particularly regarding the optimal placement of utilities like streams, custom utilities, and caches? Should these be initialized in the constructor or the build method, and what are the implications if the notifier is rebuilt? |
all state in riverpod should be created and initialized in build (for notifiers) or the top-level function (in functional providers) avoid storing any other state in your notifiers. riverpod handles streams for you. simply set the return type to If you want to get an object by it's id, add a parameter to this can be like: @riverpod
List<Todo> todos(TodosRef ref) => []; // a list of todos
@riverpod
Todo todo(TodoRef ref, int id) { // a specific todo
final todos = ref.watch(todosProvider);
return todos.firstWhere((todo) => todo.id == id);
} |
Having used riverpod + flutter_hooks since riverpod came out, you don't really need to do MVC. I use flutter_hooks for ephemeral state and riverpod for dependency injection + global state and it works a charm. |
In my project , i use riverpod(v2.4.9) source code like this: The code call path :
|
Is above example by @MannaYang a recommended pattern for the current state of Riverpod? I've used 1.x versions and am used to creating a provider that passes in a Ref to a repository class for example, which then uses the ref to access a (REST API) client exposed through another provider; this seems very similar. Is it still recommended to work like this? It's basically as in above If not the recommended pattern, what is the suggested approach? E.g. have an annotated provider for all methods such as Thanks in advance, trying to wrap my head around the changes 1.x to 2.x + code generation. |
Is your feature request related to a problem? Please describe.
As a powerful riverpod, I hope the official can provide MVC + the latest riverpod generator architecture example
Describe the solution you'd like
As a powerful riverpod, I hope the official can provide MVC + the latest riverpod generator architecture example
The text was updated successfully, but these errors were encountered: