import SocialEmbed from "../../../../components/SocialEmbed.astro";


# Talking about Riverpod with Remi Rousselet

<SocialEmbed platform="youtube" id="qyfdowkmtAk" />

## Description

Diving into the details about Riverpod!

### Remi Rousselet

https://twitter.com/remi_rousselet

https://github.com/rrousselGit

Norbert Kozsir - @norbertkozsir

https://twitter.com/norbertkozsir

https://github.com/norbert515


### Rody Davis - @rodydavis

https://twitter.com/rodydavis

https://github.com/rodydavis

https://youtube.com/rodydavis

https://rodydavis.com

### Our podcast player

https://rodydavis.github.io/creative_engineering/

### Follow on Twitter:

https://twitter.com/CreativeEngShow

## Transcript

**0:00** · welcome to creative engineering today I have a special guest with me you may know him from stof or one of his very popular flutter packages I'm of course talking about Remy Remy thanks for being on the show how are you yeah thank you for ring me uh I'm doing pretty good what about you I'm doing pry good too so

**0:20** · today is going to be all about State Management and your newest package called River pod to start things off why did you call it River pod um yeah so provider but with the letters mixed up and there's also a second meaning um where you know in in Dart we have streams and so I I realized that by

**0:42** · mixing the letters we could have River in the name so it's like in the same team so yeah there's that I like it very much it's a pretty pretty fun name so before River pod you create a provider um provider is used in pretty much all fler projects where is directly or indirectly via for example FL block what was the reason for you to start working on this new River pod um it started uh usually it started

**1:11** · with slacker flow like at some point I answer a lot of question on sa flow and I realized that the same question was popping up all the time about inated widgets and or people misusing ined wies usually uh like they created some State dark inside the build but then when something changed their state was lost because they didn't use a state for widget or whatever um so what I did was um first I answered

**1:44** · the questions but you can pretty fix the problem before uh people face the issue um so I searched for a different way of solving this problem before it happens um so that's how

**2:01** · provider came up um at that time it has some some a provider named state for provider so it created like it's kind of this it's similar to the syntax with um the current state of Provider where you have this create function that creates an object only the first time it's created so the idea was behind it was that people only use this uh syntax this way their state is not last when something change uh and then you know

**2:30** · time as um time passed uh more use case were added and um yeah that's basically how it started interesting so you touched upon this and it's a very interesting distinction what do you think about this what is River pod SL provider really is

**2:52** · it dependency injection is it State Management is it architecture because I feel like um those three topics kind of bleed into each other and provider and River poot um can be used for multiple things or for same thing what is your opinion on this um I mean I know that many people uh consider provider R not State Management

**3:18** · U but I quite disagree with that statement in the sense that even if we are talking about just injecting variables that's State Management itself right State Management is a very very broad topic and I would go as far as to say that widgets in FL are State Management and when you think about it that do nothing else but managing states that not painting anything are not uh under under links clicks they're just managing the state of the UI um so yeah

**3:45** · in my opinion um provider is State Management is just a specific a very specific portion of State Management where uh it's initializing the objects and passing them around um and then we have R which does um which has a slightly broader scope where it's also like it's doing a lot of stuff for combining objects and um like caching results when you're combining things um filtering reveals um it also has some more opinion

**4:15** · rated um things like State not State provider which is a very simple provider to create variables so it's it definitely has a broader scope and I would think I think that more people would consider about an actual State Management solution interesting the reason I was asking because a lot of um use cases are a common thing when using for example the third BL package was to use the block package as State Management and

**4:46** · block internally uses provider to provide its to its descendant so the idea with rivert is to have um the idea of dependency injection and State Management more tight ly uh wouldn't say

**5:02** · coupled but having a package which is more focused on this um my question in there would be I've used River pod myself for um my recent project and there is a provider which is explicitly used for the state um I think it was a state provider for your state how how's the package called yes the state Notifier so in this case if I understand correctly the state Notifier would be the core State Management thingy and provider would be

**5:34** · H not provider River pod would be a way to combine that state to provide that state and to manage that state how would you um yes and no um like yes uh this state Notifier would be your core class to

**5:53** · like add your typical increment method in counter for example uh so that's a way where you can can Center all your business logic inside uh but providers also um are a place where you can put business logic inside like you can start HTTP request or things like this inside providers like typically with feuture provider for example you can do a a complete um pagination uh system with just using

**6:21** · feure provider with no state notif or whatever so you can get really far with uh with this um so I would argue that providers also are are um State Management it's not just specific to one class I see so it can be used I guess

