What is the point of using RiverpodGenerator or Freezed as I understand we could just do CRUD operations to implement our data using models. But why, when and how do we use RiverpodGenerator?
-
1Most of this will be moot when macros enter the language. You'll still need the annotations, but at least you won't have to worry about a separate build state because it'll be part of the compilation.– Randal SchwartzCommented Apr 16, 2023 at 3:31
Add a comment
|
2 Answers
It just about make it easier to implement the providers and reduce the error until producing the providers, it can save your time and make the development faster. Maybe you will not know the feature of it until you work on a larger projects.
RiverpodGenerator and Freezed have completely different uses.
If we are talking about RiverpodGenerator, it solves some problems (compared to the classical definition):
- a clearer syntax based on classical functions
- pass as many parameters as needed + both positional and named parameters are available. In the past, we limited ourselves to the family
- stateful hot-reload of the code written in Riverpod
If we're talking about Freezed, it's for:
- easy and quick immutability of objects
- immediately overridden
hashcode/== - Matching in different styles
That said, it's very flexible right now. The modifier @Freezed(...) allows you to redefine almost completely the result of generation.
All of this may soon fade into oblivion. And to date, the developers of Dart are actively working on it.
