Mark Murphy
01/31/2021, 7:43 PMcontent
composable lambda. I am more worried about cases where the library itself should be calling composable functions for certain roles, but it has no a priori way of knowing what those functions are.
For example, if a library wants to render a button, it needs some composable for that. But Button()
is a Compose Material thing, and the argument made here on several occasions is that Compose Material is just one possible design system. Somehow, the library needs a way to know "this is how I build a button", in such a way that it uses the app's chosen design system. Do we have a pattern for doing this? For apps themselves, they can simply use the right composable functions, but published libraries do not have that option, as they will be used by many apps.
My fear is that, in the absence of such a pattern, libraries will tend towards "you can have any design system you want, so long as it is Compose Material".Adam Powell
01/31/2021, 8:05 PMinternal
properties on those types that establish private communication channelsMark Murphy
01/31/2021, 8:25 PMTake a look at the variety of designs and details...Agreed. For a component like a date picker, the library itself will basically be the design system for itself, exposing whatever options its authors wish. Teams wishing to use a date picker will choose among existing implementations for which one best fits the rest of their app's design, or they will elect to create their own if needed. However, not all libraries will be exposing something like a date picker. Composables are used for every unit of UI. Should an about screen composable be defining its own design system? Perhaps there aren't enough of these to worry about. I can't help but have this nagging feeling that we're going to run into problems. If the answer is that the app-specific design system is only useful for custom-crafted composables, it feels like we're going to have a lot of conflict between those design systems and libraries. Anyway, thanks!
Adam Powell
01/31/2021, 8:26 PMMark Murphy
01/31/2021, 8:36 PMMaterialTheme
", then Compose Material becomes part of the API surface.
If the answer is "create your own library-specific thing that kinda resembles MaterialTheme
in role but does not impose a Compose Material dependency", that's great, but we're probably going to need examples and evangelism.
My guess is that the answer is "accept them all as parameters". Hopefully, that will hold up.Adam Powell
01/31/2021, 8:39 PMMark Murphy
01/31/2021, 8:46 PMa treadmill of moving goalpostsThe world needs a GIF of this. 😀 It would be wonderful if the Compose team could publish guidance for how you are envisioning composable libraries will look. There is quite a bit of expectation that the ecosystem will be filling in all sorts of gaps in the widget set, and the first generation of those libraries are going to be important for establishing community conventions. Again, thanks for your ideas!
Adam Powell
01/31/2021, 8:47 PMDominaezzz
01/31/2021, 10:38 PMAdam Powell
01/31/2021, 10:53 PMBryan Herbst
02/01/2021, 2:21 PMKirill Grouchnikov
02/01/2021, 5:23 PMBryan Herbst
02/01/2021, 5:45 PMAdam Powell
02/01/2021, 7:13 PMKirill Grouchnikov
02/01/2021, 8:26 PMAdam Powell
02/01/2021, 11:22 PMTash
02/02/2021, 6:37 AMA strong design spec, with “top-level” components and subcomponent variations, semantic colours (i.e.On top of that, the various layers are built: “primitive” components, “compound” components, etc. These basic ideas are of course Compose agnostic, but it seems as though Compose is infact fundamentally poised to realize these concepts way better than Views., notbackground
) and interaction guidelineswhite