I notice we keep on getting new Compose Material3 ...
# compose
m
I notice we keep on getting new Compose Material3 Component (org.jetbrains.compose.material3) alphas across minor versions (e.g. 1.10, 1.11, 1.12 etc) but no stable versions since 1.9.0 🤔 mvnrepository.com/artifact/org.jetbrains.compose.material3/material3
a
it was still in alpha in the android, but I saw a tweet from their dev rel that m3 should be targeting stable soon either this year or early next year developer.android.com/jetpack/androidx/releases/compose-material3#…
t
The android one is on alpha29, that's crazy
I also just noticed there's a
androidx.compose.material3:material3-common:1.0.0-alpha01
is this supposed to replace the jetbrains version in the future? 🤔
a
Tbh I've been fed up with how material3 has been treated, especially since our engineering team has decided they wanted to adopt m3 instead of our in house system. Nobody on our team understands that there's no opt out of the expressive controls unless you wrap components and the new style APIs which look promising are nowhere to be seen. It makes working with m3 very ugly and displeasureable. Constant alpha versions when UX team wants to adopt the new components makes the Android team squeamish, too.
m
The fact that material 3 doesn't use component based theming is baffling (on compose anyway, it does on flutter). I'd love a good way to say, change the shape of all my buttons in one place without having to redefine one of the shapes in MaterialTheme that could affect other controls. Sure, i could wrap all my buttons in other composables and point style them, but i'd much rather have my Theme function set things up, and use the out of the box Button composables
Point is there's a lot to gripe about with the m3 compose toolkit, but without it, we'd all be completely building things from scratch
a
I built one from scratch that we consume perfectly fine. The other engineers on my team love doing things by textbook knowledge and don't want to learn. It's not only possible to do but very easy imo
Instead of UX teams guiding design, now we are forcing their hand because of the limitations of m3. It's so backwards
m
We're kind of a hybrid in compose. We have our own design system complete with it's own set of tokens, typography, and other types of tokens (alphas, corner radius, etc...). And a bunch of controls that are built on top of those. However, most of it boils down to using m3 and applying point styling (like i mentioned above) to their composables.
We're starting to move towards component based theming that take their defaults from our design system theme.
a
I'd rather not mix and match, but that's my personal belief. Unless something requires a truly bespoke component, I'd rather have a system that provides it all correctly
m
compositionLocalWithComputedDefaultOf
is your friend in these cases
😉
a
Now we are forcing our designers to collapse their tokens and change things up on a whim
m
I agree that it's nice to have a completely self contained design system, but that comes at a cost. Particularly up front, it's a huge cost to define and build the core set of components. And everytime something new shows up in designs you need to build it from scratch. That's a lot to deal with, especially since material has already figured out all the hard stuff like accessibility and other things.
a
That's the great thing about compose being open source. You can just copy paste the harder stuff if need be, and adapt the rest. I'm hoping the styleable APIs will be a good escape hatch
m
Yeah, it's open source ,and you can do that, but my experience with doing that is that there's A LOT Of internal and private bits that prevent blanket copying and pasting so you can tweak something in the material kit to suit your needs when it can't be styled through parameters.
a
They're getting better about that
But if the point of making your own design system is to avoid material, then it would probably be more copying the groundwork (a11y semantics, gesture handling, etc) and putting your own layer on top.
m
I just wish that the way compose was built had more of that type of thing built into a core kit, and then had material built on top if for visuals. It would go a long way in helping people build distinct design systems.
a
They dogfood those APis, specifically with gesture handling, in Material before anyone else uses it publicly it seems. But to be honest, it's really not an issue anymore. You can do most of these things yourself because they have ported out most of their utils