https://kotlinlang.org logo
r

Robert Jaros

06/12/2021, 2:01 AM
I'm starting first experiments with KVision 5 features. We can discuss some breaking ideas.
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.
👍🏼 1
👍 5
2. Move jQuery to optional module Bootstrap 5 doesn't require jQuery, so I plan to move all jQuery code to a module.
👍🏼 1
👍 2
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.
👍 1
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).
👍 1
👍🏼 1
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
.
👍🏼 1
👍 4
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).
👍🏼 1
👍 2
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.
👍🏼 1
👍 1
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.
👍 6
👍🏼 1
Please comment or just add 👍 or 👎 to let me know what do you think.
b

Big Chungus

06/12/2021, 7:27 AM
👍 to everything except supporting both, bs4 and bs5. Seems to be a bit of wasted effort
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.
r

Robert Jaros

06/12/2021, 9:17 AM
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 🙂
I think KVision should provide a clear migration path between major releases.
b

Big Chungus

06/12/2021, 10:33 AM
Ideally kvision would have enough abstraction to make bs just an implementation detail. Not sure how much work that would be though.
r

Robert Jaros

06/12/2021, 11:08 AM
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.
t

Tomas Kormanak

06/15/2021, 8:26 AM
I would consider changing RestClient API, for example it would be useful to allow automatically add some headers to all requests(e.g Authorization)
1
I am thiking about RestClient. Does KVision actually need own implementation of RestClient? What about using existing
ktor-client
?
r

Robert Jaros

06/25/2021, 5:10 PM
Ktor client is still extremely large. Check https://youtrack.jetbrains.com/issue/KTOR-1084
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.
t

Tomas Kormanak

06/25/2021, 5:17 PM
ok, makes sense
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
Copy code
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
Copy code
client = RestClient(..., baseUrl="<https://api.example.com>")
client.remoteRequest("/users")
instead of concatening url in every request:
Copy code
client.remoteRequest(BASE_URL + "/users")
4 Views