@kenkyee isn't the state stuff actually going against unidirectional data flow? Since events are not upstreamed to the data source and instead handled inside the component.

The lamdas you pass in are the flow back to your redux/MVU/MVI handler. Your redux handler sends the state into the component to display.

If all your `State`s are in your top-level composable, and you just pass values and callbacks down, then it’s unidirectional.

I see what you mean by I can see 2 issues with that: 1. What is the top level composable can change during the lifetime of an app, so doing that removes a bit of flexibility. 2. I’m not super happy about keeping state in any composable in the first state. Isn’t the point in unidirectional data flow, reducera what not to keep the state handling separate form the UI? If you have state in the top level composable you’re risking keeping your UI and Repo out of sync, since you now have two places state is defined/updated in.

It's passed into the top level composable... Not kept in it...

Well you're in control of your top level composable, it won't just magically change. If you have an

App()

composable that you invoke from your activity and call out to all the rest of your app logic from that, the

App()

composable is a reasonable place to host your state. Or you can pull that state out into an AndroidX ViewModel or some other stateful type, that works too. Compose is just a tool, and you can use it to implement patterns like unidirectional state flow. I would argue that point of USF is generally the same as any other architectural pattern: to help you separate concerns. You can do that entirely within something like Compose, or use other tools too, it's just a pattern.

Ah! I think I see your point now :) I didn't think about having a top level compose function to handle the overall state. Mostly since I see them as UI components, but it's more than that. Thanks for your detailed answer though. I might come back with more questions once I've played with it in my sudoku app :)