**6:40** · it's like a lot of topics in computer science and programming the answer is it depends um it can be used for certain State Management things for some it might be easier because it is doesn't require to overhead I would I would say that um the only reason currently when why we currently need this statement if your class is because we don't have um Anonymous classes in dark if we did have these Anonymous classes uh and maybe s

**7:11** · dollar classes and S classes in dark uh we probably could remove St if you're completely and just use providers but wouldn't it be possible to have these kind of Anonymous classes with the with functions with Anonymous functions because you can actually declare functions inside functions and have we can definitely do that but then it looks very scary and few people use

**7:37** · it like River already looks quite scary to to some people so I think that if we want to go a step further it would be too far for some people like I know for example that people complained about having too many providers and while I disagree with u River being complex I think it's just because it has a broad scope so um so uh people kind of think that it's

**8:03** · complex just because there are uh many apis um but yeah um it's very difficult to have something that people uh would not fear like I I I think that functional programming for example is something very simple if you try it like

**8:24** · especially like for example with Elm or other uh simplified version of functional programming like the tooling helps you so much that you can almost disable your brain and still do things very rapidly because the compiler uh tells you every mistakes you made so you just have to almost uh do right click and fix and it does the same thing for you um but people can of have this

**8:50** · mentality where oh no it's functional programming so it must be super difficult I feel like functional programming um does all the things for you and in some way which might also be a good thing it makes um doing hecky things like something that has to be done quickly which just works it is bad

**9:09** · but it works it makes it more difficult because you cannot just mutate something which in turn might be useful if you just want to try out a little thing you want to build a prototype you just want to get it out quickly without caring too much about architecture I think um functional programming makes things like this hard but on the other hand it Mak makes it easy at some point to scale to debug and to do all of this yeah yeah I

**9:35** · definitely agree with this statement which is why I think that um the ideal scenario uh when building applications is nether using pure object oriented programming or pure functional programming but using kind of like an hbd architecture instead uh especially I think Dart is a good candidate or maybe cutl whatever is we have this trend recently with language set to Bow and

**10:04** · where we can gain both the benefits of imitability and mutability when you want to and Flur use this quite a lot actually like where with widgets we have this uh IM imitability um layer but then if you go inter if you go one layer deeper with runer objects for example they use mutability quite a lot to have this um

**10:29** · very performant API where instead of recreating everything every time you just mutate what needs to change so uh you use both sides of the both benefits like you have this immutability side for maintainability and this mutability side for performances and I think it's a good compromise and um that's kind of the thing that I that's a mentality that I try to add in River I think it tries to do

**10:55** · the same thing where you could technically for example um Mak mutability and immutability if you want to you could um have this U declarative programming where uh things just like you know uh top down and kind of working

**11:15** · by itself like you you write it and it re execute when when it needs to re execute by itself just because um you know kind of like with Widget you don't really listen to anything specifically it's just working by itself just by writing the stream Builders or whatever um mhm so at this on one side you have this aspect of declarative and kind of imitability too um and on the other side you can go with um I don't know change or state interfer and

**11:47** · go um with a very fine gr control over your state um yeah yeah I really like the idea of being able to adapt these different paradigms like the function programming and the object oriented programming in each other to have like the best of both wordss like have as you said render objects being these objectoriented State machines which heavily rely on method calls to do stuff

**12:15** · and on top of this we just have this functional layer um which harvests all the power of the objectoriented layer below it but ads on top of it that's a very powerful powerful idea yeah um coming back to the actual River pod we briefly talked about this before you said people felt intimidated by having all those different providers um I can somewhat understand it I've been reading through the docs and like okay State provider does this and the normal provider so what are the different

**12:48** · providers there are in River pod what do they do and why do they exist um there are a few of them we likely I will have more in the future so I'm not sure that uh list is really helpful but um this short story is we have um provider uh just provider not

**13:11** · State provider or whatever just provider um which is used to create um an object that never changed by itself so it's just like you know a repository or an HTTP client if you want to um or maybe a computed value if you want to because you could technically listen to other providers when creating a provider um so you could make like um a

**13:37** · filtered list of toos so you take you have your provider that listens to the too list and and listen to the filter and combine both variables to have the filter to the list um which will then rebuild only one other of the dependency change so you get these benefits of not filtering your to list directly inside the bill method which is a lot more efficient um so that's for provider uh

**14:03** · then State provider is typically for very very simple States uh that don't really have business Logics associated with them so like filters from the UI it's just an Nom and you're just changing the enom directly or switches if you want to um then by putting this logic inside

