A modern programming language that makes developers happier.

kotlinlang

it’s also the playground for my latest story:
<https://guidelgado.medium.com/kotlin-multiplatform-mobile-sharing-the-ui-state-management-a67bd9a49882>

Great article! How would you go about adding say a textfield to the UI where the value is stored in the state and there is an event in orbit such onTextChanged(text: String). As in I find it easy to read state and update SwiftUI but two way bindings seem trickier. 

Hi <@U032VD9UZC2> thanks for your words.
Regarding your question, I would try to avoid “classic” 2-way binding to keep the MVI unidirectional and cyclical data flow. To solve those cases I have 2 ideas in mind (though they will be tied to the UI/UX of course):
1 - Edit state, where your UI have a “enter/exit” edit state. That’s what I use in my Timer sample when setting time (drag = edit, release = finish)
2 - Having a submit action where you’re on “idle state” until you submit (finish state) your changes so they get reflected “inside MVI state”.

For state “soft” save/restore both UI tool kits have capabilities to save it (rememberSaveable and SceneStorage) if we are in the middle of the “edit operation” and something happens before we store it inside MVI’s state.

I really liked this article but I felt there was a “impedance mismatch” between the 2 libraries. I wonder if orbit-mvi could be extended to introduce a state transition declaration?

Back in the days when I’ve discovered Orbit that was a question that I made to the authors, and the lack of it (Orbit+FSM) was what actually motivated me to study and write both of my articles. In the end, I don’t think it must be  included in Orbit’s lib since it is easy to integrate both - composition :pray: :confetti_ball:

But in a perspective of “maintenance” it would be cool to import just from one source, yes.

imho, wouldn’t the FSM make it more complicated to define states(?) or maybe I’m missing something in your article :pray:

The idea of FSM STATE is to work as a proxy validator, let’s say you receive an intent from View to do “C”, but you can only perform C” if you’re in “B” (you define your logic that way), but you’re currently in “A”. The MVI itself doesn’t add any protections. Sure you can create a if else logic but that’s not to clean and scalable.
The FSM will validate if you can perform a specific intent in you “current FSM STATE”. If you can, it will delegate the UI STATE logic to the MVI :slightly_smiling_face:. That’s my proposal.

I wouldn’t say more complicated, it’s more verbose true. But imagine the time you save (as a whole) by creating this rigid contracts. It will help with code iteration, testing, documentation and onboarding

You code your VM as a lego, with your methods behaving like pieces and the FSM the glue.

for instance you can have 3 methods: A, B and C, they don’t care about each other nor the logic of who calls who, that’s the FSM business.

with this you can easily have A B C or B C A, C B A, etc… (it could not make sense in a business logic perspective of course, but in a “coding/engineering” perspective you have that freedom/robustness)

I hope I it make it a bit clear :sweat_smile:

agreed thats clearer and more understandable in my parts :thank-you:

hopefully we can migrate our code to have FSM as well later