Data binding isn't explained very well in the offi...

# kvision

[napperley]

Data binding isn't explained very well in the official documentation. Some strange issues have been encountered when doing data binding that involves using some basic conditional checks. As a result the state changes in unpredictable ways. Here is the project where the issues are being encountered: https://gitlab.com/napperley/todo-list

[Robert Jaros]

Please check: https://gitlab.com/rjaros/todo-list/-/commit/8f165728e3eebd352f7a3ee66c31d52914af8975
(no idea how to create PR on GitLab 😉)

[Robert Jaros]

The main problem with your code was mixing the model with the UI (keeping selection - part of the state - inside the TodoListItem component).

[Robert Jaros]

I've moved selected to TodoItem data class and modified the rest of the app to use it (e.g. button actions now work only on the main data model)

[napperley]

Is the data binding directly tied to the model?

[napperley]

Including best practices (including on architecture with MVC) in the guide would be very helpful.

[Robert Jaros]

Your problem is not about data binding itself but about component lifecycle. When using data binding the KVision components are just destroyed and re-created. The state you keep inside the components is lost. So the state should be kept externally to the components (a typical "SSOT" architecture is recommended).

[napperley]

Are there any good articles/videos that cover the SSOT architecture?

[Robert Jaros]

You can find some nice stuff when you combine SSOT with redux:
https://medium.com/@juanguardado/redux-single-source-of-truth-e1fe1fb6ffec

https://www.youtube.com/watch?v=JIFq1dErB_8▾

[Robert Jaros]

KVision is not 100% pure in this matter because it's statefull by design. But I like to distinguish the state of the application and the state of UI. The state of the application is global, it can be persisted (e.g. between hot reloads) or initialized with external sources (e.g. routing parameters). It determines how the application UI is build (how the page looks), what options are available etc.

[Robert Jaros]

At the same time in a typical application there are lot's of small statefull parts which are not important to the application itself. It could be input field validation message or a selectbox option choosed by the user. You could of course put this in your application state as well, but in my opinion it would be unnecessary pollution. So you can just let KVision keep this small parts in the UI components.