Everything you need to know about the New Styles API in Jetpack Compose

Ajouté : 2026-05-24

[00:00:00]If you didn't watch a Google IO 2026, you might have missed the big news about the new styles API. So, what it is? How does it work? Does it replace modifiers?

[00:00:10]What are the benefits? Well, let's find out.

[00:00:19]The new styles API is already available in a jetpack compose. The style API is a new way for a customizing elements and components in jetpack compose, which has traditionally done through modifiers.

[00:00:32]So, does that mean that modifiers are now deprecated? The short answer is no.

[00:00:37]Styles are not replacement for modifiers, but they do act as a replacement for a styling parameters, such as a padding and colors. This means that the styles API was not meant to be used for some behavior stuff, like gestures, clickable interactions, accessibility and other. The styles API was primarily made to be used for styling capabilities. And my personal opinion is that they have pushed this new styles API because a compose a multiplatform for the web is currently in beta. I would assume that the web platform for compose multiplatform will become stable at the end of this year. And they do need a way for handling these animations and styling options for the web platform more gracefully. With the new styles API, now we are able to stylize and animate different kind of states of our component, like the hover state, selected state and other, which makes things a lot simpler for the web platform. But of course, that's not the only reason. There are multiple reasons.

[00:01:39]And we're going to get back on that a little bit later. Before we get into the code and I show you how we can use this new API, let's first understand what is the main difference between modifiers and styles. In the official documentation, you will often find that these two terms, like additive and over writable. So, modifiers by default are additive. That means that uh we are basically rendering these modifiers from the top to the bottom. And the actual outcome of our styles will depend on that specific order, right? So, for example, if we specify first the background color red using modifiers, and then below it we specify the background color, let's say maybe uh blue, it would mean that the modifier will uh draw two different background colors. So, first it will draw the red color background, and then it will draw another color on top of that. And that's what it means additive. With the new styles API, the last style actually wins. So, for example, if we declare the background first, and then after a couple of different styles, we again declare the background with a different color, that the last one that was declared will actually win over. And we're not going to draw the background two times, only once. So, there are three core concepts uh when it comes to new styles API. So, we have a style, style scope, and style state. So, what is the difference between them? Well, the style is an interface that defines the appearance of the UI element with a standard set of a styleable properties.

[00:03:06]It's a similar to the CSS style. Next, we have the style scope. It's practically similar to any other scope that we already have with Compose, like the row scope, box scope, column scope, and other. It practically means that we're going to be able to use certain functionalities of a styling our components only within this style scope.

[00:03:25]And finally, we have the style state.

[00:03:27]So, this uh style state uh acts as a some kind of a bridge between these uh behavior kind of uh interactions and our styles API. So, it provides some uh states like uh is enabled, is pressed, is checked, is uh hovered, and so on. If you want to use this uh new styles API, you would have to include at least uh this uh version 1.11.0 alpha06. So, enough talking for now.

[00:03:51]Let's open up our Android Studio and see how we can use this new styles API in practice. All right, so the first step thing here I'm using even the higher version than the one that we have seen right now in the presentation. And these are all dependencies that I'm currently having in this version catalog file. In this case, we have a simple box that acts as a parent, which will center its child components on the center of the screen. So, let's declare one again box composable function and we can specify the modifier. Now, the material theme currently does not support this new styles API completely. For example, if we try to call like the button composable function, you will see that that button does not have any parameter which contains that style interface. But that doesn't mean that it will not contain it, right? So, in some of the future releases, they will modify these pre-made components to include that custom style parameter that we can use to to provide our own custom stylings to each one of these components. But for now, we are going to use that a styleable modifier, okay? So, let's call here the modifier and then styleable.

[00:05:01]So, this styleable modifier contains a couple of different parameters. Usually, there are two. So, the style state, which again it provides that kind of a behavior for our stylings. And we have the actual style interface. So, for now, I'm not going to pass here anything and we can just use this to refer to this actual style scope in which we are able to access different kind of functions so that we can see what kind of functions we actually have here. So, there are a bunch of different functions which makes it pretty similar to the modifier itself. So, we have the content padding, size, width, shape. We even have the animate block which we're going to talk a little bit later as well. We have the background, border, and many other different styling options as well. Now, not all modifier capabilities are included in this style scope, while all these style functions are already available in the modifier scope or in the modifier itself. Nonetheless, let's here define, for example, fill max width or a fill width in this case. I'm going to declare here, for example, the height 100 DP as well, and the background can be set to be blue. So, if we now run this example, we're going to see that blue component. Right. So, it's pretty static and a simple styling. But, did you know that we can actually declare here how this component will look like when it's in a different state? Like, for [snorts] example, pressed. So, we have this pressed function that allows us to specify different [snorts] styling options when this component is in a pressed state. So, for example, we can just copy this same function for the background and set its a value to red. So, this pressed function practically also provides that same style scope, in which we can declare all our styling options. So, if I now press here, you can see that nothing will happen.

[00:06:52]So, why is that? Well, that's because that our component is not clickable yet.

[00:06:58]So, let's add here the clickable modifier. So, we're declaring that modifier inside the modifier and not inside a styleable modifier, right? So, that's a behavior which is not available directly in this style scope itself. So, now if we run our application and try to click this component, as you can see, the ripple effect will indeed be visible. But, we're not going to see this red background at all. So, why is that? Well, that's because that we do need to pass the style state. So, the styleable modifier accepts the style state. So, let's declare one state. So, style state, then we can call remember a mutable style state.

[00:07:34]And this mutable style state accepts the interaction source. So, let's also create that interaction source. We can do that by calling this mutable interaction source and I just constructing that object right here.

[00:07:46]Then we can use that to pass it right here as a parameter of our style mutable style state and then we can pass this style state to our styleable function.

[00:07:56]The only thing that is left is to now pass this interaction source to our clickable modifier right here. So now let's launch our application again and as you can see now when we click on this actual component then this press state will be re-rendered and the background color will change. So with this right here we managed to implement this transition between different style and that transition is only available with this interaction source or our style state. Because as we already mentioned the style state is the one which acts as a bridge between the interaction and a style API. As we have already mentioned before modifiers are additive and the styles are over writable which means that if we add of course a multiple background properties the one which is the last specified will actually win.

[00:08:48]And the same applies with any other styling properties like for example shape in this case.

[00:08:53]First from this code right here you can see that we have specified a shape to have the rounded corner on each and every angle of a 16 DP. However, on the bottom the last shape parameter or property that was actually called was the one that used the rounded corner shape only on the top left or top start angle. And this means that this last one actually overridden the previous one.

[00:09:18]This is also one more example of how the behavior of the new styles API actually works. So we have the content padding so we are practically declaring the content padding in this component to 50 DP and then after that we are rendering another content padding in this case it's a different property which is why it is not overriding the previous one. So, this one is called the content padding bottom and it adds up 150 DP on the bottom as well. Now, we come to the question why should we use the new styles API? Well, there are multiple reasons. The first one is the flexibility because it offers a more concise and declarative way to define styles. The most important part here is that the styles API is made to be more performant than the modifier styles because these new styles will run in the draw and the layout phases while skipping the composition phase. And of course, this new styles API is also created to be used with the animations as well. So, in the style scope, we already have a function called the animate where we can animate different kind of a properties in our component.

[00:10:23]So, let's try it out. In this existing example in the press state, I'm going to call the animate function and then in this block, I'm going to call the background red. This animate function also sets a couple of parameters so we can define two and from specifications for the animation or we can just define a single one. So, let's define here the the spec for example saying tween with a duration of 500 milliseconds. Okay? Now, launch the application and when we press on this component, as you can see, the color will now animate for 500 milliseconds.

[00:10:59]So, this animate right here should be more performant than animate DP or animate color as a state function since this one will actually skip that composition step increasing the performance of our UI rendering. So, styles support many of the same properties that modifier support.

[00:11:18]However, not everything that is a modifier can be replicated with a style.

