Jetpack Compose — When ought to I take advantage of derivedStateOf? | by Ben Trengrove | Android Builders | Nov, 2022

— 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 ought to be used when your state or key’s altering greater than you wish to replace your UI. Or in different phrases, is like from Kotlin Flows or different related reactive frameworks. Keep in mind that Composables recompose when the Compose state object they learn, modifications. 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.

Preliminary state of username and submitEnabled

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.

State updates after the consumer continues typing

That is the place is available in. Our state is altering greater than we want our UI to replace and so can be utilized for this to scale back the variety of recompositions.

Updating the code to make use of

Let’s undergo the identical instance once more to see the distinction.

State updates with derivedStateOf

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 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 to 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 .

Whether it is inside a Composable perform, sure. is rather like or another object that should survive recomposition. For those who use it inside a composable perform then it ought to be wrapped in a or else will probably be reallocated on each recomposition.

Keep in mind with keys of every state and can appear fairly related at first look.

The distinction between and is within the quantity of recomposition. 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 .

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 is used right here to buffer out that pointless recomposition.

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.

That is the place issues get slightly difficult. can solely replace when it reads a Compose state object. Every other variables learn inside 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 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 to take away the additional recomposition, however there’s a delicate bug. If the brink parameter modifications, our 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 , no matter is the primary worth that’s handed into our composable shall be captured and used for the calculation from then on. will nonetheless recompose, as its inputs have modified, however as keep in mind with none keys caches throughout recomposition, it won’t reinitialise the 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 for threshold is handed into our composable.

Despite the fact that our is lower than , remains to be set to .

The repair right here is so as to add threshold as a key for keep in mind, this may reinitialise our state anytime threshold modifications.

Now we are able to see, when the brink modifications, the 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.

Related Articles


Please enter your comment!
Please enter your name here

Latest Articles