When I add the

io.ktor:ktor-server-config-yaml-jvm

dependency to a project, and build the

jar

task, the default

io.ktor.server.config.HoconConfigLoader

is not being added to the list of ConfigLoaders in

META-INF/services/io.ktor.server.config.ConfigLoader

This has the knock on effect that the "application.conf" file in the root of the jar is not able to be loaded, as there is no ConfigLoader class available to handle that file type. See thread. I've reproduced this in the examples application.

Please help me decide on further development of KVision. Vote! 1️⃣ Maintain backward compatibility for as long as possible. Make breaking changes only when required by the development of core tools and libraries (e.g. KGP). Keep current modules up to date, even if they're probably not being used by anyone. 2️⃣ Modernize! Support ES modules, TailwindCSS, kotlinx-datetime, Kilua RPC integration, at the expense of having to make changes (sometimes significant) to my existing projects. Deprecate and drop modules which require a lot of work to maintain and are not used often or at all. 3️⃣ Let it burn! Focus on Kilua development (I'm already migrating my applications!) 😉 4️⃣ I have different opinion (please leave a comment)

KVision 8.1.1 is out https://github.com/rjaros/kvision/releases/tag/8.1.1

The API documentation made with Dokka 2.0 is so much better.

KVision 8.2.0 is out https://github.com/rjaros/kvision/releases/tag/8.2.0

Help me understand this KVision pattern(?) The application I'm maintaining has a Container.mainLoop() function which basically does:

fun Container.mainLoop() {
    main().bind(store) { state ->
        /* Render the view according to state */
    }
}

I suppose the basic idea here is that the view is re-rendered whenever there is a state change(?) The problem I'm having is that this happens asynchronously. The application goes through a number of state changes, but instead of re-rendering the page after each state change in realtime they queue up and after everything has settled, the page is re-rendered multiple times back-to-back, which is pointless. The application really just needs to reflect the "final" state change. Is this a bad pattern? Is there a better "best practice" approach to this? Thanks!

KVision 9.0.0 is out https://github.com/rjaros/kvision/releases/tag/9.0.0

The documentation update will take some time, so the migration guide is not ready yet.

KVision is now simplified. There are no fullstack modules, no Electron, no Cordova and no OnsenUI. The framework itself and all example apps are migrated to ES2015 target and ES modules.

There is new TailwindCSS module and ready to run example application.

Examples repository has also been simplified and all fullstack examples use Kilua RPC now.

Anyone had any success with using chart.js date adapters with KVision? I naively tried to add an (NPM) dependency to an adapter in the build, but no cigar 😞

KVision guide has been fully updated to version 9.0.0. And the new fullstack chapter just references Kilua RPC guide.

The old version of the guide is still available as https://kvision.gitbook.io/kvision-guide/kvision-8.x

KVision 9.0.1 is out https://github.com/rjaros/kvision/releases/tag/9.0.1

Does Kilua RPC support returning objects? They are not mentioned, but inline with the Kotlin Serialization guide,

Unit

is just a singleton object, and it is handled like any other Kotlin object. But Kilua rules out Unit as a return type, which has me wondering about objects in general

Yes, Kilua RPC supports returning any serializable class. But not

Unit

. Is

Unit

serializable? (I'm not sure 🙂)

LOL. When I created KVision fullstack interfaces years ago returning

Unit

was not possible. I've just accepted this rule, because it was not a big problem for me. Years passed and I've made changes here and there, replacing old, manual deserialization code with features from the kotlinx.serialization lib. But I've never ever tried returning

Unit

... until today 😉 And it works!

Thanks for your question @Phil Richardson 🙂

https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/builtin-classes.md#unit-and-singleton-objects

The Kotlin builtin Unit type is also serializable. Unit is a Kotlin singleton object, and is handled equally with other Kotlin objects.

I see your comment about testing returning Unit. Good to hear, as my question was initially aimed at using some other marker object in place of Unit, given the docs says Unit cannot be a return type. Unlike the Nothing non-type, everything I knew about Unit said it is just an object, thus wondering if that made objects barred.

Hi! More Chart.js hurdles... io.kvision.chart.DataSets has a member minBarLegth. I think that should be minBar_Length_? Either way it doesn't seem to work. Can I work around this and pass DataSets options in a non-typed way?

KVision 9.1.0 is out https://github.com/rjaros/kvision/releases/tag/9.1.0

New version of KVision Project Wizard has been uploaded to JB Marketplace. The plugin was finally updated to support KVision 9, Kilua RPC integration and new modules list (including TailwindCSS support).

KVision 9.1.1 is out https://github.com/rjaros/kvision/releases/tag/9.1.1

Hi Robert. Are you planning to keep updating kvision, or are you expecting users to convert to Kilua? Apologies if you've already addressed this in an earlier post.

Yes, I plan to keep updating KVision. Perhaps not as often as earlier but I will try to follow major dependencies updates.

Recently I had to work for living a bit more and I have some catching up to do 😉 But I just started to work on my OS projects. I'll update Kilua RPC, Kilua and KVision to Kotlin 2.3.0-Beta and Spring Boot 4 RC in the coming days.

Understood. Thanks for your efforts on both projects!

KVision 9.2.0 is out https://github.com/rjaros/kvision/releases/tag/9.2.0

KVision 9.2.1 is out https://github.com/rjaros/kvision/releases/tag/9.2.1