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.

Pedestal, my collection of micro-utilities for Multiplatform apps, has reached 1.1.0. Most notably, this introduces iOS support for Pedestal State, the library that powers the loading times in Decouple, thus removing the last obstacle to iOS support in Decouple. Thanks to @Landry Norris for helping figuring it out. I have started work on Pedestal 2.0, which will split many modules into smaller and more independent libraries. In particular, the progression management will be split into its own library, allowing Decouple to drop the mandatory dependency on State (which pulls in #arrow and KotlinX.Coroutines). Integration with Arrow will be moved to its own optional module. I expect this to be done in the next ~2 months or so, hopefully in time for the release of Arrow 1.2 😉

Pedestal 2.0.0-rc.1 is out, which uses Arrow 1.2.0-rc.1 to dramatically improve the usage and introduce typed errors. In relation to Decouple, the progress management has been extracted into its own micro-library, meaning everything else (including the Arrow dependency) has become optional. I will likely make in post in #feed in the coming days to give more details on everything that's new.

Decouple 0.7.0 is out, with added Desktop support (contributed by @Landry Norris), the new logo, a completely rewritten Gradle configuration to profit from the Gradle build cache (and hopefully the configuration cache and configuration-on-demand whenever the Android plugin supports it), a few renames for headless testing and chips and the Android source set v2 migration. I'm hoping this work on Gradle will let me focus more on the components. I'm currently reworking the navigation bar for the web implementation.

Decouple 0.7.1, with a nicer navigation bar for the web (as always, the link to the demo is pinned at the top of this channel). It's not mobile-friendly at the moment, but it still looks much better than previously.

Decouple 0.7.3 with better documentation (including a list of components in the module-level documentation), a tutorial to discover Compose and Decouple, and a project structure reorganization. All modules are now published to the GitLab Maven Repository. I'm looking into publishing for Maven Central soon. I have a LazyColumn/LazyRow prototype for Compose HTML that I will be working on stabilizing first, so it can be used by other projects. Thanks @Chrhuang for contributing a calculator example.

OpenSavvy has been accepted for publishing to MavenCentral 🙂

I haven't posted updates in a while, so here's one. The first goal of the past month was to improve documentation. For end users: • We added a "from scratch" tutorial which leads a user through creating their first composable function (a counter) to discover how state management works with Compose. • We did a user study on the tutorial to ensure someone with basic Kotlin knowledge (no Compose or Decouple knowledge) can finish it without major issues. This led us to change a few things. For now, we're happy with the results, except for a few technical setup issues. • We added the list of available components in the package-level documentation for

core

. • We started working on a playground which will provide a simple environment to play around with the library, as well as compare it with others. For now, we're planning on making a demonstrator for Compose Multiplatform, as well as Kobweb. In the long term, this will give us a common ground of discussion to improve interoperability. For contributors: • We simplified the project structure and the package structure to make navigation easier. • We wrote a tutorial on how to fork the project. We're currently writing a tutorial on how to create merge requests, and one on how to configure GitLab CI runners on your own hardware. They're available in our wiki. The second goal was to start preparing for the eventual stabilization of the library. • Our other project, Pedestal, has been published to Maven Central 🎉. • We have finished designing the way we separate components in interfaces and components, to ensure we can make binary- and source-compatible changes in the future. Once we're done implementing them, we will declare Decouple in 'alpha' stage, as it will become relatively safe to add it to a project. Then, all that will be left to do is have enough components out-of-the-box for Decouple to be interesting to use… • …which brings us to our last update: we are starting an analysis of real world apps to survey which components are commonly used and in which context, to ensure we provide them out-of-the-box. Lastly, we have a prototype of a lazy list for Compose HTML. After discussion in the #kobweb Discord server, we decided to extract it its own external library so it can be used without Decouple. As soon as we finish setting up Maven Central publication, we will move to stabilize this implementation and advertise it to more users.

Apparently, this is now a monthly progress report, so here I go. This month was a bit lighter than the previous few, mostly because multiple regular contributors have been in vacation or busy with other things. • We found a solution to the main issue of the current software design: adding attributes to components is a breaking change. This is also a problem for Jetpack Compose. Compose for Web (HTML) found a solution with the

attrs

block, but we found it too verbose for our needs. Instead, we found a solution which is invisible for users of the library (attributes are still regular Kotlin parameters). Currently, only buttons have been migrated to this new syntax. • Our final design is still blocked by a bug in the Compose compiler. If you have any knowledge that could help fixing/working around it, feel free to help us 🙂 A lot of the build process from Decouple is shared with multiple other OpenSavvy projects. As you've seen in the previous progress reports, managing the build process has grown to be a significant percent of our time. Having to maintain multiple build processes which follow the same idea but are technically different didn't help. For this, we have created the OpenSavvy Playground, a collection of project templates. • The Baseline is a project which just contains IDEA and CI configuration, usable for any kind of technical stack. • The Gradle playground is a project template with all the new features pre-configured: the build cache, the configuration cache, configuration-on-demand to avoid configuring all projects uselessly, convention plugins instead of

allprojects

for faster maintenance, documentation generation with Dokka, publishing to MavenCentral for multiplatform projects, etc. • All playgrounds come with Gitpod and dev containers information, so anyone can open the project on the cloud in a single click without having to install anything. Unlike regular project templates, the Playgrounds will be continuously updated as our build process changes. We will be migrating our existing projects to this structure one-by-one to ensure we only have a single setup to maintain. Pedestal is almost fully migrated, Decouple is next. Coming back to Decouple, now that are passed the phase of "will it even work", we enter the phase of "we need to understand what the actual needs of our users is and what the list of components will be". We initially started a survey of multiple large projects to get an idea of how we could adapt them, but the results were not satisfying. Instead, we have decided to take a detour to properly learn the best practices of the Android world, since this is the ecosystem our users are the most likely to be familiar with. We will be implementing a todo-list application, first in pure Android, following the best practices from Google, then with #kobweb, then finally with Decouple. Our goal is to get first-hand experience on using Decouple for a complete project, and see how it compares with other technologies. Hopefully this experience will give us knowledge about our strengths and weaknesses that we will be able to bring Decouple into an alpha stability level. We will be making a more complete announcement with the exact extent of what we're trying to do, but until then you can read more about the project here. As always, if you have some free time and would be interested in contributing to our projects, don't hesitate to get in touch 👍 Any contribution is appreciated, no matter its size

Two months ago, we announced we were working on lazy lists for Compose HTML. Our experimental library has now been split into its own repository to be developed independently, and it just reached Maven Central! Lazy layouts for Compose HTML 0.1.0 • Central • Repository It supports components similar to

LazyRow

and

LazyColumn

, but with a few HTML-specific changes: they accept the same

attrs

block all other Compose HTML components do. This first version was focused on deciding the API shape. The algorithm can (and will) be improved, for example for unloading components dynamically, but we aim to make these changes without impacting other projects using the library.

Great news, the Compose Compiler bug that was blocking us has been fixed! This was the last technical hurdle, all that's left is to actually make the library interesting to use. Meanwhile, our lazy layout implementation has gotten much better documentation, as well as the ability of loading elements one-by-one, as well as recomposing when the initial list changes. Thanks to @Ryunos and @Jacob Ferrero for their help. The next step is figuring out how to unload elements dynamically. The next technical challenge is to figure out how to get transitive resources in the JS ecosystem. #kobweb does this by asking users to place resources in the

public

directory, and crawling through dependencies to find them. We'd like to find a way to provide this to all Kotlin/JS projects, but there's nothing concrete for now. At this point, we're starting to have quite a few ongoing projects! This month was mostly spent on extracting all the Gradle configuration we use to our convention repository, to ensure all projects use the same versions, etc, and are easier to upgrade. Once that's done, we will start reorganizing the Decouple repository on top of it. Unrelated to JavaScript, our test framework, Prepared, is starting to take shape nicely! It features coroutine-aware test fixtures, virtual time control, randomness control, filesystem access, compatibility with kotlin-test and Kotest, and helpers to test Gradle plugins. We're also working with the maintainer of #parameterize to try to get both libraries to work well together 🙂 Meanwhile, we're experimenting with the #kobweb team to try to decrease build times for Kotlin/JS… if it does turn out as we hope, the announcement will be very interesting 🕵️ For personal reasons, the coming month will likely be slow, so expect little for the next update :)

As I mentioned in the last update, the Kotlin team has fixed a major bug blocking Decouple recently. The technical aspects are therefore sorted out, it's time for a big cleanup. I'm searching for people who are interested in design systems and UI kits in general. The objective is to put in place a list of the most common components, and organize them by the reason they are used. In different UI kits, components are often named after what they look like, so it isn't obvious when two components are direct equivalents in terms of user experience. If you're interested in this subject, or know someone who is, please reach out. The most complicated part of Decouple is, and will remain, the polymorphic component concept. To decrease friction in the future, this concept has been moved to its own module (

decouple-core

) with proper documentation explaining its objectives and usage. On the Kotlin/JS side specifically, we have hit the classic issue that resources/assets are not published as part of libraries, and are thus not available to downstream projects. We want to expose default CSS files to users, so we need this feature. We are experimenting with a Gradle-based approach to solve this—but it's not as simple as it seems. Last but not least, this Slack channel is dedicated to Decouple itself, yet we often end up talking about our other projects, and it doesn't feel like the correct place to exchange about them. We're opening a Discord server to discuss all our projects, even when they are not related to Kotlin or UI development. Please join us 🙂

Decouple is finally moving again! It's going to take some time to reach back to the components that already existed before the start of the cleanup, but the codebase is already much, much cleaner and easier to understand. If you want to play with our polymorphic component syntax, you will be able to in a few hours (when Central syncs). In this version, we provide no components out-of-the-box, but hopefully the syntax shouldn't change in the future so you can already start creating your own. https://gitlab.com/opensavvy/decouple/-/releases/0.8.0

Since this should, hopefully, sync to MavenCentral, the next step is to document how to actually pull the project (though it's the same as every other KMP library): https://gitlab.com/opensavvy/decouple/-/issues/206

We now have a new README which better explains how Decouple fits with the overall Compose ecosystem (including a comparison with Redwood) and presents the current state as well as our near-future goals: https://gitlab.com/opensavvy/decouple/-/blob/main/README.md?ref_type=heads#decouple

There's quite a lot of new stuff!

Action responsibility First, we finally have some proper documentation on the concept of "action responsibility": all asynchronous operations under Decouple are tied to a single composable function which is responsible for both cancellation and user feedback. This ensures that we can't forget useless work started in the background, and we know that users will be notified when something takes some time. It removes the need for the application developer to always remember to implement progress indicators: they come out of the box. Learn more here

New components Second, we have the API specification for the different button types as well as the simple `Text` composable. We also have a prototype implementation using Compose Multiplatform's Material3 design theme, and another prototype implementation using Pure.css. As a reminder: our goal is to provide design system implementations for all Kotlin platforms, including KJS and Native. One of the particularities of Decouple is that we can add new arguments to composable functions in a backwards-compatible way… Although the library provides very few components (but well, it's a start!), it's already relatively safe to use them in projects.

The demo We started to configure the demo app, which is a single app written in 100% common code*, which runs with different design systems on different platforms. The next month or so will be about stabilizing the build process such that we can host that app somewhere. (*. I'm not counting the different ways

main

is written for each platform since that's just boilerplate)

Headless tests Finally, this release is also the return of the Headless module, which allows you to write tests for your composable logic without emitting any UI. These tests help ensure the behavior of the UI and the displayed data is always the same, even on different platforms which have different ways to lay out the data itself. The module is easy to integrate into any test framework. Learn more here

As always, you can also read the full release notes.

The next challenging step will be to create a catalog of commonly used components and group them by their features. If you are interested in helping with this, please get in touch! (either here or in our Discord)

Decouple 0.10.0 is out! This release brings back the support for

Row

and

Column

, as well as a bunch of dependency upgrades. We're looking for people who would be interested in contributing a bit of CSS once in a while to help speed things up. Don't hesitate to DM me or reply in this thread 🙂 Full release notes.

Hey! This channel hasn't been much active lately, but there are plans 👀 If you're at KotlinConf, come say hi :)

We now have a Slack channel for all our other Kotlin-based projects: #opensavvy Sorry for not updating this channel often, there are some news coming 🙂

Material3 for Compose HTML 0.4.0 is out! In this release, we drop support for TailwindCSS, stabilize

LinearProgressIndicator

, and introduce an experimental

Divider

,

InsetDivider

and

Checkbox

components. If you'd be interested in helping us, we gladly welcome contributions, especially to write CSS 🙂 Release notes

Material3 for Compose HTML 0.5.0 is out! This release adds K2 support, as well as few components (design unfinished): • Badge • Snackbar • TextField As well as design improvements for: • ElevatedButton • FilledButton • FilledTonalButton Release notes • Learn more

We have Material You theming on Kotlin/JS! The demo is available here. The color generation algorithm is independent and is already published for almost all platforms here, though it is lacking in documentation and breaking changes may still happen.

Material3 for Compose HTML 0.6.0 is out! First, this release is the first with dynamic color, meaning your users can customize how the theme looks based on their favorite colors. We also have a few new components: •

FilterChip

•

InputChip

•

AssistChip

•

SuggestionChip

Release notes • Demo • Learn more

Material3 0.6.1 is out! New components: •

OutlinedButton

•

TextButton

We now have all default buttons. Changelog • Demo • Learn more