State Management in Jetpack Compose (Why State Hoisting is so Important) - Android Studio Tutorial

what's up guys and welcome to this new video about State hosting in chapter post this will be the third video of a two video series which will basically cover everything about State Management and Jetpack compose as I already said we will start with State hoisting which is so important in order to use check and compose the right way and in the next video we are then going to talk about stakeholder classes so where you actually should put your state in if a real model is required if you can manage the state inside the composable if you need to create another composable which is responsible for only a holding State and all that stuff I think there won't be any questions left after these two videos all right okay I'm in Android Studio here and I've created also this little example two composable functions nothing special here very very simple but before we will talk about State hoisting we first need to know what state less and stateful actually is we have this count composable here the second composable which has this counter variable and this is a mutable state of so this counter is a state bar this means that this composable discount composable is stateful it contains state it holds State and this example screen composable which invokes the count composable has no State it's hold no state so it's stateless this is these are two very important definitions here stateful and state less composables the main concept behind State hoisting is now to extract the state out of composables which get invoked to The composable Scholar so that they invoked composable gets stateless and the color composable is stateful to now conform to this protocol we need to extract the counter States out of the count composable and put it inside our example screen composable because the current composable gets invoked there the example screen is the caller and the current composable is the composable which gets called but before we apply this let's talk about the benefits and maybe you're already asked yourself why the heck should I do this uh this is fine so far if I click on this partner here the counter gets increased and the increased calendar is then displayed in this text composable this all works very fine why should I change this why should I Hoist the state here and in this example I agree this is fine this works if you would invoke it and press on the button multiple times you won't have any state issues there everything would work properly but let's talk about the huge disadvantages when your screens and your compostable expand the first disadvantage would be if you would need the counter somewhere else if you would have another composable which also needs this calendar let's just quickly copy and paste this here and call this count composable tool so now you have two composables which have both the count States but if you want to show the same calendar how would you do this like this so you need to share the state here and this is right now not possible because each state is internally hold inside the composable and can be accessed from another composable so this would be the first problem let's remove discount compostable again and have a look at the second problem up here in our example screen let's imagine we wanna show a different partner or a different composable if the counter actually increased by 10 or something like this we want to check if counter is greater than 10 and then we want to show a button which maybe says you have reached the limit or something like this how would you do this because you don't have access to this calendar down here you you can't access it and you wanna have access to it but in this scenario when the state is in internally inside the child composable which gets called This is not possible so this is the second problem all right okay let's talk about the third problem for that we removed this if condition here and we also can copy and paste the counter State up here like this and then we could say something like this counter or type inch which gets in as a parameter here and we can pass the counter variable like this and then we can remove the state and we get a compiler error that the value cannot be reassigned because the parameter gets always passed as a value and maybe we would now do something like this via my counter by remember and then we would say mutable state or condor so that we have state again which we can then increase and we can even pass the counter as a key for the remember here so that this always gets triggered when the count composable gets invoked with another counter value so and now we can make this my calendar plus plus to increase it on a button click and we can also display my calendar as a text and this example works it will increase the counter properly and also show it properly on the UI but it works only as long as there's no other compostable which also needs to access to this calendar and also want to display it let's copy and paste this composable like this and it's called discount composable tool if we would have it like this then each count composable would have a my calendar which are two different counters than they which simply increase with this button click to different counters and they will just show on the text field or on the text display their own counter and there's no shared calendar here and this is not possible with this scenario this problem demonstrates very well that there's not only state hoisting required when it comes to readings State it's also required and very important when we want to update State when we want to write to State like we do with this calendar increase let's go up here and I also forgot to invoke the card composable tool I think this should be fine though and how can we fix this now how can we hoist State writing out of our account composables we can add another parameter here which will be an increase Lambda function which won't take anything and also does not return anything and up here we can then invoke the Lambda function and we can then simply say count dot Plus Glass and the same thing for our composable tool we will also say counter plus plus then we can copy and paste this increase down here and when we click on the button now we can say increase and invoke this Lambda function and the same thing for our other compostable here and we then can also remove this mycounter state variable and take this counter for the text display the same thing down here we will take the calendar and remove the state variable so both count composed builds are now stateless they don't have state but they can reach the updated stain at any time because up here the count composable and account composable tool always get invoked when the counter actually changes and gets then the most actual the latest value of the calendar and can always display the current one and also of course the hoisted State writing which happens in this Lambda block is also extracted out of our account composer builds and now in our example screen which actually belongs to this leads to two composables which are totally stateless which are totally reusable and don't have different counter variables they always have the most recent one and this looks very clean in my opinion let's also have a look at the more real world application example where there posting is also very powerful I've also recreated another example here because I think this would be nonsense if I type this off let's go quickly over it's it's uh kind of easy to understand we have a text field input composable here which takes the text and a modifier and then we have the initial text the internal text which is a state so this text composable is stateful and it also has another state which indicates if the text input is valid or not and it simply checks if the text field is not empty then we have a column with a real text field here this text field has the text as the value so our current state because it needs a state value and if the state value changes then we get the new value provided here and we can update the text and we can also check if the input is in is valid or if it's invalid and also modifier for a little bit of styling here and now we also want to show a text if the input is not valid that there is an invalid input and we will show this as a red arrow on the bottom up here we have an example screen which has a column and in this column our text input field gets invoked this example screen does not hold any state it's currently stateless and the invoked composable is stateful so there is no State hoisting at all let's imagine this is the initial scenario and everything works but if you want a little adjustment now just a little adjustment depending on this state here then nothing will work anymore because if you wanna check here if the current input is valid like this and show a corresponding partner to confirm the input or something like this then this is not possible because this States is not hoisted the state is inside the call composable and it's handled internally also if you want to access this text if you want to access the text which the user typed in and you can't access it even if you have a button here to confirm the input you can access the text how would you pass this text to your view model to process login request or something like this and this is so so bad and so important that state hosting is handled properly the problem now in such a case is that there are tons of possibilities to make this work even without state oysting for example you could pass the view model down here which is so so bad you could could pass the view model down here and say if the input is valid then you will show a confirm button and invoke The View models login starts then or something like this this would of course work but this would make your text input field composable so much bigger and the text input field composable would also have a an additional button and you would end up with compostables that aren't reusable at all they are not testable they have inconsistent datas and all the problems and this can all simply be avoided with State hoisting so let's change this example and apply State hoisting we will make our example screen compostable stateful we will say VA is valid but remember mutable state or and this is false by default also we have power texts if I remember mutable State off and this is empty by default in a real project maybe you have a predefined text or also empty text or maybe also view model but let's put the state up here for the sake of Simplicity and then we also need to modify the text input fields we need to add the Callback function where we actually can change the states because as I already mentioned State changes state writing also needs to be hoisted let's go down to our text input field and remove the state here so the text input field is now stateless we also need to provide additional Lambda function for the on value change callback and of course there is valid so up here we can say it's valid of type Boolean and on value change which provides a string and returns nothing like this and then we can simply pass the Lambda functioner we can cut this out and pass the Lambda function here and then everything is fine here our text input field is now stateless and can be invoked on every position in our screen from everywhere we can reuse this compostable where we need it we need to just test and it's valid Boolean on change Lambda block and a text string and of course the modifier if you want so and then we also need to pass all the values here we need to define the on value change like this we get the value provided here and we updates the text which is defined here and also the is valid state which is defined up here and also we need to pass this valid is equal to is valid and then this should actually work and this text input field can be used everywhere and it's totally stateless now everything is so much easier if we want to show a button depending on if the text input is valid we can simply say if it's valid and then we will show the partner and we also have access of the text inputs because it's also defined as a state here and only gets here updated in this on value change Lambda block so we could say something like this viewmodel log in with this text and we would have access to this text so this makes it so much easier for us if we do proper State hoisting all right okay this was it for this video I hope you enjoyed it and you learned something about State hoisting in the next video we will have a look at different possibilities to create States so let's have a look up here if you maybe have asked yourself what's this buy remember is we can also use the equal sign then we can also have mutable state or mutable list of mutable State list of and all that stuff and when you also ask yourself when should I actually use a view model when should I use another stakeholder compostable class and all the things will be covered in the next video so there won't be any questions left how to handle and how to place and where to place your States see us then

Channel: K Apps

Views: 2,020

Keywords: Jetpack Compose, Jetpack Compose State, State Management, Android Jetpack Compose, Android State Management, State Hoisting, State Hoisting Jetpack Compose, State Jetpack Compose, State Android, Compose State Management, Jetpack Compose State Hoisting, Clean Code Android, Clean Architecture, Android State Hoisting, StateManagement, JetpackCompose State, Jetpack Compose StateManagement, Kotlin State, Kotlin State Management

Id: 8h1trLWAymU

Length: 15min 21sec (921 seconds)

Published: Wed Nov 09 2022