From the stacktrace I see the error is coming from...

# ballast

[Robert Jaros]

From the stacktrace I see the error is coming from build() used in this class: https://github.com/rjaros/kvision/blob/master/kvision-modules/kvision-routing-ballast/src/jsMain/kotlin/io/kvision/routing/KVRouterViewModel.kt#L53

[Robert Jaros]

Sorry, I should use thread ...

[Robert Jaros]

I don't see any info about initial state of the router view mode in the docs, but maybe something changed?

[Robert Jaros]

I've tried to debug a bit. And I can see the initial state is correctly set to some value by the withRouter call, but after that a BrowserHashNavigationInterceptor is added, and the initial state is reset to null.

[Robert Jaros]

The interceptor seems to be new and I think it doesn't work correctly.

[Casey Brooks]

Hmm, let me take a look this today

[Casey Brooks]

Ok, so I found the root issue. I made a change in 4.0.0 where .withViewModel now returns a new builder instance of TypedBuilder which helps ensure the type-safety of applying subsequent interceptors. When the config builder functions are called in a chain (which is how I always apply them), everything works out fine, since the operators applied after .withViewModel operate on the new instance and the operators on Builder and TypedBuilder are identical.

But for your snippet, the .apply { } block returns the original, untyped Builder assuming that withBrowserHashRouter and withBrowserHistoryRouter mutated that object, when in reality those functions return a new object. While I did note the different return type of that function in the v4 migration guide, I completely overlooked the behavioral change that this implied with respect to the mutability of that builder object.

Using .let instead of .apply fixes the issue:

BallastViewModelConfiguration.Builder().let {
    if (useHash) {
        it.withBrowserHashRouter(
            routingTable,
            initialRoute
        )
    } else {
        it.withBrowserHistoryRouter(
            routingTable,
            basePath,
            initialRoute
        )
    }
}.build()

[Casey Brooks]

So this further confirms to me that the current configuration system needs to be deprecated and a new one introduced that fixes the confusion caused by the mutability of these objects, as noted in Issue #62.