1. Bootstrap 5 Not all currenty used components have versions compatible with Bootstrap 5. I'm considering supporting both Bootstrap 4 and Bootstrap 5 with two sets of kvision-bootstrap-* modules. This will make upgrading existing apps easier and get the benefits of BS 5 (like optional jQuery) for new applications.

2. Move jQuery to optional module Bootstrap 5 doesn't require jQuery, so I plan to move all jQuery code to a module.

3.

RestClient

and fullstack interfaces move to fetch API With jQuery gone, all

ajax()

calls will need to be replaced with

fetch

. This forces also some changes to the public

RestClient

API.

4. Replace

awesome-bootstrap-checkbox

with

pretty-checkbox

library (as a module) The old library doesn't support Bootstrap 5. But I'm also considering just dropping this feature at all and just keep Bootstrap 5 styles (including "switch" component).

5. Unify data bindings I plan to remove all DSL builder functions with

state

parameter (there are really lots of them - and it's a lot of mostly unused code). The

bind()

extension functions will be used instead. The same goes to

FormPanel

- remove

add()

and migrate to

bind()

. I'd like also make some cleanups with state modules. Move all state functions and state components (observables) to a module (

kvision-state

) and rename

kvision-event-flow

module to

kvision-state-flow

or

kvision-state-coroutines

.

6. Explicit CSS modules initialization Currently CSS modules are automatically initialized, which doesn't allow to use "-Xir-property-lazy-initialization" option with IR (issue #231). I plan to make it explicit (with a single line of code in

start

method).

7. No wrapper elements for Flex/Grid/V/H Panels by default Currently wrapper elements are automatically generated, which can be disabled with

noWrappers

parameter. I plan to invert the default. It will probably break some existing layouts and will require manual migration.

8. I'am considering

kotlinx-datetime

dependency instead of KVision custom datetime types for fullstack interfaces. I'm not sure how stable the library is at the moment.

Please comment or just add 👍 or 👎 to let me know what do you think.

Also I'd consider standardising dsl builders. Now they're all over the place, so it'd be good to make them all adhere to the same argument schema.

I think KVision should provide a clear migration path between major releases.

I am thiking about RestClient. Does KVision actually need own implementation of RestClient? What about using existing

ktor-client

?

Even after optimizations made recently, it still adds to the final bundle more then the whole KVision core.

It also depends on coroutines, which also adds a lot.

Our RestClient does not depend on coroutines. And I've already switched to Fetch API, so no jQuery either.

I have looked at you RestClient changes and I have couple of ideas... • add filters (Output/Input or Request/Response) and replace beforeSend/requestModifier/transform parameters by them • filter can be added to whole RestClient instance or single method call

interface Filter {}

interface RequestFilter: Filter {
   fun filter(request: Request):Request
}

interface ResponseFilter: Filter {
   fun filter(response:Response): Response
}

something like ^^ It might also handle serialization/deserialization

It would be nice to be able to set baseUrl or url prefix, because it's usually same for all requests

client = RestClient(..., baseUrl="<https://api.example.com>")
client.remoteRequest("/users")

instead of concatening url in every request:

client.remoteRequest(BASE_URL + "/users")