Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using sealed classes for intents. #76

Open
nicbell opened this issue May 18, 2021 · 2 comments
Open

Using sealed classes for intents. #76

nicbell opened this issue May 18, 2021 · 2 comments
Labels

Comments

@nicbell
Copy link
Contributor

nicbell commented May 18, 2021

Hey

I have a proposal to switch to using sealed classes, data classes and objects to represent intents.

Currently we are exposing multiple functions from our view models to our views to represent actions

class MyLoginViewModel : AndroidDataFlow()
  fun login(mobileNumber: String, code: String) = action { 
    // Manipulate state
  }
  
  fun resendCode(mobileNumber: String) = action { 
   // Manipulate state
  }
}

// In our view
viewModel.login(mobileNumber, code)
viewModel.resendCode(mobileNumber)

Recently in projects I have been using this approach to have fewer public functions and use sealed classes for intents and handle the intents in an exhaustive way.

sealed class MyLoginIntent {
  data class Login(mobileNumber: String, code: String) : MyLoginIntent()
  data class ResendCode(mobileNumber: String) : MyLoginIntent()
}

class MyLoginViewModel : AndroidDataFlow()
  fun onAction(intent: MyLoginIntent) = action {
    when(intent) {
      is MyLoginIntent.Login -> login(intent)
      is MyLoginIntent.ResendCode -> resendCode(intent)
    }  
  }
  
  private suspend fun login(loginIntent: MyLoginIntent.Login) { 
     // Manipulate state
  }

  private suspend fun resendCode(resendCodeIntent: MyLoginIntent.ResendCode) {  
     // Manipulate state
  }
}

// In our view
viewModel.onAction(MyLoginIntent.Login(mobileNumber, code)
viewModel.onAction(MyLoginIntent.ResendCode(mobileNumber)

Currently Uniflow is taking care of manipulating and representing state in an exhaustive self documenting way. It is taking care of the flow of state but not really taking care of the flow of intents. What do you think of making this pattern part of Uniflow in some way.

@StephanSchuster
Copy link

While I like the idea of encapsulating related things and keeping APIs minimal, I think this would add slightly more complexity/code and especially prevent different usages of action and actionOn, right?

@MarcinChrapowicz
Copy link
Contributor

Not really you can modify this a little and achieve it

sealed class MyLoginIntent {
  data class Login(mobileNumber: String, code: String) : MyLoginIntent()
  data class ResendCode(mobileNumber: String) : MyLoginIntent()
}

class MyLoginViewModel : AndroidDataFlow()
  fun onAction(intent: MyLoginIntent)  {
    when(intent) {
      is MyLoginIntent.Login -> login(intent)
      is MyLoginIntent.ResendCode -> resendCode(intent)
    }  
  }
  
  private suspend fun login(loginIntent: MyLoginIntent.Login) = actionOn<...> { 
     // Manipulate state
  }

  private suspend fun resendCode(resendCodeIntent: MyLoginIntent.ResendCode) = action {  
     // Manipulate state
  }
}

// In our view
viewModel.onAction(MyLoginIntent.Login(mobileNumber, code)
viewModel.onAction(MyLoginIntent.ResendCode(mobileNumber)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants