derivedStateOf — a extremely frequent query we see is the place and when is the proper place to make use of this API?
The reply to this query is derivedStateOf {} ought to be used when your state or key’s altering greater than you wish to replace your UI. Or in different phrases, derivedStateOf is like distinctUntilChanged from Kotlin Flows or different related reactive frameworks. Keep in mind that Composables recompose when the Compose state object they learn, modifications. derivedStateOf permits you to create a brand new state object that modifications solely as a lot as you want.
Let’s check out an instance. Right here we have now a username area and a button that permits when the username is legitimate.
It begins off empty and so our state is fake. Now when the consumer begins typing, our state accurately updates and our button turns into enabled.
However right here is the issue, as our consumer retains typing we’re sending state to our button time and again needlessly.
That is the place derivedStateOf is available in. Our state is altering greater than we want our UI to replace and so derivedStateOf can be utilized for this to scale back the variety of recompositions.
derivedStateOfLet’s undergo the identical instance once more to see the distinction.
The consumer begins typing, however this time our username state is the one one which modifications. The submit state simply stays true. And naturally, if our username turns into invalid. Our derived state accurately updates once more.
Now, this instance is a bit oversimplified. In an actual app, Compose would almost definitely skip recomposition of the submit composable as its enter parameters haven’t modified.
The truth is, the conditions once you want derivedStateOf can really feel few and much between. However once you do discover a case, it may be supremely efficient at minimizing recomposition.
All the time do not forget that there must be a distinction within the quantity of change between the enter arguments and output outcome for
derivedStateOfto make sense.
Some examples of when it could possibly be used (not exhaustive):
- Observing if scrolling passes a threshold (scrollPosition > 0)
- Objects in a listing is bigger than a threshold (objects > 0)
- Kind validation as above (username.isValid())
Now, let’s take a look at another generally requested questions on derivedStateOf.
Whether it is inside a Composable perform, sure. derivedStateOf is rather like mutableStateOf or another object that should survive recomposition. For those who use it inside a composable perform then it ought to be wrapped in a keep in mind or else will probably be reallocated on each recomposition.
Keep in mind with keys of every state and derivedStateOf can appear fairly related at first look.
The distinction between keep in mind(key) and derivedStateOf is within the quantity of recomposition. derivedStateOf {} is used when your state or key’s altering greater than you wish to replace your UI.
Take for instance enabling a button provided that the consumer has scrolled a LazyColumn.
val isEnabled = lazyListState.firstVisibileItemIndex > 0
firstVisibleItemIndex will change 0, 1, 2 and so on because the consumer scrolls and causes readers to recompose each time it modifications. We solely care about if it’s better than 0 or not. There’s a distinction within the quantity of enter we have now and output we want and so derivedStateOf is used right here to buffer out that pointless recomposition.
val isEnabled = keep in mind {
derivedStateOf { lazyListState.firstVisibleItemIndex > 0 }
}
Now, let’s say we have now an costly perform that calculates one thing for us with a parameter. We wish our UI to recompose any time the output of that perform modifications (importantly, the perform can be idempotent). We use keep in mind with a key right here, as our UI must replace simply as a lot as our key modifications. That’s, we have now the identical quantity of enter and output.
val output = keep in mind(enter) { expensiveCalculation(enter) }
That is the place issues get slightly difficult. derivedStateOf can solely replace when it reads a Compose state object. Every other variables learn inside derivedStateOf will seize the preliminary worth of that variable when the derived state is created. If you must use these variables in your calculation, then you may present them as a key to your keep in mind perform. This idea is far simpler to grasp with an instance. Let’s take our isEnabled instance from earlier than and develop it to even have a threshold for when to allow the button, slightly than 0.
Right here we have now a button that permits when a listing is scrolled over a threshold. We’re accurately utilizing derivedStateOf to take away the additional recomposition, however there’s a delicate bug. If the brink parameter modifications, our derivedStateOf gained’t take the brand new worth into consideration because it captures the preliminary worth on creation for any variable that isn’t a compose state object. As threshold is an Int, no matter is the primary worth that’s handed into our composable shall be captured and used for the calculation from then on. ScrollToTopButton will nonetheless recompose, as its inputs have modified, however as keep in mind with none keys caches throughout recomposition, it won’t reinitialise the derivedStateOf with the brand new worth.
We will see this by trying on the outputs from our code. At first every little thing is working accurately.
However then a brand new worth (5) for threshold is handed into our composable.
Despite the fact that our scrollPosition is lower than threshold, isEnabled remains to be set to true.
The repair right here is so as to add threshold as a key for keep in mind, this may reinitialise our derivedStateOf state anytime threshold modifications.
Now we are able to see, when the brink modifications, the isEnabled state accurately updates.
Almost certainly, no. When you have a number of states which are combining collectively to create a outcome then you definately most likely need recomposition to occur any time certainly one of them modifications.
Take for instance a kind that takes in a primary identify and final identify and shows a full identify.
Right here, as our output modifications simply as a lot as our enter, derivedStateOf isn’t doing something and is simply inflicting a small overhead. derivedStateOf additionally isn’t serving to with asynchronous updates, the Compose state snapshot system is coping with that individually and these calls listed below are synchronous.
On this case, there is no such thing as a want for an additional derived state object in any respect.
To sum up, do not forget that derivedStateOf is used when your state or key’s altering greater than you wish to replace your UI. For those who don’t have a distinction within the quantity of enter in contrast with output, you don’t want to make use of it.