<@UHAJKUSTU> Is it a normal practice to have a sin...

# decompose

[electrolobzik]

@Arkadii Ivanov Is it a normal practice to have a single component for multiple sequential screens (in a wizard) in a flow in case when there is a single Store which holds the state of the flow?

[Arkadii Ivanov]

You mean having a component as an entry point for a flow, with multiple child components?

[electrolobzik]

For example I have sign-in flow. It contains the phone number screen (A) and a screen for entering the sms code (B). For this particular flow it makes sense to have a single state for both screens. I think that it should be part of some SignInStore. Both screens A and B should use this state and pass intents from the user to that store. I already have a SignInRootComponent and just added a new EnterPhoneComponent as it’s child. But this component looks like this:

class DefaultEnterPhoneComponent(
    private val sendCode: (String) -> Unit,
    private val onBack: () -> Unit,
) : EnterPhoneComponent {
    override fun sendCodeClicked(phoneNumber: String) {
        sendCode(phoneNumber)
    }

    override fun onBackClicked() {
        onBack()
    }
}

It doesn’t do any useful work, from my point of view. So my question is if it is a good solution if I remove this EnterPhoneComponent and will bind SignInRootComponent directly to screens A and B.

[Arkadii Ivanov]

Can you elaborate what you mean by "bind SignInRootComponent directly to screens A and B"? You mentioned that A is a "phone number screen", so A seems the same as EnterPhoneNumber component.

[Arkadii Ivanov]

It doesn’t do any useful work

I would store the state in the component itself. E.g. something like this.

interface EnterPhoneComponent {
  val model: Value<Model>

  fun onPhoneChanged(phone: String)
  fun onSendCodeClicked()
  fun onCloseClicked()

  data class Model(
    val phone: String,
  )
}

[electrolobzik]

Usually when I initialise the UI of the screen in the root I use the child component to pass state and handlers to that child screen:

[electrolobzik]

In this case I am thinking of avoiding the child component totally and passing the root component state and handlers directly

[electrolobzik]

Screenshot 2024-01-03 at 11.53.54.png

[Arkadii Ivanov]

Got it! As I mentioned, most likely it's a good idea to store the phone state in the child component itself.

[Arkadii Ivanov]

You can also validate the phone number in the component, if you like.

[Arkadii Ivanov]

But in case of really simple components, your solution should work.

[electrolobzik]

In what case you would move the logic from the component to a separate Store?

[Arkadii Ivanov]

I would extract a separate child component if there is any logic to be implemented or state to be owned. I would create a Store for any not-very-simple case (e.g. if there is any logic). For a simple phone number component without validation, I would just store the state in a MutableValue if I need SwiftUI, or `StateFlow`/`BehaviorObservable` if I don't need SwiftUI.

[electrolobzik]

got it, thank you one more time 🙂