I'm starting first experiments with KVision 5 features. We can discuss some breaking ideas.

# kvision

[Robert Jaros]

I'm starting first experiments with KVision 5 features. We can discuss some breaking ideas.

[Robert Jaros]

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.

[Robert Jaros]

2. Move jQuery to optional module

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

[Robert Jaros]

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.

[Robert Jaros]

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).

[Robert Jaros]

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.

[Robert Jaros]

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).

[Robert Jaros]

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.

[Robert Jaros]

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.

[Robert Jaros]

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

[Big Chungus]

👍 to everything except supporting both, bs4 and bs5. Seems to be a bit of wasted effort

[Big Chungus]

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.

[Robert Jaros]

I would happily drop bs4, but one of my own apps I have to support, depends on datetime picker, which could turn out bs4 only. So I'm just thinking aloud 🙂

[Robert Jaros]

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

[Big Chungus]

Ideally kvision would have enough abstraction to make bs just an implementation detail. Not sure how much work that would be though.

[Robert Jaros]

Unfortunately BS is not just about css styling. It's also JS with heavy dependencies (like jquery). And components with rich API (like datetime or typeahead) are tightly coupled with these dependencies. But I'll try to move those problematic components to optional modules and leave core module cleaner.

[Tomas Kormanak]

I would consider changing RestClient API, for example it would be useful to allow automatically add some headers to all requests(e.g Authorization)

[Tomas Kormanak]

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

[Robert Jaros]

Ktor client is still extremely large. Check https://youtrack.jetbrains.com/issue/KTOR-1084

[Robert Jaros]

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

[Robert Jaros]

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

[Robert Jaros]

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

[Tomas Kormanak]

ok, makes sense

[Tomas Kormanak]

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

[Tomas Kormanak]

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")