I've read a lot about state managment and librarie...
# compose-desktop
j
I've read a lot about state managment and libraries that help like redux, flowredux, decompose, kotlin-bloc etc. But I can't seem to wrap my head around how composables are meant to relate to state and the one that seems to have the proper example, decompose, just seems overly complicated. Searching google is a crap shoot since jetpack is so popular. I'm primarily developing a desktop app, but the state is rather complicated so I'm concerned about state mgmt using just compose. What's the secret recipe that I am missing for someone relativly green?
c
To clear things up: Decompose is not a state management library. It's a routing library, that happens to be able to restore state between sessions/routes like
SavedStateHandle
on Android. But it is not intended to be used as a State Management layer like Redux. I've shared a snippet here before of an example of custom State Management in Compose Desktop, for a basic idea of how it all works from a centralized ViewModel-type pattern: https://kotlinlang.slack.com/archives/C01D6HTPATV/p1644259697620799?thread_ts=1644257413.142249&cid=C01D6HTPATV And finally, I haven't shared it publicly yet, but I'm getting very close to releasing a new library for State Management which works on Compose Desktop. You can preview it here though there's not much documentation yet.
👍 2
j
thank you both, @Casey Brooks very well documented mental model. Good reading
r
@Casey Brooks Looks like a very nice project. Do you plan to make ballast work on compose-web (JS target) as well?
k
👍 2
h
I'm also struggling with the state management. I'll look into these links later on. Thanks for sharing
c
Ballast intentionally doesn't bind itself to any particular UI views. I've been using it on Desktop and Android for a while, and it's currently compiled for JS and should work there but I haven't actually run it in JS yet
👍 1
The other KMP MVI library I'm aware of is Orbit-MVI, which is more mature. That team put together a

very good video

walking one through the steps to get to MVI, to help you understand how to use the pattern. I'm also putting together a feature-comparison table between all these libraries. While I am trying to be objective and highlight where each library works best, I'm sure I've got blind spots, and would appreciate any changes/suggestions to the table
j
@Casey Brooks One thing I am still stuck on, what is the purpose of the ViewModel if the State() is held in the Contract? Or is State supposed to be in my viewmodel and not the contract?
I think I am conflating the two, well three, the trivial example, the mental model, and the Sample. I probably just answered my own question...
c
Yeah, this is why I have't fully released it yet, documentation is very much needed 😊 But don't worry, I'm working hard on getting this done soon! You can see a mostly-complete example in this folder, with the actual connection from the ViewModel to Compose here The idea is that the
Contract
is just that: a contract. It doesn't do anything by itself, it's just a declarative model of your the data and interactions of a screen, as a bunch of classes. The ViewModel (and it's related components) are what actually implement the MVI pattern; the ViewModel holds onto the State object (as a StateFlow) and processes the Inputs as they are sent to the ViewModel
j
no worries, this is just so much different to what I am used to that i need to recompose my thought process.
c
I would highly recommend the video from Orbit MVI above, it's going to help you understand the general pattern much better than my project's docs will at this moment
Also, don't discount the usefulness of the Android Compose docs in CfD. All the concepts are the same, very little in there is truly Android-specific. So the official Managing State doc is perfectly applicable in a Compose Desktop (or Web) application
1
a
Most of the Android guidance that refers to androidx ViewModel is specifically about state that has a defined lifetime that outlives the composition for some reason. There are plenty of reasons you might encounter this sort of thing outside of Android as well, such as with navigation stacks, so it is indeed conceptually applicable if not mechanically
a
I agree with @Adam Powell. From my point of view, there are two different concepts - scoping the state to a "screen" + navigation, and managing the state in the scope of the "screen". The former concept is usually handled by the various navigation libraries, e.g. the official Android's
navigation-compose
+
ViewModel
, Decompose, etc. The later concept can be handled by the various MVx libraries.
💯 3
🙏 1
c
@rocketraman To follow up on your interest in Ballast on Kotlin/JS, I’ve now got some examples built with Compose Web running in the docs site https://kotlinlang.slack.com/archives/C01F2HV7868/p1648232567613589
👍 1