Coding Riverpod with creator of #Riverpod, Remi Rousselet

foreign [Music] welcome to another episode of flutter original and this episode is a very special one I have a very special prolific author of many the tools that you're probably using in your flutter or Dart applications Remy rosale is with me today and it's an honor to have you in this show Remy how are you today I'm fine what about you I'm pretty good thank you I'm I cannot be more excited as finally I got you to this show I think a lot of people will been waiting for this moment I promised many devs that you will be on this show one day and talking about at least some of the things that you're doing on let's say today I want to talk about riverpod mostly but before that Remy a lot of people know you already bought introduce yourself for those who probably don't know you well open source developer working on a bunch of packages like uber Park freeze books too I'm usually trying to make your state management and rated stuff a bit easier in flower um yeah and I'm working on invertise too where we're doing a bunch of Open Source so we can twist it um yep that's about it that's cool I think Remy um a little bit of his story so you've been with dart and flutter from a very early stage let's say I guess and um I myself find you on stack Overflow where you've been very active and you answered so many questions and some of them vary in detail s how did you find Darth and how did you decide like to start working with dart at all and then thinking even creating Dev tools or let's say you know developer tooling that is kind of solving some problems to make developer experience better so how did you ended up doing such things um well I used to be a web developer a while ago and um from a co-worker I heard about dard because we had some issues at the company we were looking for a way of making type code in web and one of the things that was mentioned was Dart so I looked up Dart and somehow in the dark web page flutter was mentioned so I tried flutter and to try it out didn't I didn't try it Michael wasn't to try sir full flutter just wanted to try it out and uh if I didn't log with it and so I stayed and yeah um as for why I made all these Dev tools um um it's usually because first I uh I liked answering on stack Overflow because it helped me learn more about flutter because at the time the community wasn't quite big so um it was a nice way of um reaching out to people and learning more about Fleur and um not some point I realized that some questions were coming back all the time um and so even though I spent quite a lot of time answering those questions um and and so I started thinking about if I could solve the problem at a source so that people burn absorbs anymore and started making comeback edges and so that's how provider came to be and all these other packages are kind of like step UPS uh like more problems were found and more solutions were made and it keeps going so that's where I want to die very interesting I mean so I guess one of the first packages that you created was provider if I'm not mistaken and so well do you want to talk about it a bit and many people know these days you already created like a successor to provider or let's say riverpod so how did you create that package what kind of problem you solve and why did you ended up rewriting that again into riverpod um when I make provider it falls mostly to help solving a few issues related to inherited widgets um because the narrative witches are a bit raw I would say and very confusing in a few in a few different ways one of which was um when people use the narrated widgets typically always forgot to make a stateful widget associated with it to cash see changing teeth here or whatever you're exposing they like to use a stateless widget to and just create the model directly inside to build my dog but you see which it reveals somehow this state is destroying and people were kept asking why is my step destroyed and and so um one of the submissions was making um kind of what I call that the thermostat full provider which is basically an inherited widget which is um which basically instead of taking a value it takes a callback which returns a value and it caches that value you can see that button quite a few uh uh basically everywhere if you're familiar with provider Android web app um so now you didn't you don't have to make a state for widget anymore you just use the provider in your stateless widget and the problem doesn't appear anymore um so it was the first thing um the first reading I mean then I mean once you're here you can dispose a stateful people you can subscribe to it so that's it don't forget about it can do a bunch of extra stuff um uh yeah because there is a lot of problems we can probably talk about it for like hours hours I understand yeah I think I bet many many like I I I can literally say maybe 100 of flutter developers already know somehow provider so this is the first uh kind of package that many developers are introduced to when they come to developing you know flutter applications and um part of it because it's a fantastic tool that you created our package and part of it is because for a long time it was recommended by Google or flutter team somehow uh instead of using like the ordinary solution for in like as you said in created widget so and but then use you ended of rewriting that to riverpot yes so and do you want to talk a little bit about review part what's the story and what's your take on it like right now well roof report is basically provider um and it's the main river but there's a nanogram of provider and the main reason why we have two package isn't enough one uh it's um because yeah I wanted to make provider better but the issue was that um I fasted bunch of core uh printings um around flutter and more specifically narrated widgets cpis I have a few flowers I would say um like when when you start subscribe when a widget starts subscribing to an inherited widget it never stops and subscribing to study narrative widget so for example if you conditionally invoke them team.off inside your widget and you the condition goes from True to false then see which it will still rebuild when the team changed even though it doesn't use it anymore one of the complex areas with inherited widget is related to scoping and because you know it was inherited widget you can place your widgets a urinary to widgets anywhere in the widget tree including at lower levels but it means that if you try to access iterated widget from higher levels you will you won't get it which is fine and are it's an interesting barium we'll see it involves so much complexity um for forces behavior and most of the time like 99 of the time need of minutes at all um you usually you just have one instance that says available for the Ontario with a tree and um I mean there's a scoping mechanism is more from my experiment the scoping mechanism is used more by people as a way of um destroying the state when it's no longer needed instead of um uh actually relying on not exposing a value to a substrate like this bit doesn't quite matter in my opinion um so yes the main issue is that well people were trying to destroy the state once they didn't use it anymore but it's used an underrended way of doing it um which cause problems make the application quite complex so I wasn't satisfied with all provider um solve this and a bunch of others English like mentioned there are many many problems um um and looked for improvements to the barium um like another problem for example that I've was never satisfied in provider was the proxy provider if you're aware of it in my opinion it's terrible design but whatever um like combining providers in the provider package is very difficult um for the 10 is a problem um so yeah all these problems that built up over time um I searched for a while for solutions for those and came to what I believe is fairly decent Solutions in in the new robot package it offers basically a different way of solving those problems that is more um tailored to what you would expect in uh in federal so instead of scoping a provider to destroyed stay from this ball now you can flag it at what we call Auto dispose in robot so by using that the state will get destroyed if you stop using it so this you have the same behavior of uh garbage garbage collecting your state when it's no longer used but it's not relying on scoping anymore it's running on a slightly different Behavior so the effect is the same but the complexity isn't um but basically it's this sort of things different approach to solve the same problems and definitely I mean to my opinion um so these are all great things that we've been missing as a person that who've been working with provider for a long time definitely was kind of missing always solvable but you know now coming that to riverpod it just makes it super easy but there is one argument though here which I think there will be my last question and we get to pair programming afterwards um so a lot of people say that you know a river pot you say is provider but many people argue that provider it was super simple to use whereas a wider it's not although I usually let me let me say my answer to this because a lot of people say this without really spending maybe a few minutes on the documentation the reason is like well the first thing you see that the provider uh in um River part let's say that's technically provider I mean so without even changing anything people can see that of course it comes with more complexity and more tools but how do you answer this question how do you like usually get back to people if they ask such a things yeah in my opinion um it's such a cliche because there are a few problems involved in my opinion first the documentation of providers ironically bad uh in the sense that it doesn't cover a lot of stuff whereas riverbot tries to go in depth on those topics but it probably confused people because somehow everybody has this a bunch of pages of documentations whereas River providers like barley aridmi and uh and so one of those looks simpler than the other by default ironically um and also um like the uh discussions room provider are usually very focused on certain strategic providers they probably discuss about anything else whereas any article about durable somehow tries to list every single possibilities even though you could technically still use just general TF provider if you wanted to uh like technically basically everything you have in robot you have the same thing in brighter but just people don't know about those like they don't know you can use technology for provider in provider too um or is there a different providers there to Twitter provider um just people took nobody um in fact they're probably more kind of providers in the provider package than in version um so yeah in general I would say in my opinion what about this um probably uh simpler in the sense that if you use it you will have a fewer problems so in simpler in that sense like it the code will work better but it's probably probably um a bit less iterative at first because you're likely use to a different way of doing things so yeah so um um there is a word for it like a short knowledge I'm not sure uh like when you do something so when you get to a new new area you already have you kind of shift your uh way of writing code as well right you know so it's a bit of a different Paradigm which is a bit of uh some people um so that's probably about a part of why people think it's more complex uh because you have to learn a slightly different approach so of course people are a bit disturbed by it um yeah so yeah sounds good Remy I mean this is good so nothing is beating a pair programming with the author of riverpod at this point so I think the best is now let's share your um vs code and let's get into a report and see I really want to show people how author of package or the author of riverbot is using riverpod in an application see it's gonna be funny I I believe so let's get it started Remy then if let's say now you have an application you're sharing your code right now how do you start using Rivers um using riverpod um well the first thing you need to do when you want to use a robot the very first thing is in your vein you'll have to add something called provider's code uh in your application here the first yellow you need of course going forward so jirai you have a few options um so do you recommend okay that's that's one of the question right now then so I see that you're using hook uh Hooks and also um so is this something that you will really start working with riverpod like who is one of your I like everything hooks uh I can understand why some people don't like those which is why it's optional it's voluntarily optional uh for those who don't like it um in my opinion it's nice especially if you want to do something like full metal but if you're getting started with a river but uh you don't necessarily have to think about it uh like the silly stuff with it just start with uh for a river but it's it's fine basically the same thing um you can look into hooks later uh once your remote from where you're always rewarding maybe easier and you know I'm just using it because you know that's my default but I'm pretty used to it yeah that's actually that's what we wanted to see we want to see what's your default as the author of package it's very nice so then hooks is your default that's nice that's also why in the there is a new documentation website in progress where there are a bunch of toggles uh enabled uh in the documentation it does on the top right of the side a bunch of tables about what you want to enable like do you want to enable hooks do you want to enable cut generation and it represents my diff um what I think is a good default for beginners uh so by default hooks are disabled but code generation is enabled my stencil consideration is that uh sure you have to run an extra command you have to run build order but I mean you can start it once in background in watch mode and forget about it so sure as a first thing of your day is it takes maybe a minute um you'll be fine for the rest of the day but then after that point um the benefits of generation are quite big like they allow significant simplifications of your program um you can allow as they can remove a lot of potential errors uh when programming um which is why I use it and why I recommend it um so yeah and especially considering in the future we're likely going to have what's called Static media programming which is called cut generation for Dart directly built into language so you wouldn't have to run this build Runner watch command anymore uh the cartoon version would basically work automatically without you thinking about it so at this point the downside of calculation will basically be none but you would have all the upsides so if you stop using it now uh you probably will have a smoother pass to upgrade once those one subject matter programming is available interesting okay that's very nice to hear about this so then provider actually comes with code regeneration so for for some people it might be a new things because generally is there something a bit controversial and try to offer uh post best Solutions um so if you really don't want to consideration you can do entirely without it um especially once you think about it the robot was originally without generational um it's a fairly recent thing um uh so yeah but if you're new to it and if if you're if you're not sure just stop with calculation uh it's probably going to make your life easier interesting do you want to do you want to show us quickly like for code generation in real about what packages we need to install yes [Music] um it's not here okay I placed it in different place so you you basically need to do a few things um the first you need to install a robot so either Your Hooks are about your forever but whatever yeah and then The annotation package uh both in easy dependencies part and then inside Dev dependencies you'll install big Runner which is used to start the generation and riverbot Generator which is the actual graduation implementation um and then if you're using category you might as well install phrase and uh maybe Json seriesable um which are which are typically used to get uh with server part 2. yeah so for those who probably don't know freeze is also one of the packages that Remy has created so we're gonna have another show about freeze later so let's let's focus on River potting at this point okay so then we have provider scope wrapping our entire app into let's say provider scope what next um and this picture basically set up to start using your debugging your application um so um you can start defining what we call providers and you send um so let's search for example this finder provider um well if we're going to use contractions there is an extra step first um in your dot files when you want to do the construction you have to specify as a part directive which is basically your file name with DOT j.dark .r so here I'm in the mind of dark so I specify main w dot R which is the file is going to be generated here obviously doesn't exist yet um and so if I'm going to use the word but the generator I need to import representation so now I can define a provider a provider is defined with the robot annotation and then you can define a plane function like being held score hello world there's not no word and um and the word so providers Jerry um when you annotate a function with a attribute about view is it has to take one parameter which is what it is a function name with rash assert and um it's like a convention right so yeah and the Power Rangers typically named ref which is a class which will be generated um so if I save now as the Cartoon Network will run and hopefully there probably should be some kind of error because you're returning oh you can see it's because I move actions above specs as a charger stopped oh yeah and let's just return Yes ring please they treat Mr sugar stock now okay should take it down um yeah so now I Define a provider and if I want to use it inside um widgets one of the things you can do here where where are we like if I wanted to show it here or maybe here replace the counter with the yellow Word level we could use a widget called consumer which is basically kind of like your stringular feature Builder the Builder pattern in color which takes two parents and two parameters or three other forgot so with the contacts a rough object which we'll talk about later and the last part which is a nocturnal side parameter and it's not very important right now different performance system organization um and so here if we want to show the yellow level what we can do is uh using this ref object we have here we can use it to create providers so to do that um it's easy or the conclusion like copilot is already doing it for me yeah um I can call ref.watch and pass C provider we defined before uh provider um you see Hello World provider here hello provider is because um we Define a function named hello word and so our robot takes this name they see Hello World and ads provider which is a new variable generated and as you can see here if I go to the definition yeah right you can see it which invokes our load function and because I mean in fact if if you want to Define it without code generation you need to do that yourself if you want to do it without conversion it would likely look something like that now you see once again uh it's a technician does it for me it looks basically this way without consideration um yes I'll remove it but yeah okay so I obtain the provider so now I have the uh content of the provider and I can just show it here so one question that I I get from time to time I like to hear the answer from you is so we're actually getting a reference with watch to a provider in a build method so where build is running many times right so is that safe uh or how does that work um should we always use watch or there is other way to do it as well um there are there are a few methods on here um um but generally basically the rule is if you're in the build method uh you need to use watch yeah uh I've seen many people ask yeah I'm in the build method but the value won't update or I want to optimize things and I want to use what's called a raft.read instead to knock rebuild they would get onesie value changes but that's considered a bad practice you should always use watch if you're within the build metab don't use um if you're if you're within a builder to don't choose a read here if you're going to use implementation if you're going to uh you're still looking after performance optimization um you can use something you can instead do something like rafterquatch dot select select is used in the scenario where you have a knob provider which emits an object which contains multiple properties and you want to listen to only one of these bookies like if somehow instead of the lower it's an obsession vertex I just wanted to show the lens uh there is no need 40 with a jewelry build if ceilings didn't change like maybe it went from a lower to another string of the same lens uh in that case because everyone's yeah please um so if you want to do this optimization you could do select and uh only obtain shared the value would pass to the Callback would be the yellow word string and you can return this lens until you hear you you wouldn't get the string anymore you would get dark with the lens here and you can pass it here well this can this stream of course but this train and and now and they would it will rebuild only once the lens change instead of flame versus Trend changes okay so that's a way of still using watch but but doing the performance optimization um if you want to look into the other ways of listening to things um right if you want to use read the only case where you would use read would be inside things like unpressed and whereas here you can do eras.read well you need a Wrap okay let me keep praying that the ID provider you can do that here because in the own press you don't want your widget to listen to the provider anymore it doesn't make sense here you know that you associate it um yeah so that particularly the rule um in fact there is an upcoming link rule for this um yet but I mean I can talk about it which would basically tell you uh at any given point which uh method you should use so it's not pretty it's actually you have the choice and you need to decide which one to pick is that there is only one choice and uh the choice changed based on your context I see depending on where you are there is always basically one solution okay this is like very less likely than you make mistake here in this exactly it's a Linker will tell you exactly you need to use this one don't use this other one okay in fact it's basically a general rule with provider um with robot um generally there is only one solution to a problem um unless there is something controversial like if you want to do invisible state or immutable State then then offers the Easy Choice yeah but juriser is only one solution um it's just a matter of knowing in which situation you are to know which solution you should use um and so uh foreign like if we go back to the planting tags a common question is which provider you need to use absolutely that was the question yes yeah I I know it's super common one do I need to use the future provider do I need to use this true provider a general tissue provider uh it's very common but um is the irony of this question is that in many opinions it's a bit backward uh it's not do you which provider do you need to use it's uh uh do what you want to do and the provider uh that is that the zip provider necessary will naturally come for you like if you want to make a generative here then you will need to send the digital provider it's not do I want to make a generative provider and then I need to create that into this year it's the opposite way it's I want to make a change here and therefore always Standard TV provider do you see the logic yeah um so basically if you want to listen to Firebase we could expose the stream then obviously you'll use stream provider you wouldn't use something else you wouldn't use gender different provider to listen to a string it doesn't make sense yeah you could try and convert this training to Enchanted tissue but you get the point um so that's where Cloud generation comes in um basically cut generation it's basically Shifting the syntax to uh change how people perceive the problem instead of having to know which type of Provider you need to use you just write your logic and then the all the only obvious choice um of Provider um riverbody picks up for you because now every button is able to determine which provider you need to use so here we made a simple provider and Report was able to determine that we need to use the um provider yeah the provider this one yeah I wanted to use the other compilation but very interesting yeah yeah and so if you had like a stream like a return a streamer string then you would detect automatically stream provider you know streams aren't super Liberty territory yet but yeah and as I will soon be uh so yes that's basically ID if you were to write the async keyword and return the feature uh that would change the generated code to a future provider feature provider yeah try going here you see now YouTube provider so it shifts the problem basically you just write your logic and then the type of provider works by itself like if you now want to make um oh that's very interesting that means like code generation is actually getting rid of uh um thinking behind what kind of Provider you want to select you just write your code in any way that you like to read and I think in my opinion it's always been this way it's just the way people think about it isn't uh because uh the way they write the syntax uh uh lightly confuse some people but I mean the way it was the way use robot I've never thought about which provider do I need to use I just want to do something and then the provider there is just one choice interestingly very nice to approach let's say yeah um so yeah that's one of these things the card generation helps a lot here it it's helped it helps your mind quite a bit for uh to focus on the actual problem at handle just instead of I can't imagine how many lines of code you're also getting rid of uh you know in a normal way of writing provider if we used code generation you probably get rid of a lot of code so imagine now you're gonna Define a future provider or a a Notifier uh State Notifier thingy you know so um it's not it's always the lens of the code it's mostly about because lens wise is basically around the same with a few lines of difference it's mostly about how well it formats and how the utilities around it uh actually if I were to add the uh provider again and the world provider provider that'll work you can see any um like here it looks confusing like you're defining a variable and then with a functional and depending on how long this thing is you can formats weirdly or if you want to have a recursive provider which can happen when you're using family which is something we can talk about too um yeah like if you do something like here by uh combining a provider where provider might depend on a slight variant of itself like rest off watch Hello World provider I like button 42. here you see in the oven error here because provider Doc is getting confused because you have a recursive variable variable definition whereas if you did the same thing uh in Sear with um like if you want to use uh if you want to pass parenters to Providers you don't need to use family anymore so you're not restricted to a single parameter you can just take whatever you want like maybe a required Name barnator ID and then if you want um to do a recursive uh dependency here again there is no problem anymore dark isn't confused you can fall like things nicely like here this is like a blank function like formats nicely whereas if you wanted to do the training comma here it starts might get weird um interesting that that actually the second one the latter one it looks very natural as well the way yeah the syntax is very natural it's just a plain function losing my notation there is nothing very fancy here whereas here you're like did I Define some Google State because I made a final keyword what happened exactly whereas here when you see this you're like yeah I did find a function that's all right um one of the other common question I see is is this like Global variables are bad um why is robot not bad um and I believe photos brought me because here you're defining your final variable but it's more of a syntax thing you're not actually the funny final or where you're more defining function it's a weird function whereas if you're writing this you just Define a function the problem doesn't really mean yeah anymore um when you when you see this code nobody would say no you made it vulnerable no no you just made a function um yeah speaking of that Remy a question here so in in a real application I mean when you start working with an application you I assume that you're probably not gonna write your River part annotation here in the main file right you probably are you going to like keep all of the providers in one file or maybe different or you're gonna Define it where it's needed like in any file that is needed um I generally dislike the um organization where people put all their providers in one place I've seen people have a provided a dark file and put their providers in here I don't like this at all um so why a typically do things in ECS is I put things right next to where they are used so if I if I have a provider that's very specific to just the home page I'll put it next to the own page with it so here it seems in mind.org but maybe I could have a sorry hold on Dart with my homepage with that like stand for and then I got my provider yeah that makes sense yes um and maybe maybe if you're separating the logic a bit and maybe you want to extract just the home UI in one place and maybe the homeless if you're uh you might have to you might have the whole logic.r maybe yeah I think here I'm really which returns Your Home Logic uh yeah first things next to each other so is he basic is a core goal behind this is um it's about making something intuitive when you search for something specific in your project because um generally when you ask yourself where is the logic for something uh you don't know the type of that something like you uh you don't know if you want to know uh okay um what um where is the logic for the user authentication thing you don't know it's just a class you don't know if it was in a provider you don't know if it's an animal or something so when you look at your photography picture and you see a nanium.dart or class.dart or models done darts you don't know which folder you should look into because this file names don't really help you much whereas if you see a user authentication.org design then you will know you want this one instead of I don't know configuration.org yeah it's much more intuitive to look into yep I agree all right sounds good so then um well I mean so you made it so simple that now I had actually a bunch of questions regarding other providers where I see right now with riverpod annotation I don't really need to ask this question anymore because well I go ahead and write a feature and it will automatically detect that so yes but we can talk we can look it to uh into the problem the opposite way and yeah what do you need to write generally instead of web provider um basically the shoulder monkey of uh Riverboat is that um it's trying to make it's true it's basically a way of writing a logic that's very inspired from widgets yeah you know with widgets um your UI is never out of date um unless you're making maybe making instead for it and you'll forget to call State set state but that's an issue that's more of an edge case um because it's uh I'm going to talk about it later basically if you're but it just if you're just writing a bunch of stateless widgets your UI is never out of date you can use team.off whatever whatever this new updates your UI will update capture all uh as opposed to if you were to use some more uh Legacy way of doing things like if you were in web and you created uh these somewhere and then you have to do this dot uh text to call hello and in the creation when you create a div you need to also initialize it here so you have two places where your modified the credit detect I mean it yeah everything um so we just saw a lot of problems here um but we say key logic and uh Central router does the same issue um uh status very what we call imperative um where you still want the same problem where you have an initial value and then on something like on pressed you have some logic to update the state uh so you have to re-rent through the logic again um so you could you could have a bunch of errors here it's probably a bit abstract because I'm not very clear but um anyway um maybe something here would be um basically with root but um I'm trying to offer a different way of writing logic that is a more um I mean is it it's a funny word but more scalable in the sense that um the potential for errors is um much less is there um far fewer irrepossibles like a concrete example would be if you want to do a network request Network request is a very common thing to do and it's a very um built-in thing in robot by the clear Network requests in workload is just a nasing function like if I convert this to async uh by the way that's one of the nice thing with uh the card generator syntaxes you can just use convert tracing it you now have a future provided um so yeah um you make an async uh Network quite so here you will do http.gov whatever uh using your network request you may be the code to your response like response Dot from the user.tronicism you get the point you make sure Network requests here and then in the UI um here um and lower let's go back to this again where the UI naturally um the necessary tools for you to unlock things like error or loading sites like um with the hello world object it'll just have the user or the string in this case you have something called async value if you look at this async value drink an async value um I think like is loading are there I'll tell you kind of like asynch snapshots and I see yeah very similar to that and it has a slight bonus point which which is uh Z1 function which is a neat way of handling all all these scenarios at once so data loading an error um you know in a kind of like a switch case scenario it's very similar if you did uh if uh in the world loading uh error you can see Point um if you looked at the uh read some for our live stream uh which allows pardon Marching for dark this one version is plastic clipboard and merging um it's pattern matching without having button for matching for the artist basically like work around and if you were to do it with Mario matching it would do award Racing loading that is maybe 18 here and here you do return text loading things like that you're right um yes so yeah basically when you make your AC in your network request in word about uh with just this you don't need to do anything as anything for earnings or loading earnings right but you don't need to do a try catch you can let it throw it's fine nothing will happen um and your UI will gracefully handle things even if you make a provider which depends on another product like if I make another request here and I want to combine both robots uh both things um like here already that same name and you want to do full name um I can get the name and call about future trigger run um so crmo obtaining the name from the name provider and then from here um I can maybe uh do um hello name like this um which is an async request depending on a lot or async request I mean that technically could await something else like maybe get last name yeah and um in here we follow uh this uh when we try to read the name if somehow obtaining the name um failed here is this await will fail too with the error that happened and we voluntarily will let this this throw again because then in this scenario they are handling once again is okay the name failed so obviously this should fail to um so hello or this function will throw two which is totally fine and then when when we try to read this new provider in the widget then we can once again handle the errors in this case there is never a case where the errors is kind of like a solid and you for example it you don't have black surprises um um yeah that's a sync or um managers wanted to continue on this uh on this topic and now you made a network request and you want to do something like a pull to refresh which is a very common pattern in mobile applications refreshes not definitely supported by robot um like if you wanted to do a little refraction flower you would do um refresh indicator refresh Burger technique list progress indicator yes progress indicator and then my tickets just a refreshing to get around with the honor refresh call that yes so yeah hysteria you have your UI which is generally a list view otherwise you don't have something scrollable so yeah please view whatever and so in here um you do your refresh you see the automation from the beginning for me um you can just go ref dot refresh your provider and then um which I do this is this is this in itself is in us but generally is the on refresh function expects you to read in literature which completes when the refresh completes yeah right uh and so um you need to return something here and so what you can do is just obtain the um uh feature associated with the network request um and and just return that so by doing this you refresh the load provider which group performs the network request and then you obtain the new you obtain the feature of associated with this request and you're written that and so the refresh indicator will keep loading until the request is complete and that's just that's basically all the logic you need to do for zero Network for your updates you don't need it once again to do any erroring again uh nothing at all just it like your typical logic here um of the one function during the word fresh will correctly shows the previous layer by default it's the same thing C 2.0 version during during a refresh the previous data keeps showing or the previous error if there is one keeps showing instead of showing a a loading State because refresh indicator already comes with a loading state uh you know is there is this little spinner yes so it would be weird to have two spinners on the screen at the same time um so that's the default Behavior Uh by default your UI behaves naturally it yeah interesting universe Yeah well yeah these are interesting so one one more question I mean let's say now you define two uh to Providers and you you want to use both of them let's say in one consumer widget so first of all consumer Vision as far as I know it's not the only way that you can consume providers right so there are other ways to haven't mentioned it on purpose but yes you can't um generally is an alternative to this is consumer is nice uh it basically will rebuild only um only the widget that is contained within the Builder slight downside of consumer is that it has a bit of indentation to your build method um device if you do consumer here too to see better return consumer like you see that it's slightly indented compared to just doing a origin text you're right recording text versus root index uh it's minor but um and it's just keeps drawing um and so if he if he built like this extra lines um there is another solution which is you change the Base Class of your widget to uh you basically takes your widget which you would quickly ask so here we have a stage for widget and you just add consumer in front of it and so here you do the stateful widget so you have to do the same thing for the state so conserve state well obviously it's a correct starting a break too yeah and so by doing that now within your consumer States you now have access to the ref object like with your consumer here and you can do it exactly the same thing here so you can just do wrapped up watch here okay so in fact if you want to do let's say something in initial state then well you can get an access to ref and you can do that right let's say or um is that uh probably a good um correct to say if you are dealing like with with like let's say a couple of different providers in One widget so instead of I mean the only the only disadvantage of using consumer which is going to be the indented you know things that you will receive you can do that though right you can you can have can I have like several consumer Widgets or should I wrap them in there like a parent level of all widget and then use let's say only one consumer per widget or can I have multiple of them you can have as many consumer repair widget as you want uh I need to begin with you can generate the separate widgets so there is no issue here basically if you look at the implementation of consumer it's just a consumer widget which selegates its implementation to a function yeah it does nothing else there is nothing fancy in here um so you could you could use just consumer widget and in fact that's generally what I do it's just um I tend to um split my widgets slightly a bit more than your typical developer I like to make a lot of uh small widgets like if I wanted to do just the text I would likely just do uh like it's just this and take c um my text here well my text yeah consumer widgets and I have this here all right that's that's also one of my questions do you like to use consumer widget as um uh the way that now you're using to extend you know your main class your main widget with that or do you like to use the widget itself the consumer well that's what I was about to cover like if if I make small because I like to make small widgets like this which are very uh uh focused on one thing and so um at this point the consumer widget like the Builder the Builder one this one consumer with the ref here it runs very little value here and yeah because you're basically even even with this even without it you're still already rebuilding only the texting because since you're making small widgets like when you when you when you use um rev.watch it rebuilds the widget associated with the rest so here the ref is coming from my text so only my text Will Change will update when the provider updates so your scaffold walkthrie build when you do that and all and so at this point uh the consumer thing basically does the same thing in fact you just added an extra with it for little value and so at this point the value of removing one level of an indentation and all uh comes in ND and also one thing I really like with this but it's a bit Advanced um is with consumer widgets you can have a Constructor uh in the benefit of contractors when you split your logic in small bits like this and where your state is coming from providers you generally have no parameters all in here um and so if you have no parameters at all your Constable structure becomes very powerful because you can almost always instantiate your computer your widget with the Colts keyword even though this state actually can change over time um which means that by doing this here when you do comes my text say is this widget did a REV dot twice here another provider and zip that and through whatever and and this provider updates but the provider watched by my text doesn't we don't want to update this text when this provides changes right we won't do already update what matters and since we're using the cost control flutter will naturally detect that sequence the widget instance didn't change and therefore not rebuild uh the my text widget when this one updates yeah you basically get performance of the musician by default without you having to do anything just just through this kind of keyword yeah yeah sounds good yeah it makes sense which you wouldn't get if she did the consumer thing because you can't still do comes here as you would use a social well those solar fortunes can become okay that's interesting so then generally um breaking down to smaller smaller widget with consumer widget extending your widget with consumer widget is kind of like a best practice here in this case yes because we get Constructor and all of the benefits that you mentioned yes exactly but I mean I guess that many people generate don't tend to do that so that's why I mentioned consumer first because as they will update only what's necessary and then I can look into consumer widget at all uh yeah if they want to but yes see is it the uh best practice would be to just do a small widget like this and you get it's basically the most efficient approach while also very irritable in my opinion yes I agree with that and probably maybe also easier to test so you're dealing with only one piece of widget to test later yeah probably yeah okay so um so far we this was great so far only one more question because we talked about it but we never used it so at least we want to hear your opinion what when or what we're going to use um hooks here in this case I knew it um if folks uh riverbot art is certainly considered um is really use for what we call Global state like your application State like your user your current user things like sales whereas hooks is more for local state local widgets type so if you have a widget that's animating there is generally an animation controller if you have a form you have some text editing controllers and all and those aren't shared between widgets it's just specific to one very specific which um so that so if you want State specific to One widget you will you can use hooks you could use a stateful widget but you could use alternatively hooks um and so one nice example is say you want to make um a text field makes field and you want existing culture here you cannot do dentists in control here like that because you're vaccinating which are would be recreated whenever see my text update so you would need um you would need um hello doesn't look good date oh breaking two pages you need to convert it to a stateful widget to send the controller uh I think yeah controller it's a big tedious and then you need to you shouldn't forget to dispose it to worries sure how much if you don't but you probably should um so yeah launch of logic here and if I were to do the same thing with um hooks instead where you would subclass who created or if you're using a robot you can consumer with it which is basically the combination of consumer widgets okay so it basically boasts this and from this anyway uh yeah let's continue with that I try to use it real quickly using the ref parameter um and so in here we could use this exact same logic here um but instead of making your thoughtful widget we could use what we call a hook so sorry typically functions um which starts with the keyword you use if there is no use keyword at the front of it it's not a hook and and so those functions can only be used within the build function and they are basically stateful function where when the build function or executes the state Associated to this function is preserved okay so here I'm using uh from the um is it important no it's not let's import it shared Focus so this is a hook from the floor hook function of front rocks package which basically takes the logic of doing all of this inside just this one liner so it creates a controller and it disposes it and when the widget reveals you would really you would reobtain the process you would create a new controller whenever this is updating so basically this is all strictly equivalent to doing this I see and the nice thing is with hooks you can do two of them if you wanted to and you would obtain two different controllers so that would be a cool amount of doing magic design um you can see how the logic is basically could be could um the number of lines could basically quickly exponentially increase if with yeah and even even though here that's a fairly simple use case where we're just disposing something um like if somehow now you want it to listen to the changes on the text editing controller and update the UI whenever it text changes one thing you could use is um a reasonable Builder and iPad select mobile controller because controller is a chain conditioner which is a reasonable and then in here we can pass the Builder and maybe child I believe yeah which sends this function will update whenever the text field updates so well here we don't have a text but also obviously it will never update but you get the point if I pass this controller to a text field this widget would updates when the text field the Z text change uh but I mean we use the Builder the equivalent of doing this with hooks would be use listenable and you pass the controller the use listenable is basically it's strictly equivalent to the listenable Builder I see and so uh instead of doing return text uh controller.text here you can remove this year by just with just this line here and the interesting side effect of this is hooks are just playing functions which means you can make functions which use those functions so you could make you could combine say you want you only need to use those two hooks very often together you could make a separate function like let's think I'm sure Music City controller and listen we could do interesting yeah of course yeah you could call us out and we can control both and return the controller and then you use analytics and and you can reuse this multiple times if you wanted to and then this would then listen to both printer rows and you could use both if you have a separate text so you see logic is very reusable you can make smaller cities which you can share between widgets if you make a separate widget this is a record that can also use this new function as opposed to if you did this here with a stateful widget is very difficult to share the logic of disposing those things and if you made a listenable builder here there is nothing you can really reuse between widgets whereas here you can very easily reuse this logic yes now probably makes sense for many people why they need to use you know hooks it's a bit different I won't deny it and there are some some rules around it I would suggest you're looking at the redmi uh you can't do shrinkbot it's considered antibatter to do conditions around hooks for Loops uh like while you only need to uh you need to always invoke your um hooks you never conditionally involve them yeah um so that so it's a bit tricky uh it's not very flourish to so I guess why some people wouldn't use them but there's definitely some problems that they solve so if you find if if you're interested by them go ahead and use them if you're not then that's fine um I I understand very nice Remy well this was very interesting to me uh watching you writing some River pass code so I guess you don't really enjoy yourself writing every report because you do that every day but I think it was very interesting for me and in probably many of the viewers right now so last question is okay so if you want to say anything about riverpod in general anything that is upcoming or incoming or you know generally this is the last words that you may say to us right now look um what else the last four I guess I could um if anyone is interested in helping I would uh lost some help on documentation and um yeah documentation primarily like and uh I'm sweating a little bit with documentation I know that the documentation is a bit sometimes confusing to newcomers um I strongly believe that robot is um simple if if you can understand if you can understand if you're familiar with it but many people tend to be scared by the documentation so if he if you're motivated by it um reach out and uh and try to help and I'd love to um to see what we can do together and um I mean when considering um maybe giving some reward reward rewards to people who contribute like maybe sending a shirt I don't know some stickers or we'll see we can we can look into it together um it would like it would help me a lot and it would it would help the community as a whole um so yeah right I mean definitely I will put the link to contribution guide as well as the repo to the description below um as well as all the Remy's um you know way that you can connect with him Twitter and other repos so please take a look at the repo and help Remy to write better documentation I mean in fact maybe only not writing documentation but also creating any type of content that may uh make it easier for people to understand riverpot yeah so that's also a type of contribution which I think Remy will appreciate for sure that's very nice and thank you very much Remy for joining this show I think this was uh very interesting to me to hear from you um how you would use riverpot and it will probably clarify a lot of things from other people too right when I use that when I use this and you know how should I combine how should I dispose and so on and so forth that you clarified at least from your point of view and that was super interesting to hear thank you very much once more to join translate joining this session foreign foreign

Riverpod is a reactive caching and data-binding framework that was born as an evolution of the Provider package. According to the official documentation: Riverpod is a complete rewrite of the Provider package to make improvements that would be otherwise impossible. In this video, I have pair-programmed with the author of Riverpod and many other #dart and #flutter #devtools and libraries, Remi Rousselet, on how we should use Riverpod properly. 00:00:00 Introduction 00:04:26 Provider to Riverpod, Remi's answer! 00:15:44 Pair programming with Remi 01:08:22 Last words ---------------------------------------------------------------------------------------------------------------- Pub: https://pub.dev/packages/riverpod Website: https://riverpod.dev/ ---------------------------------------------------------------------------------------------------------------- Remi Rousselet Twitter: https://twitter.com/remi_rousselet/ Majid's Twitter https://twitter.com/mhadaily ---------------------------------------------------------------------------------------------------------------- Let me know what packages or plugins you would like to see in the show, and I will do my best to invite the authors for pair programming. Consider sponsoring my time to support my open-source and video work 💖 Github: https://github.com/sponsors/mhadaily?o=sd&sc=t Or join this channel as a member.