set the channel description: https://github.com/respawn-app/FlowMVI Discussion, Q&A, feature requests and anything related to FlowMVI - a KMP MVI implementation based on plugins. Docs: https://opensource.respawn.pro/FlowMVI/

set the channel description: Discussion, Q&A, feature requests and anything related to FlowMVI - a KMP MVI library with a rich DSL and a powerful plugin system.

I've run into an error using flowmvi on wasmJs, here is the output.

CompileError: WebAssembly.instantiateStreaming(): Compiling function #67408:"pro.respawn.flowmvi.plugins.$onExceptionCOROUTI..." failed: struct.set[1] expected type (ref null 14487), found struct.get of type (ref null 846) @+10644021

Has anyone come across this? I have been using the FlowMVI as an example.

So sorry for the long response! I didn't get emails for some reason, so I didn't even know there were questions here. Yes, this function is cumbersome to use because you have to import it by choosing the correct overload in the list, by default, it will just use the default one. This will be fixed with context receivers I hope

Hi, how you recommend doing communication between stores. I have a screen that is a list of Type A with a list of Children of Type B, I have one huge container managing the state of the screen and I want to break it up into components. Do you have a recommendation for achieving this with FlowMVI?

Hi, @Vaizin Nikita how would you mock a store for UI tests?

God, I don't check the slack enough and don't know what is up with notifications!

I have all of the notifications enabled, but I received 0 of them for a bunch of mentions here.

Okay notifications should be fixed now.

Massive Update 🤯 3.1.0-beta04 The highlight: you can now decorate any plugin. And since a store is essentially a plugin for itself, you can also decorate the store. To do this, there’s a new function in the builder called decorate, or you can use the

decorator { }

DSL and then

install(decorator)