**14:23** · providers uh it allows you to combine this state with other things so like I mentioned previously with the to list example if you have your um filter implemented in a state provider you can then combine it with the state of your to list to to this um very powerful filter mechanism um then you will have uh your typical business logic providers so St

**14:52** · your provider change notif your provider um maybe if you using AER body packages I'm pretty sure uh maybe in the future we'll have block providers we don't know um which have this fine grain control over a piece of state where it has methods it has maybe it receives events um and it allows you to mutate the state using uh us this

**15:18** · method and EV um it change over time and then you have um dump down versions of uh this business logic um objects with a stream provider and future provider which are like um simplified version of a stay a change of

**15:36** · time but for very specific use case so here's just listening to the result of a future or stream and so whenever something change the stream it will update the value so you don't have to manually subscribe to the stream and then imit the new value you could do it with a stat or chent or whatever but it's just kind of like this Bor play that you don't really care about so making a provider makes things easier especially with Firebase for example so basically correct me if I'm wrong provider is the base class that

**16:08** · can be used to achieve all of this for example if you want to have a stream which you listen to you could just provide the stream with provider and then manually listen to it and do all your stuff and stream provider adds this abstraction on top of it which says okay

**16:24** · uh we don't provide you with a stream of items because obviously what you want to do is you want to listen to those we provide you with every single item and we will provide it every time the stream that internally emits so all the providers like stream provider future provider State Notifier provider could be implemented with more code with just using provider yeah um just using

**16:49** · provider itself may not be the correct choice I think um the correct would instead be maybe State Notifier provider or CH Notifier provider uh because these are uh the most powerful providers uh provider is doesn't really have a built-in way of emitting update so you won't be able to implement stream Provider from provider for example but with stat if your provider or change if your provider you could do basically everything so one thing um that I faced

**17:21** · when using provider for example I had a um State Notifier provider and I wanted to obviously listen to the state so so because I was using flare Hooks and a build method I said okay use State Notifier provider so I got the current state now I also wanted to access the actual State Notifier to call method on

**17:42** · like update something delete something so this time I couldn't just use the state Notifier provider because it provided me with the state and not the actual object so what I ended up doing is just calling I think it was something like provider off and then calling the me the method manually um would there be a way to say Okay I want the state Notifier I want all the new States but I also want x to the objects to reduce B plate code um when you're using state if your

**18:12** · provider in RB um you have a way to specify what you want to obtain so when you combine it with I don't know use provider or the watch method in Rod you can either do like watch my provider or you can do watch my provider. state so

**18:32** · if you do the former you will obtain the statement instance without listening to the state so you can then call increment decrement whatever and if you do the later you will be you will obtain this state directly but not this state interfer instance so just talking all the

**18:52** · different providers and the idea behind this it feels like it isn't too difficult like at the end it just BS down to when do you want to be updated for example a stream provider every time um an stream item is submitted or do you

**19:07** · just want to have the raw State Notifier as an object without listening to the states so you were talking about adding more examples maybe it would be interesting to have a little tutorial doc showing how to do something which you could be doing with a stream provider without a stream provider just using as little amount of providers as possible and then saying okay we did this this is quite a bit of boiler plate code you could use this to make it easier yeah one of the thing I'm considering is um architecturing my

**19:39** · tutorial such that we start without the provider and at the end of the tutorial we have this refactoring step to show how we can reduce the boiler plate to reach the same thing so like we could yeah we could maybe start with I don't know change Notifier that does the data fetching and that call notif find listeners when um the the query is finished and then at the end refactor to Future provider to remove almost all the C yeah I feel the thing that is most

**20:09** · valuable with this approach is if you get a solution for a problem that you never had before you accept the solution but you may run into the problems that it the solution tried to solve to begin with if you never faed a problem before you cannot really understand why it is there so if you say okay we this problem

**20:29** · how could we solve this solve it first so the user understands okay this is how I would do this this is something I understand and then reason okay we did this and this is my solution for this exact problem yeah I think that is very valuable and that would be very nice for docs um in the dark dock of Herod the

**20:48** · documentation Associated to each um element of the API um if you go on the dark do of any provider each provider explains what the use case of the provider so like if you go on the documentation of future provider it will tell you that it's usually used for fetching a request um fing something for an API or yeah pagination whatever even

**21:12** · if you go on the documentation of family it explains why what is the concept of family why you would need to to use this kind of thing uh I think one of the issue is that the current website um doesn't show the providers uh doesn't highlight the mation Associated to each provider in um so people don't necessarily find it and I think that would be one of the D sides of D dock it's like kind of hidden in a corner I'm pretty sure that few people use D

