![]() However, I will stick with using the generator since this seems to be the way things are going for now. I don't find it particularly troublesome to figure out what provider I need to use, it's not like there's a whole lot of choices. That being said, I don't know that I had an issue with the older way of writing out a provider. Seems simple enough to turn it on, and just let it generate on the fly. You don't have to do anything particularly special to install it or make sure it's up to date. The code itself is highly commented, so you're not going to open it and wonder if it's your code.Īs far as generating, it's just another flutter command line call like flutter pub get. There's probably other ways to set it up, but this does seem to make sense and it's easy to keep track of what's going on. in the name, along side the non generated file. For one, the generated code goes in a matching file with. I wanted to see what all the fuss was about and started using it a couple of days ago. Speaking personally, my experience with it is I took time to learn it twice already, probably 20hrs+, and come back and apparently everything has changed and all the old stuff is out the window and now it's all build_runner and annotations? What a waste of my time.this is state management, not rocket science.Ī full year after I looked at it last and the docs are still WIP? I feel sorry for any devs who went down that road and have had to spend this much time learning something as intrinsically simple as state management which is really nothing more than binding `build` methods to state changes. Assuming wasting peoples time is something you care about. To promote it as a replacement to Provider, and then spend 2 yrs constantly tinkering and changing the API, with no docs to back it up, wasting everyone's time who trusted your advice, is just bad decision making, no two ways about it. GetIt has been largely the same since it's inception, only really adding features.Īnd you're missing the point, when riverpod is _somewhat_ mature and docs are ready, then promote it. Even when provider changed, the changes were small. This idea that everything needs a new version every 3mths is an idea cooked up by marketing departments and sales people.Ĭase in point: Provider or GetIt. Things don't change endlessly until they are abandoned, GOOD things mature, and then go into a maintenance mode where they only require small updates and fixes. Part of the success of Flutter/Dart is its straight-forwardness and simple learning curve (IMHO.)Ĭonsidering I started programming in 1999, I don't think so :p When you try to decode its inner workings you are drown into a humongous rabbit hole which requires a very very good understanding in advanced Kotlin language features as well as coroutines. I think this may be the OPs problem as well.Īs a more general note, evolving projects have to pay close attention to these iterative improvements which make a lot of sense for the insiders, but add abstraction which may make actual usage very hard. I know why you do it, but "bare" riverpod is much easier to understand than the boiled down code where need to mentally expand the expressions to the actual provider etc. It was very enlightening, but I noticed that Craig had a hard time wrapping his head around it just like the OP, and I think for a large part it was due to the code generation thing. ![]() Documentation says, "DON'T use ref.read inside the build method".I just saw the session you did a while ago with Craig from Google. Here, I should use ref.watch as it is now inside build method and with onPressed it will be ref.read Once I press a button, the function with ref.read will fire up and it will be for only one time. As per the Riverpod documentation, asynchronously we use ref.read such as inside a function and for synchronous code, we use ref.watch such as inside the build method.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |