Help me understand this KVision pattern(?) The ap...

# kvision

[Christer Palm]

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!

[Robert Jaros]

Hello

[Robert Jaros]

State binding is asynchronous by design. But there is also bindSync extension function, which does this synchronously. You can try if that's better fit for your case.

[Robert Jaros]

If you want to reflect only the "final" state, you can probably do this by using different type of store. KVision supports many different store types, including StateFlow. It should work like this.

[Christer Palm]

Nice, I think the latter is what I'm primarily looking for 👍
OK, I think that also pointed me in the right direction what to look for in the documentation 🙂
Thanks!

[Christer Palm]

Looking at the Working with State chapter

[Christer Palm]

BTW, Is state binding a reasonable way to manage rendering when the rendering approach is to fully re-render the page?

[Robert Jaros]

In general yes. I have some large apps, which are designed that way - a single store with a single binding for the whole content - and they are working fine.

[Robert Jaros]

But if you have very complex app, with a large state (especially when it changes often) you can use a bit different pattern and bind parts of the state to parts of the app content.

[Robert Jaros]

This way only part of the content which depends on the modified value is re-rendered.

[Christer Palm]

Currently the app is using ReduxStore - I suppose that's a "high level" store that can't simply be replaced with a Flow?

Any way to control the ReduxStore behaviour in this regard?

I don't think selective binding, etc. is of any help here. It's not that there are state changes that aren't reflected by the view, it's rather just an efficiency problem with the full re-render approach where multiple pending state changes really only needs to trigger one re-render.

Is there a way to check if there are pending events, so I can "manually" skip forward to the last pending event?

[Robert Jaros]

It's not so difficult to replace redux with stateflow + sharedflow. You can check the fomantic example: https://github.com/rjaros/kvision-examples/blob/master/fomantic/src/jsMain/kotlin/com/example/App.kt

[Robert Jaros]

It still uses a reducer function and action dispatch