What is the best practice for incapsulating ui-logic of some custom made complex UI element? For example I have a SMS code field in the Compose UI made from 4 separate edit fields. I want to move it’s logic (changing focus on input/deletion etc) from the MVI Store of the screen. Let’s say I have a component for this screen and MVI Store for it’s logic.
a
Arkadii Ivanov
12/22/2023, 3:35 PM
You can choose between the Composable function itself and the component class, I guess.
Arkadii Ivanov
12/22/2023, 3:35 PM
Perhaps, the latter would be better.
e
electrolobzik
12/22/2023, 3:48 PM
@Arkadii Ivanov Is there any example how it could look? This child component is not stacked in terms of navigation and it’s UI (compose function) will be inside another compose function, representing the screen. I just don’t fully understand how all this should be connected, how this widget component will be connected with compose code.
a
Arkadii Ivanov
12/22/2023, 3:58 PM
So you can extract a component class for your SMS code widget, if you want. Especially if you want to make it reusable. Then you can expose the state via Flow/Observable/Value.
Handling focused states is a bit of a controversial topic. You can manage it in the Composable function itself, or in the component, or event in the MVI store