**21:41** · dock yeah yeah coming back to the river pod and how it works um I had somebody on Twitter asked where does River pod actually St state so River pod works by

**21:58** · defining Global providers um at first glance it looks like the state might be in some kind of Singleton some kind of global variable um because you are defining the provider AS Global State um how does all of this work where does the State live why is the state where it is there is actually no Global state in rot

**22:18** · which is kind of the most imp impressive thing in my opinion with the architecture where even if your providers are Global the state is not Global it's since that stored inside this provider scope widget that we added inside our widget tree previously and if we want to go more specifically into how it works

**22:39** · um provider scope what it does is that it creates an instance of the object called a provider container which doesn't depend on Dart and which doesn't depend on FL sorry uh which is a pure Dart object that contains um States for

**22:56** · providers and it it Expos it to the widget tree using plain unated widgets and which what this means is that for example if you were to do testing um you would typically create this provider container object yourself inside a test and this Pro container object contains method like read so you can do container. read my provider to obtain the state of a provider and so the basic idea behind this is that uh

**23:27** · you know one of the basic criteria for testing is that two tests should not share State because that would be a bad IDE like if you change the order of the test you could have a different Behavior so that's a very uh so then your test will not be uh reable and so uh using this architecture you could create your provider container uh individually for each state such that um

**23:54** · two tests would not share State at all which would would not be the case with Singletons or Global states by the way I really love the approach of having this provider container that doesn't depend on fur um in my current project I'm actually just started writing a CLI version of the project and I was able to reuse all the dependency injection wiring which I had set up before for the repository for the hdp client and just reuse that in plain

**24:24** · Dart because all the dependencies were wired up using the provider container I didn't have to do some manual Constructor injection so that's a big plus another thing I really like and I don't feel you emphasized enough is because um because you have these Global providers you get complete type safe access to the thing yeah so and all the

**24:47** · IDE integration before with provider you had to add this generic type the compiler couldn't make sure that the um that the actual type is in the widget Tre that you have access to that is there the new provider all you do is I I think of the name okay of repository I just start typing repository and it auto fills to repository provider yeah which makes just so much more productive yeah I also make sure that

**25:14** · you cannot try to read something that doesn't exist or like we provider so many people faced uh provider not phone exception because they use the wrong build context but with River pod you almost can have this issue um you can still face this issue if you're using like scoped provider which is a very very specific feature in rivot which you probably don't care about um if you if you want to the short story is that it's a reimplementation of the four uh fures

**25:48** · of inher widgets with River pod so you can scope them to a wget tree um but then yeah otherwise uh outside of scope providers you can do Bic you you don't have these exceptions anymore and it also solves these problems about um like for um I don't really remember

**26:12** · what I wanted to say sorry it may come back in the future that's perfectly fine yes so actually you you just talked about the um scope provider yeah and there was a thing I was wondering about I haven't tried using the scope provider yet but most of the state typically lives at the top of the tree because in Florida you have the routes and if you want some state to be available every page on every dialogue you have to put it on top of material app I had an issue open on

**26:44** · GitHub that I would like to have some way to share some sort of skate between multiple pages but right now with the current mation that is not really possible so but sometimes a river pod and providers also just used to provide a value to the sub widget Tre for example you have a

**27:01** · one page that doesn't navigate that doesn't move around it's just one page but it has a lot of sub widget and each each of those sub widgets has of widgets and you you would like to have value there without having to pass it down the widget tree to every single Constructor the scope provider as I assume allows us to add this dependency which uses the New River pod API to inject the dependency is it right um yes it is right but you probably

**27:31** · don't need to use cope provider to do that you could technically have your typical provider but just use it inside your specific page and maybe even uh place the provider directly next to the uh implementation of your page and make and make it private you could technically do that especially considering now you have now you have the variables for your provider so you can make them private if you want to which is very powerful if if you think about it um the use case of scope

**27:59** · provider would more be about making team for example so that you can override the team on a specific part of the application uh or maybe um translations or I don't know very specific use case and other common use case with SC provider is um lists so if you want to

**28:17** · pass the ID of an item instead of passing it to the Constructor of the widget you could expose the ID using scope provider and then the items will obtain their ID using the r River API rather than their Constructor the the main benefit of that is that then your provider uh no then

**28:38** · your widget doesn't receive any parameter at all which means you can make it constant so you can you can make it constant so that if you update wherever inside your list your widget will not rebuild unless what it used rebuilds so if you have like say a list of 100 items and then you add a new item

**28:58** · that means that the item count changed uh but if your item count change um typically what this VI would do would be reexecute it and buer uh for everything that is everything uh that is present in the list until um reaching the end of the screen so

**29:20** · that would uh rebuild a lot of things for no real reasons because uh nothing changed for them but if you use scup provider to pass the ID you can make your widget const your items constant and then they won't rebuild unnecessary

**29:36** · because since they are constant FL is clever enough to not rebuild them so you can do this you can do this performance optimizations but that's a very Advanced use case I would say like if you're just getting started you don't really have to care about that and go back to it in the future but super interesting I hadn't thought about this uh potential issue and a potential solution about this that's very interesting um coming back to the um scope and the um scoped

**30:04** · provider discussion we had before for example you have some sort of variable um which you only want to have uh be accessible on this one screen so you could make it private how would you deal with for example initialization and tear down for example you have some heavy object you have a connection to database or some sort of heavy calculation that you don't want to maintain pain after the screen is for example destroyed something else is pushed how would you deal with this if it is not actually scoped to the screen um one of the very

**30:39** · powerful addition um of the inherited widget mechanism that is implemented in River pod is um the autod dispose flag on providers um basically what it does is that it's a slightly different implementation of uh when the widget is removed uh with dispos the resources instead what it does is that when a provider is no longer used it it it dispose the resources which means that technically if you remove the page that

**31:11** · will automatically dispose the resources too but that that's slightly different in the sense that it's not scoped to the page uh so if you for example you have two screens that you're using the same data then if you close one screen but the other screen is still open that won't dispose the data immediately because it's still in use and then as soon as you remove the other screen that will automatically dispose everything uh

**31:37** · correctly that is super interesting yeah that sounds like a pretty pretty solid approach yeah um and an interesting aspect of that is that we can also combine providers so we can also have this very big graph or different states and so um when you're using autod dispose um um

**31:57** · the autod dispos flag um it will automatically force you to have all the children in the graph of providers to also use the autod disposed flag because you know if if a descendant is not using the autod dispos flag but a parent is using it that would kind of be weird because it would be always kept alive so um so then you have this graph of autod dispose objects and that certainly makes

**32:24** · provider uh no River but a very clever like in the sense that uh all your graph of providers will still be in use um even if you're using only uh the leaf of your graph and as soon as you stop using the leaf of the graph everything will kind of destroy itself naturally without having to care about it mhm that sounds pretty pretty

**32:47** · clever yeah so touching upon this we we talked about this before like the um scoping um not not the scoping where you declare providers one thing I also really like is for example I have a repository and if you if I want to provide this repository to the rest of the app I don't have to go into for example my main file create a new provider in my multi-provider and provide it in there but I can just do it above the actual class so if I for example say okay my repository now also

**33:17** · needs a dependency on the network client I don't have to move to do different files to do this I can do it all in one place and I really like the approach of having code that is modify together be together for example if I modify the provider and one of its dependencies in the class I also want to modify the actual provider which provides this class M so that's I really like this yeah we can even go one step further and

**33:44** · like now that providers are variables we can even extract them into packages so if you're spitting your application into multiple packages you can probably extract all the logic for the homepage inside a separate package share it with different thing and you can extract the provider too so that um you just have to

**34:03** · insert the provider scope with it at the root of your application and it doesn't matter whether the homage is using providers or not um it will just work out of the box you don't have to worry about inserting something inside your main application and another benefit is also in testing like I one of the downsides

**34:23** · with provider is that you have to uh when you want to do testing you have to reinsert all the providers if you want to set to to to test a very specific widget so that so that's quite a lot of Border PL to add all the providers needed by your wget tree whereas with uh River you can just add this provider scope wet and then you don't really have

**34:45** · to care about reinserting all the different providers that you need to use and you can just override only the provider that you want to Mark the behavior yeah you don't have to re imp all the wiring which you are doing already yeah because the wiring is done implicitly yeah which which is very important because you likely want to test this wiring too so if you have to copy paste it that's not a good approach yeah there is um I think always

**35:15** · a good indication that the code might have a few B smells if you have to copy paste stuff to get it to work so this approach now yes I do too so um I asked on Twitter uh what people would like to um hear in this podcast and the majority was

**35:37** · examples a lot of people said of course basic counter application can be easily done in pretty much any State Management too where it be state for Widgets or block coun example is a good way to start but there is always uh a need for more so uh in this segment I'd like to

