Apparently, this is now a monthly progress report,...

# decouple

[CLOVIS]

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