in the store. This enabled the creation of new built-in decorators (plugins) for retries, buffering, debouncing, and conflating intents. 🧨 API Changes • Changed the installation order of “time travel” for plugin test DSL. This will break tests that relied on the old value in time travel—now it’s the new one. This was a mistake in the API design. • Kotlin 2.1 • Changed store lifecycle behavior: now it doesn’t wait for the next lifecycle event to close but skips the operation instead. This was very inconvenient in beta02. Debugger and Plugin Updates: • Added live templates for the plugin: • fmvic - a new container. • fmvip - a new plugin. • fmvilp - a new lazy plugin. • fmvim - models (LCE states, intents, and actions). I recommend using the plugin just because of this feature — it generates all (already minimal) boilerplate for creating new stores in seconds. 🚀 New Features • Added a callback for undelivered intents/actions in the plugin DSL (#106). • Added a shutdown context with some store API in the onStop callback. • Optimized plugin chain execution by skipping empty callbacks. • Implemented store decorators and corresponding DSLs. • New decorators: TimeoutDecorator, ConflateDecorator, RetryDecorator, BatchIntents. • Added logging of undelivered intents/actions in the loggingPlugin. • Improved performance by reducing context switching in the store (#105). Docs on the website are still in progress. I haven’t had time to write articles due to the volume of features, plus I need to use some of the new functionality for my work. Currently working on a plugin for automatically collecting performance metrics for any store ⚡️ It should land in the fifth beta.

Hi guys!

How I Made a Game Engine Using MVI in Kotlin I wrote an article on Medium where I explain in detail how to use FlowMVI to manage the lifecycle of business logic, handle errors, implement caching, manage resources, prevent memory leaks, and ensure thread safety—using a game engine from my work as an example. https://medium.com/proandroiddev/how-i-made-a-game-engine-using-mvi-in-kotlin-4472d758ad05 I’d be glad if you clap for it and spark some neural activation in me to write more articles and improve the library!

Hi everyone, happy New Year! Some presents for you: • I'm considering renaming the library, so I'd be happy if you voiced your opinion in this discussion & poll • I wrote a new documentation article explaining the State management on documentation with all the details you need. • The website has been remade from scratch on a new stack to enable SEO, better theming and custom layouts • The Quickstart guide has been rewritten from the ground up to let you try the library in 10 minutes • And of course I totally forgot to mention the stable 3.1 release

Hi @Vaizin Nikita! Just wanted to say I loved those couple of articles, they did get me hooked up in the idea behind the library and I'm not trying to integrate it in a personal project to see how well it helps me achieve my goals when designing apps. Great work! I'm having a small issue in following the ViewModel integration with Koin: I see the documentation using

getViewModel(...)

in the composable version of

storeViewModel

, but I couldn't figure out where that is coming from. I tried replacing it with

koinViewModel

which has the same signature, but it's crashing saying

No definition found for type 'pro.respawn.flowmvi.android.StoreViewModel' and qualifier 'pro.respawn.flowmvi.api.Container'

Apologies if it ends up being a trivial question!

Hi @Matteo Vettosi! Thanks for the praise. I saw your previous question, the article is a 1.5 years old so you made me realize I need to update it. The API has changed and I recommend you always consult the documentation. The articles are more for entertainment or informational purposes and can get outdated. The up-to-date Koin integration is implemented in the sample app, but it's using a multiplatform library (essenty) instead of VMs. To solve your issue, check this up-to-date code for Koin 4.1 (remember that the article is out of date?):

import org.koin.androidx.compose.koinViewModel
import org.koin.compose.currentKoinScope
import org.koin.core.module.Module
import org.koin.core.module.dsl.viewModel
import org.koin.core.parameter.ParametersDefinition
import org.koin.core.qualifier.qualifier
import org.koin.core.scope.Scope
import org.koin.viewmodel.defaultExtras

@FlowMVIDSL
inline fun <reified T : Container<*, *, *>> Module.storeViewModel() = viewModel(qualifier<T>()) { params ->
    StoreViewModel(get<T> { params })
}

@FlowMVIDSL
@Composable
inline fun <reified T : Container<S, I, A>, S : MVIState, I : MVIIntent, A : MVIAction> storeViewModel(
    key: String? = null,
    scope: Scope = currentKoinScope(),
    viewModelStoreOwner: ViewModelStoreOwner = checkNotNull(LocalViewModelStoreOwner.current),
    extras: CreationExtras = defaultExtras(viewModelStoreOwner),
    noinline params: ParametersDefinition? = null,
): Store<S, I, A> = koinViewModel<StoreViewModel<S, I, A>>(
    qualifier = qualifier<T>(),
    parameters = params,
    key = key,
    scope = scope,
    viewModelStoreOwner = viewModelStoreOwner,
    extras = extras
)

Hey @Vaizin Nikita, does FlowMVI have any way to help initialise a screen that requires a parameter (i.e.: an item details screen needing the ID of the item to display) without recurring to the ugly

LaunchedEffect(Unit) { intent(LoadItem(itemId) }

? I saw some people normally place that parameter in the viewmodel constructor and pass it to koin during injection, but I don't particularly like the method and it doesn't seem possible when view models are built on the fly from the Container type anyway.

So I took a stab at FlowMVI, in wasm. Took time but I guess the wasm exceptions are equivalent to hieroglyphics without a rosetta stone. All is good, but since I loved how the plugins plugin, I'm thinking about implementing it in a ktor server. Sounds wild right, and feels like like im defeating the purpose of state management. The reason is, the architecture is such a beaut, and I'm diving in. If all goes well, I'll post more here. If not, you'll still some documentation of the journey. ✌️

Hi @Benny Sway , thanks for trying it out! Wasm exceptions are currently being improved with some compiler flags in kotlin 2.0.20. The latest alpha is already using all of the relevant flags (doesn't mean you don't have to use them though 😞 ) Can you tell me what difficulties you had so that I can add the solutions to the docs? This would help everyone. I was actually thinking about using FlowMVI in a backend environment for years now, just haven't had a chance, always just writing cruds and stateless rest endpoints. But new features may finally require me to implement a proper streaming / CQRS support, which I think FlowMVI would be great at. State + async parallel message handling basically equals everything needed for CQRS. I will be happy to hear any feedback you have

Sup @Vaizin Nikita, In your previous message, I'll put a pin on it. On other news, I'll share a plugin, but I am fairly intermediate and I am no senior programmer (but might be close) And I hope it doesnt violate FlowMVI's T's and C's but here is a useful plugin I made: Consortium Plugin (gist)

Hey everyone, Just pushed out FlowMVI

3.2.0-alpha03

. https://github.com/respawn-app/FlowMVI/releases/tag/3.2.0-alpha03 The main focus of this update is on store composition. To help with that, there are two new plugins:

childStorePlugin

and

storeDelegatePlugin

. These let you build store hierarchies and achieve a cleaner separation of concerns. For instance, you can now extract logic for specific features or even UI components into child stores, instead of bloating a single main store. To show how it works, there's an example in the sample app for progressive content loading that’s just 7 lines of code. Details and guides are in the docs. https://opensource.respawn.pro/FlowMVI/plugins/delegates I’ve also seriously reworked the

whileSubscribed

plugin. It's now based on the new

SubscriptionAware

interface, which allows the store to get direct information about its subscribers. In practice, this solves the issue of unnecessary restarts during configuration changes on Android – there's now a small, configurable delay before the store stops. I wrote a ton of tests for this, but I'm still a bit anxious about the new

whileSubscribed

implementation. Please let me know if you run into any issues. The new default 1-second delay shouldn't be a major problem when updating, but who knows who might have depended on the old plugin's behavior.

@Benny Sway I was inspired by your consortium plugin for the new update, and @Fergus Hewson you also wanted communication between stores - LMK if the new system addresses it!