**35:57** · walk through a few simple example scenarios simple in a way to simple to understand but from an architectural standpoint maybe not too simple um and I would like to hear your thoughts and how you do this um on those so let's start off with something actually very simple um just a bit more complex than the counter application the classical Todo um List application but with the little twist that we also want to have items filtered

**36:28** · which I know we talked about is a very good example of Provider it's actually implemented on Z rivot documentation there is an open source implementation of it it's just not associated with a tutorial that explains step by step how to do it but if you go to to-dos do R.D

**36:46** · you will see a to-do application with filter and everything implemented R but yes yeah do we still want to go over Concepts or would you that okay yeah so we have a simple application to-do list we want to be able to add a to-do item remove a to-do item and update a to-do item every to-do item is just the text and whether it's

**37:10** · done or not done how would be the it doesn't have to go into the detail because obviously listening to code is a bit harder to read it but how would you architect this and what kind of providers and why would you use yeah um I thingss are two difference to there are two big steps there is the filter which is uh one thing on its own and then the um just managing the list of to do so first for managing the list that's

**37:40** · a typical use case for um a state Notifier or a change Notifier depending on whether you want to use multip or not um so you make a custom statement if your class which expose uh you know add too remove too edit to-do methods and that just expose a list of um to-dos then you pug it into a statement provider or a CH provider uh which then expose uh which then allows your UI to

**38:13** · listen to the list of to-dos and do something on click or whatever to update this list of to-dos um so that's for the list of toos without filter and then for the filter um using Riot is actually very easy to do uh to filter States um so you the only thing you need to add is create a separate um State for the filter um for

**38:41** · your enm for example so you can use State provider like we mentioned previously which just stores the current state of the filter so likely none by default um then you plug it to your UI such that it change when you change the filter State and finally you can combine your um filter and your um to-dos your stat

**39:07** · interfere to-do uh to- list using a provider and then inside your pro proor what you do is you use this R object pass to the provider uh and call r.

**39:18** · watch uh to-do list and ref. watch um filter uh provider and then you just do um list. where and then filter accordingly and this will automatically um oh yeah I

**39:35** · forgot once you've created this provider what you do is inside your UI instead of listening to the entire list you now listen to this new providers you just created and so with just this little change and now your UI will automatically filter things accordingly and it will filter the list only when as you added a to do or you um change the filter State mhm so the idea behind this is we

**40:04** · could actually implement the filtering inside the state Notifier we could have a method called set filter level or set something like this and then do the actual filtering in there too but the behind the idea behind this is the separation of concerns like you have your state not the fire provider your state no fire that's not really State uh that's not really uh separation of concerns here it's more about making it declarative such that uh we have a single source of Truth for the list of to-do like this this business subject um

**40:36** · manage the list of to-dos uh directly and we don't really want to mess around the um official um SF of toos we don't really want to changee the public API about it to avoid like having to I I

**40:52** · think I saw many questions on sa flow where they did this mistakes where they updated the Leist stuff to-dos that they had when they change the filter but then when they when they go back to none they realize oh no I lost my toos where they are so um yes so it's so like by separating things uh and using ref.

**41:14** · watch instead of having all this logic inside um State notif here you could technically do that and have a big stat if your objects that expose many different things like the filter list and the rooll list and whatever you could do that um but the issue is it's likely more complex because you will have to deal with listeners you will have to um make sure that you're caching

**41:37** · the value when when you need to like listening to both the filter and and the change on the uh to the list could be quite complex whereas um by using um

**41:52** · this by splitting it into um multiple provid than using r. watchat it's very linear you don't really have to bother about uh what happens when the state of the filter change what happen when the list uh change it's just done for you automatically and without having to care about it I think the thing or the um the

**42:13** · idea that would better encapsulate this is the single responsibility pattern in this case because you would have this one component that it's only its only responsibility is to manage a list of to-dos update and do a lot stuff it doesn't really have to do the filtering because it's just has a single responsibility and then you add something else which has also a sing responsibility it gets a list of items and just filters it the interesting part about this it is very um pluggable like

**42:41** · if you want to change it if you want to remove the filtering you don't have to go into your class and remove lines of code and do your stuff all you have to do you just don't listen to the filtered the filter provider anymore but instead the normal to-do list provider and another benefit is that it's also more performant in the sense that uh especially if you're using imitable data like if you're using imputable data you might if you want to have a single big

**43:09** · uh statement if your object uh your model will likely be quite complex like you will need to have a zero um unfiltered list of to-dos and then you will have to have this filtered list of to-dos but then when you want to do any edit you will have to always is clone

