https://kotlinlang.org logo
Join Slack
Powered by
Question about Square Workflow: what are the useca...
# squarelibraries
l
Question about Square Workflow: what are the usecases when you’d choose Stateful vs Stateless workflow? (If your screen saves state using a Snapshot? Something else?)
z
Stateless workflows are just Stateful workflows where the 
StateT
type is 
Unit
, e.g. they don’t actually have any data in their state. So if your workflow doesn’t need to actually maintain any internal state, 
StatelessWorkflow
is slightly less boilerplate to write. This is common if your workflow is just running some workers or mapping its props directly into renderings. It’s also useful for tests, if you need to provide a fake child workflow to inject into some other workflow.
l
Makes sense. Thanks @Zach Klippenstein (he/him) [MOD]
z
Np!
l
More related questions if you don’t mind. I am trying to build a simple master detail Note app. I am very familiar with MVI but Workflow is not easy for me to grasp. The first screen displays a list of notes from repo and has a FAB to add a new note. Clicking on a note, will bring you to note detail from which you can edit or delete the note. When you return the main (note list) screen the changes are reflected since repo was updated when the detail was updated. How would you approach it? A Stateful or Stateless Workflow for the master screen and a Stateful Workflow for the Detail screen? Would the state of each contain loading and error states besides the data state?
z
Re: loading/error states, typically we tend to model them as sibling states to the "loaded successfully" state in a sealed class, yes. But that's just convention. If your state includes other data that is shared between all 3 states (loading, error, success), it may make more sense for your workflow's 
StateT
to be a single data class that contains a "loading state" property (which might itself store a sealed class value).
For master/detail, just for background we talked about this at droidcon: Video: https://www.droidcon.com/media-detail?video=362741019 (master/detail discussion starts @ 16:20) Slide: https://docs.google.com/presentation/d/19-DkVCn-XawssyHQ_cboIX_s-Lf6rNg-ryAehA9xBVs/edit#slide=id.g75f6fce343c681d4_193 To get into more detail, you would probably have three workflows: 1. Master workflow: Renders the master screen, and emits an output when a selection is tapped. 2. Detail workflow: Gets the current selection in as props (e.g. as the ID of the selected item), and can render loading/error/detail screens as appropriate. 3. Parent workflow: Renders both master and detail workflows, and owns the state of “what is the currently-selected item” – updates this state when the master emits a new selection, and passes the selection down to the detail as its props. This approach is flexible because you can show master/detail side-by-side on tablets, and re-use the same child workflows to show separate master and detail screens on phones (only the parent workflow needs to change).
l
thanks again! it’s this parent/sibling/child workflow relationship that’s new and hard to get used to. i think that’s what the samples lack. there are a few single-screen games and todo app but most apps will not be a single-screen and there will be some sort of navigation involved. i feel like before i tackle showing things side-by-side, just showing a list and picking an item to go to the next screen is a more useful example to get started and then build on that. i would be happy if i could replicate something like roxie’s sample app https://github.com/ww-tech/roxie with Workflow. i am gonna try
z
Agreed, we need more samples of this sort of thing. The Todo app should be master/detail on tablets too.
r
Ooh, fun. On it.
z
l
Thanks all!
r
If you’re still looking, this is refined by https://github.com/square/workflow/pull/693, and expanded on by WIP https://github.com/square/workflow/pull/694
l
Great. Thanks! I will check it out
16 Views
Open in Slack
PreviousNext
Powered by