I got into this post hoping to talk to someone who was able to give a clear point of view siding with riverpod. But I got your point on that, it's easy to create a mess. When you control the flow of your data and building your app according to it, this point becomes more easy to maintain. That way my bloc can have complex yet adapted and readable states.Īnd for bloc to bloc communication, that's not a so hard subject. But in my app I define a generic state class and custom state classes that extends the generic one. I'm not sure what you mean by "derived data".
Widgets are listening to bloc states (complex or not) and are built according to these states. As almost everything in your app is a widget, context is always accessible. But, even if I built complex app with bloc to bloc communication, to be tied with context never was a pain.
I understand that riverpod is not tied to context when bloc is. I genuinely asking myself what riverpod is all about and you rose some element of answer. Thank you, I really appreciate that you took time to answer me with great details. It is easy to dismiss trends and approaches from outside Flutter, but in the greater context, all of UI development faces the same architectural, scalability and maintenance pain points. While Riverpods flexibility seems daunting at first, one becomes to truly appreciate it with complex domains.Īlso if one looks at the greater sphere of UI development (web, native) the way Riverpod approaches things is more in line with the larger trends than Bloc is.
RIVERPOD V2 HOW TO
Pretty much one of the first things in Riverpod documentation you read is how to combine Riverpod providers ( ). Also for whatever reason people using bloc seem averse to derived/computed state (something that is normalised in other frameworks).Ĭontrasting to Bloc, Riverpod is not in any way tied to context or widget lifecycles. Neither do the decoupling gains result in an easier to maintain codebase if there is alot of bloc to bloc communication instances. While in theory it presents excellent decoupling, in practice it makes it total pain in the ass to deal with in a domain where there is lot of interconnected data. Second point comes from how Bloc documentation strongly advises to do bloc to bloc communication ( ). So that is one point of inherent inflexibility. What I meant is since Bloc uses Provider underneath, Blocs method of existence and information passing is tied to context and specific widgets lifecycle it is used in. Probably should have elaborated more clearly. What are everyone's thoughts?Īlso bonus question, given I only have 4 pages, is it worth using a package like go_router to handle navigation? It seems a bit excessive to me, but I thought it worth asking anyway. What I need is something that works really well with futures and streams, can be somewhat easily maintained by a single developer, control the lifecycle of a state object and control the scope of a state object. I think a state management package would be helpful in cleaning up my code, and currently my two picks are Bloc and Riverpod (primarily due to their popularity) but I can't decide between the two. As such I have future and stream builders absolutely everywhere, and I'm passing data around and repeating functions all the time. I often have a future that checks the integrity of data on an object, and then subscribes to streams on that object to keep the information up to date. I (currently) only have 4 unique pages (home, account, settings and login/sign-up) so navigation is pretty straight forward, but the body of the pages is dynamically generated. I'm building an app that makes heavy use of futures and streams.
0 kommentar(er)