**43:27** · the object but that means that the larger your model is the bigger the Clone operation is whereas if you're separating it into multiple providers uh you have less things to clone when you're updating the list so it's technically slightly faster too interesting okay so I think that was

**43:51** · a pretty good breakdown of the um first example of just a simple list of to do we've also the added uh feature of being able to filter um let's move on to something a bit more complex and the ideas or the app would be you have a list of items just like in the to-do list but in this case those items are not as trivial and simple as to-do items

**44:14** · in this case we can have one class which man manages a list of to-do items because they're so simple it's just mutable data which can be copied and changed let's have a case where each item is super complex each item managing its own vast and big um state may do

**44:32** · additional Network calls in there to lazily load even more data or just have a very complex interaction I think putting that all in one class might be too much how would you do this um I don't really understand what

**44:47** · you're explaining so for example think we have a list of not to-dos but of games we have um like 10 games each can be visible at the same time obviously a game is very complex you don't want to have all the game states of all the games in one class because every item is complex how would you do this okay um yeah so it's

**45:12** · not just a list of um dumb objects it's a list of objects that may update independently that has different roles too so it's not just the same kind of object okay um um um so I think um different approach is uh to um have a separate provider for

**45:36** · like when you have um this kind of use case you may want to instead of storing the list of games just store the list of IDs of games and then um so you can update just the IDS new IDs remove IDs and then the listening of um the object is is done separately um so uh the idea you you may want to use something like family um so you want to create um separate uh game uh provider

**46:09** · that is as CH your provider or techn provider and use the uh dot family Constructor to um create your game instance based on the um based on the ID

**46:32** · um turn I'm not sure I think do do you want to add new games at at TR time possibly like imagine it not just being games it there are apps with just complex interactions within this items like not all apps just have this dumb data sometimes it's just just complex so think of this game as being being anything that is complex so yeah adding removing updating um would be would be something the one

**47:10** · wants um I mean uh the the reason I'm um thinking about it is that with games they have completely different implementation so it's a bit like depending on the game type you may use a completely different controller so that's speciic use case for example it's always the same game like it's Tetris or

**47:30** · something but obviously with a different state like different instances of the same game yeah that's that's an example yeah so in that case the uh what I was explaining previously totally makes sense where you have your list of IDs on one side and on the other side you have um your statement if your provider or CH provider. family and then um it receives

**47:54** · the uh game ID um because families are just providers that receive an extra parameter to do some extra fancy stuff so here it's just the ID you don't really care about the ID inside the game instance it's just uh the ID Associated to the to the game and so your state notif provider will create the game instance so the the tetris instance and then your UI will be able to

**48:20** · um like when you want to add a new game what you will do you will just uh push a new ID to the list um and then that will automatically update the UI that listen to all the IDS so you you may have a list view somewhere which will update because you added a new ID and then when you want to read the game Associated to the S ID you will um read the game provider that you created which is a family so you will have to do like watch game provider and then uh

**48:54** · pass parameters to the game provider so you pass the idid that you received previously from theist View and so by doing that U that will uh the first time you try to read this ID that will create the T instance automatically for you and that will also subscribe to the T instance such that when it change change are

**49:16** · propag propagated and also think that this makes a lot of sense because the object which manages the list doesn't have to load all the items and wait until like five instan of Tetris are loaded it just says okay we have five items we can distinguish between those items and the actual loading which may include a loading indicator or some sort of network fetching can be done externally in these Tetris providers yeah so this

**49:44** · can be so again single responsibility we have one list that is being managed and we have one individual game that is being managed which could also live on its own yeah so um to make things uh even further complicated because that's the thing I like is um okay we have like three uh Tetris games and now we want to

**50:08** · implement some weird impossible game that accesses the state of another Tetris instance think you're playing Tetris on free Tils and you want one Tetris to see okay if the other Tetris just spawned a cube I want to spawn a a

**50:25** · something else how would you do something like this can you still add tus at run times of course um so how does the interaction between tet instance works like what how how does it determines which tus instance does it want to use I mean an example would be would be

**50:47** · at at the initialization stage you would be select another tetr sance maybe viid so or example you always want to use the instance which is on top of it in the list just some ristic I'm asking mainly because um there is a very important part in State Management which I think is not used in us which is uh un generational data flow um and uh providers uh can of

