Landry Norris
02/23/2023, 4:41 PMCLOVIS
02/23/2023, 8:25 PMCLOVIS
02/25/2023, 4:04 PMCLOVIS
02/25/2023, 4:09 PMCLOVIS
03/01/2023, 5:19 PM@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)
🔢 neutralLandry Norris
03/02/2023, 12:11 AMCLOVIS
03/09/2023, 9:09 AMCLOVIS
03/09/2023, 9:12 AMCLOVIS
03/27/2023, 6:51 PMCLOVIS
04/19/2023, 8:27 PMCLOVIS
04/19/2023, 8:41 PMCLOVIS
04/30/2023, 11:09 AMCLOVIS
06/18/2023, 9:34 PMCLOVIS
06/23/2023, 7:29 AMCLOVIS
07/30/2023, 1:42 PMcore
.
• 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.CLOVIS
09/06/2023, 1:42 PMattrs
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 sizeCLOVIS
10/09/2023, 7:49 PMLazyRow
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.CLOVIS
11/11/2023, 5:17 PMpublic
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 :)CLOVIS
12/15/2023, 8:35 PMdecouple-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 🙂CLOVIS
12/17/2023, 10:17 AMCLOVIS
12/17/2023, 10:18 AMCLOVIS
12/20/2023, 1:21 PMCLOVIS
01/03/2024, 8:06 PMCLOVIS
01/03/2024, 8:10 PMCLOVIS
01/03/2024, 8:16 PMCLOVIS
01/03/2024, 8:19 PMmain
is written for each platform since that's just boilerplate)CLOVIS
01/03/2024, 8:33 PMCLOVIS
01/03/2024, 8:35 PMCLOVIS
01/03/2024, 8:37 PMCLOVIS
03/02/2024, 3:57 PMRow
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.