[00:11:22]You still need modifiers for certain behaviors like interactions, custom drawing, or stacking of properties. So, by having both additive and overridable behaviors, now the Jetpack Compose is a lot more flexible and we can use either one of these approaches. Besides that, we can also define the style as a standalone style by using the style function. So, in this case, we can put that a style inside the variable and then pass that variable and then reuse it in a multiple other places. For example, we can create a unique style for the button component and then pass it around in each component that we want to have the same style. We can even create an extension function on the style scope, define our own styling properties, encapsulate it into one extension function, and then pass that function in the style scope wherever we want. Now, when creating a custom components of ours, it is recommended to add a style property or parameter to those custom components so that the user can specify and the customize the styling of those components from the outside as well, similarly like we do with modifiers. Also, one more thing which I want to showcase here is this remember updated style state function that we use with interaction source as well. So, I'm going to explain why this function is important and how we can utilize it. So, here is one custom component that I have made here, okay? That component contains, of course, as always the modifier as a parameter, but now when we have this styles API, we should also include a style as a parameter to each one of our custom components. Now, this style is actually an interface and by default these interfaces are considered as unstable, so I'm not really sure if this style is going to be stable eventually or if they are trying to make it stable because this way our custom components might be recomposed more than they should. Here, you can see that we have the interaction source that we have, uh you know, either passed here as a parameter or we are constructing it manually. And we have this remember updated style state. Here, you can see that uh we are practically accessing that uh state of our style state, in this case enabled, and we are providing that enabled state from the parameters of this custom component. Because otherwise, if we didn't use this approach, what we could do is create a new style uh state like this, and then remember a mutable style state, and pass this interaction source. But, in this case, we wouldn't be able to change this uh is enabled uh property of the style state based on this parameter, unless we used the side effect. So, the other uh workaround would be to add, for example, the code that will uh look something like this. So, if we don't use the remember updated style state, we would have to trigger this uh code in some kind of a side effect. And that is uh not a ideal way, right? So, instead, what we should do, we should, of course, use this remember updated style state, and just uh modify uh its own states inside here accordingly, which is much cleaner. Now, as I already mentioned, we are able to access and uh modify different uh states of our component, like the pressed. Uh we also have a selected. Uh we have a hovered state, which is really important for the web platform. We have the focus state uh and uh other ones as well. The last thing that I want to mention about the styles API are uh its current limitations. So, right now, infinite animation is uh not supported uh with the styles. There is no support for custom properties that extend beyond these uh standard style attributes. Uh custom shapes are not yet supported. Uh it will be fixed in the future versions. And the shape animations are also not supported yet.

[00:15:09]There is also uh not a support for interoperability with the view system themes and styles. And when it comes to uh interoperability with the ripple uh effects, uh using, for example, pressed without uh setting the indication to null on a clickable modifier will result in a both being shown at once. So, you might want to consider passing this indication to null if you don't want to see a double ripple effect. Here are also some uh guidelines uh like uh do's and don'ts that we can follow for a best practices. We should use the style for a visuals and a modifiers for behaviors kind of stuff. We should always expose the style parameters uh in a custom components that we create by ourselves.

[00:15:47]We should consider replacing a multiple styling parameters of our uh custom components with the unified uh style parameter to encapsulate all these styles all together. We should uh prioritize uh styles for animations, so we do have that animated block that we can use to animate between different uh states of our uh component as well. When it comes to don'ts or what you shouldn't do with the new styles API, you shouldn't attempt to handle on click or a gesture detection within the styles because uh styles are limited to the visual configurations based on the state. And uh yeah, that's pretty much it. So, there are also other different uh useful information that you might find this official documentation about the new styles API. Uh that was everything that I wanted to show you in this video uh in this overview video about the styles API. So, let me know your thoughts in the comment section down below. Uh write me down if you want to see more videos about this topic in the future. And of course, uh don't forget to leave a like to this video, but uh only if you find it helpful.

[00:16:43]Thank you for watching. I [music] don't mind if I die, I'm a legend. When [singing] they lay me down, I'm at rest.