set the channel description: Decouple your design system from your multiplatform UI Experimental component library which lets users replace each component by any Compose-based implementation: write your UI once for Android, Compose for Web DOM, Jewel, Mosaic…

set the channel topic: Decide which components are worth adding the library, prove the tech works

set the channel topic: Decouple your design system from your multiplatform UI

set the channel description: Experimental component library which lets users replace each component by any Compose-based implementation: write your UI once for Android, Compose for Web DOM, Jewel, Mosaic…

Hi, everyone! I've been reading about Compose every since the first announcements, and I've been using Compose for Web (DOM) in production for the past 6 months or so. When I started using it, I was disappointed it was not possible to share UI code between Android and Web, but I understand it's not really possible as the ecosystems are too different from each other. My understanding is that JetBrains' goal for the next few years of Compose is to provide a multiplatform library based on Skia that has identical components for all platforms (as in, both in code, and visually pixel-perfect the same). I think there is an alternative approach to multiplatform UI, and Decouple is my exploration of it. Currently, it is very experimental, but at least proves that the idea actually works. What's left to do is to actually grow it into a proper component library that can be used in the real world. In a simplified manner, Decouple declares components in interfaces, allowing to abstract over multiple component implementations. Thanks to the power of composition and context receivers, this creates a new paradigm: writing the application UI in a common module, and having component implementations elsewhere. Essentially, this decouples (eh) the application UI from the components themselves, which are expected to live in another library. This provides many benefits: • Write a single UI and run it on multiple platforms that are completely different in implementation, as long as they run Compose: (Android, Compose for Web DOM, Compose for Desktop, Jewel for IDEA plugins, Mosaic for CLI applications…) • Start writing your application with one of the built-in themes and replace any component by anything else at any development stage without touching the application itself (e.g. your design team can work asynchronously without ever touching the application code) • Powerful headless UI tests, in which you only test your UI at a very high level (you can directly access each composable's arguments) Context receivers are not available for JS yet, so I've had to hack them with CompositionLocal that's not great, but the end goal is that each app provides a single interface that declares what components the project uses:

interface MyComponents : UIMetadata, Buttons, Chips…

you can expect-actual (or just implement) this interface via delegation to use existing implementations, or just create your own:

class MaterialComponents : MyComponents, Buttons by MaterialButtons, Chips by MaterialChips…

and then, you can typesafely declare components that work for any implementation you provided:

@Composable
context(MyComponents)
fun UserList(users: List<User>) {
    Column {
        for (user in users) …
    }
}

Because of the receiver, this allows to easily know if all components used are available for all implementations:

@Composable
context(CLI)
fun UserList(…) {
    // Here, you can call only components that are declared to be implemented for CLI applications
}

Currently, we have a few dozen components implemented, but they prove this structure works. I'm very interested in having other people's opinions on where this can go.

What distinguishes this project from redwood and Compose UI in the long term? If I were to choose a UI for a new project what would lead me to decouple?

I'm not familiar with redwood. My understanding is a big issue being tackled by decouple is web, which the present solutions are currently diverging into a DOM approach and a Canvas approach. A lot of the community is getting excited about Canvas as a solution for a write-once use-anywhere app, but using Canvas on web does have a few limitations (not the least which means on ultra widescreen monitors you're probably allocating a giant texture which may be a waste of memory). Decouple is trying to do something clever where it would target the DOM.

Oh CLOVIS just answered the question in the thread and it's a much better answer 🙂

Could this idea be extended also outside Compose world?

Where would the best place be to put an iOS demo in the project structure? I could create demo/ios, but I’ve found XCode projects that consume a cocoapod to be more reliable than the gradle ways of building an iOS app. This leads to two folders: a gradle project for the pod and an XCode project for the app. Would this mess up the current build infrastructure in any way?

If anyone wants to contribute on easy tasks to get to learn the project better, I recommend looking at the list of open AndroidX issues, if you've used Compose on Android before they should be relatively easy to go through (these are mostly adding missing features to the existing Android implementation, which is currently a proof-of-concept). I'm very thankful to the first contributions I've received 🙂

Decouple 0.6.0 is out, with a new Headless UI module to test your UI logic on any platform without running the app, and a lot of documentation to help contributors understand the project, including a comparative of the various Compose-based projects currently ongoing (also linked at the top of the channel).

0.6.0 highlight: headless UI testing It's now possible to use any Decouple component in a headless mode where an instrumented design system allowing the pause the application and events. This mode is entirely multiplatform, in that you can test your application even on platforms your application doesn't support (e.g. test your JS application on the JVM to use the better tooling). You can learn more about it in the documentation. Here's how you can use it to test the state of a simple counter:

Decouple is implemented using multiple design patterns that appear in a lot of components, but are not based on a class or another symbol that I could add documentation to. For example, components that can start an action have a suspending event and an optional coroutine scope that will by default cancel the action if the button goes offscreen (it is also possible to specify it explicitly). For example, a button looks like this:

@Composable
fun Button(
    …
    onClick: suspend () -> Unit,
    scope: CoroutineScope = rememberCoroutineScope(),
    …
)

This pattern is very convenient because it allows to use coroutines in all events, and it allows the button to automatically display a loading indicator if the event is taking too long. However, there is no good place to document it… I cannot copy-paste the documentation on each component that uses this pattern. I'm considering creating a

concepts

or

patterns

package in

core

that would only contain 'fake symbols' that can be documented. They would never be used in an actual application, but it would be easy to refer to them in documentation. For example, a dummy type alias:

/**
 * Explain the pattern here.
 */
typealias PatternName = Nothing // useless, takes no space in the final application

Do you think this approach is a good idea? 1️⃣ yes, using a

typealias = Nothing

(but typealiases do not get their own pages in Dokka, so it would be hard to link to them) 2️⃣ yes, using an empty

object

(but it will exist in the final binary) 3️⃣ no, use some kind of external documentation website (cannot see the explanation in the IntelliJ documentation popup, hard for users to know if the website matches the version of the library that they're using) 🔢 neutral

Just got the demo app running on iOS. Compose for iOS is not fully stable yet, so it's not perfect.

I published an article (in 🇫🇷) about the high-level goals of Decouple and the reasons I believe they are attainable today: https://blog.4sh.fr/2023/03/07/une-meilleure-experience-utilisateur-grace-au-projet-decouple/ —and we now have a logo

Other than that, I'm currently rewriting the Gradle structure to use convention plugins/precompiled script plugins, and @David Herman and I have been discussing creating a Gradle plugin to use ViteJS instead of Webpack for Kotlin/JS projects—hopefully, we can get a proof-of-concept in a few months.