The concept of MVI (and especially the TODO exampl...

# mvikotlin

[benkuly]

The concept of MVI (and especially the TODO example App) seems to be a bit complicated and the difference to decompose is also not clear to me, so I am not sure if it fits to my needs:
I have a key value database, which could be very large and not all data in it is needed all the time, so mirroring the database to Stores is not an option. I would need something like functions in a store to receive only specific data, which are loaded from database, but are also observable, when something changes (e. g. due to a server response). Is this doable with MVI or is it the wrong framework for something like that? Thanks 🙂

[Arkadii Ivanov]

The difference between MVIKotlin and Decompose is in their purposes. MVIKotlin provides Stores - a source of State. Decompose provides Lifecycle-aware componentization. When both libraries are used together, Stores are usually scoped by components.

How many rows do you expect to have in your database? I have implemented a chat with MVI. A Store contains all the messages in memory, they are loaded from the database page by page on scrolling. Changes are swapped to the database by the Store. We had >1000 messages loaded in the Store , the performance was fine.

[benkuly]

Thank you, I think I understand the difference now 🙂

So the store contains an Intent like LoadMore and this adds more messages to the store? I think something like that could work for me.
Because I develop a library: Can the MVI-Stuff compiled to JS and used from JS (via @JsExport)? My current own implementation of a simple store can't do that, because it uses Flow, which cannot be exported 😕

[Arkadii Ivanov]

So the store contains an Intent like LoadMore and this adds more messages to the store?

This is exactly how I implemented it in that chat project.

Can the MVI-Stuff compiled to JS and used from JS

You should be able to hide the logic behind a facade (e.g. in the MVIKotlin samples I used a thing like "controller"). Then just export your facade. It can be a class, or an interface plus a factory function.

[Arkadii Ivanov]

Not sure about exporting though, never tried that.

[Arkadii Ivanov]

Do you need this library to be consumed from a non-Kotlin JS project?

[benkuly]

Okay cool!
The js ecosystem for kotlin is small at the moment and dukat has many bugs, so I think a library, that could be used for non-kotlin js projects would be nice.
I will give MVIKotlin a chance, thank you very much :)

[Arkadii Ivanov]

I would say that the primary goal of multiplatform JS is actually to consume the code from another Kotlin projects. There might be various issues or unexpected behaviours when exporting to JS. E.g. there are definitely some issues when publishing such a library to NPM. So I recommend to try this first, before diving into implementation details.