**51:16** · enforce you to use Ral data flow to make sure that your application uh doesn't lead to Spaghetti code on the wrong run um so you need to think about how your objects interacts so in the case of uh you're only reading the previous T instance it's fine because it's just a linear list so that's unctional so you don't have re issue so yeah in just say in this case you can just inside your um game provider which is still a family um

**51:50** · you you receive the ID Associated as parameter uh if you remember correctly so since you have the ID as parameter you could technically uh listen to the ID minus one to obtain the previous instance so you could like using the ref object you could do ref. watch uh game provider and

**52:10** · then pass your ID minus one and then you will be able to listen to the previous instance interesting I really like the fact that it's so easy to access all of this without having to worry about okay can I access this because am I above or below the provider like things you would be having with the provider package where you have to think about this you will still have an exception if you try to do something that is not a unit directional data flow so if you have so

**52:38** · if you're trying to read as a previous T and then the previous Tetris is trying to read the next Tetris you will have an exception telling you that it's not possible because yeah because it's cycle and it would be infinitely updating right yeah and then especially uh that's also why we can do some powerful things like the autod dispos flag because since it's an un data flow um you don't have this cyclic dependency so you know when

**53:04** · you can dispose resources whereas if you had a cyclic dependency you wouldn't be able to know oh okay it's not used anymore um so so yeah rivot will not let you do very weird stuff you have to be careful and that's also that that's one of the biggest reason I'm working on De on a de tool for rivot at the moment where where um I'm extending the FL depal and um so you have a a new tab for rivert

**53:35** · which shows like your typical State Management uh T tool where it shows um the um exp expanded view of an object but here also has an extra tab where you see the graph of States so um you would

**53:53** · see oh this provider depends on this other provider and then you have this this tree um of states and see what what happened when you update this provider which or the provider depends on it and you also will likely see the widgets too at the same time so you could like I really like the idea yeah I like the idea I feel like I

**54:16** · feel like all the State Management Solutions could use a bit more love from the def tooling uh Direction because you have all this St manag and things but it's still kind of awkward to inspect the state uh especially during runtime and if like even if you are in debug mode you first have to set a break point you don't have to manually go through the variables and the references just having a way to have more information be

**54:42** · visible with less effort I think that could be um very helpful and I think um I I'll give a shout out to Z go team like um tried the I've already started working on the dev tool and I've tried it um tried what's

**55:01** · existing in the dev tool and there actually have the possibility to expect objects D objects at R time so you are able to list all the all the properties and everything you want to implement a DA tool which means that I was able to um list everything we want to do and

**55:21** · um um in know typical death tool so list all your properties and list and potentially update them we can also um update the state of your um State at from the death to so you can click on something to go bu and update strings um

**55:41** · so yeah the death is very very very powerful and I think uh it's quite underrated at this point uh and maybe in the future more people will contribute to the death to once they realize that they can do all this fancy stuff that typical applications in dark would not be able to do mhm yeah that is indeed super interesting I didn't know you were able to do so much even during the runtime but that's definitely something I'm super excited for so um yeah that's

**56:10** · why I'm surey if if anybody wants to know more just FL Remy um I'm pretty sure once things are ready you'll be able to you you'll know um yeah on Z death to um I would

**56:26** · say that I at this current stage I'm able to obtain all the different informations needed to show the de tool like the graph and update the things and the only remaining thing is uh making the pretty because it's certainly not very pretty but I mean if you think about making stuff pretty um then I'm pretty sure you're at a stage where all stuff is working so if it's just making it pretty I'm pretty sure you'll be able to accomplish that

**56:59** · yeah so um I think we are slowly getting to the end do you have anything to add to say um yeah I would say if you have any feedback about repot whatever it is even if it's like oh no repot is super bad it's fine um please tell me I would love

**57:21** · to get as much feedback as possible like the only thing I've seen is people saying uh maybe thank you or something like this so it's great to hear but um I love to hear also about what problems people are facing so that maybe I can document it or maybe I have some new features to develop so if nobody is complaining it's difficult to do uh my

**57:45** · job you know I can't really improve this thing further if nobody's complaining because I don't know what to improve maybe it's just so good that there is nothing to improve who knows it's very unlikely I'm pretty sure that there are many things I need to improve like for example I sometimes when I try

**58:02** · when I randomly try stuff I find bugs so I'm wondering is it that people don't bugs or is it that they didn't find it and I always have this question at the back of my mind do people actually use the stuff I make I never know I definitely

**58:21** · do okay thank you so much for being on show um for all the listeners we'll have all the links we'll have his Twitter handle and the ways you can follow him in the show notes thanks again for being part of the show and thank you for good \[Music\] one