https://kotlinlang.org logo
Join Slack
Powered by
:wave: there, question about Workflow: What’s the ...
# squarelibraries
d
👋 there, question about Workflow: What’s the idiomatic way of communicating between sibling Workflows?
Copy code
Parent
    Child A
    Child B
Child A needs to send something to Child B without holding it in state inside the Parent. Is there a pattern? Right now I’ve created a Relay/Channel in the Parent, which gets passed into Child B. Child A sends an 
Output
to Parent, which then gets routed to the Relay/Channel
r
Much better to have A produce an output for the parent to interpret, and for the parent to update B's props. Remember you can override onPropsChanged in B if you need a state change.
This is a pretty abstract question, though. What are you actually building?
Another option, eg in master detail, is for A (master) to produce an int output (selection index), and for B to be stateless. Its PropsT is an immutable class with the details; its OutputT the same type.
When the UI changes some field in the details, a modified copy is produced as output.
tl;dr: Relay nasty.
z
Communicating between sibling workflows like this is generally considered an anti-pattern, better to do one of the things Ray suggested.
e
How about this scenario: In a deeply nested screen consisting of multiple workflows, (the tree I’m imagining would be on the order of 10-20 workflows in total, with about 4-5 layers) … how would you recommend handling a leaf node which needed to affect screen-global state changes?
To make it more concrete, imagine that the screen is a document viewer, which allows navigation within a collection of documents, and you have a little stateless widget that navigates forward/back — to propagate the changes using outputs would involve the entire hierarchy participating
So my thought was to use something like a 
CurrentDocumentRepository
which would be injected into (say) the root Workflow as well as this leaf node, and the leaf node could change the current document in a worker?
z
to propagate the changes using outputs would involve the entire hierarchy participating
This is by design. Forcing the hierarchy to participate makes the data flow very clear and explicit and reduces the amount of magic side effects/“spooky action at a distance” going on. For simple cases it seems like more boilerplate, but keeping workflows more “pure” makes them easy to test and also easy to re-use elsewhere in the hierarchy.
e
Interesting, I think of it as making them less easy to re-use, since they must necessarily participate in any hierarchy-wide concerns, even if they do not pertain to the concerns of themselves
Admittedly, this thinking is colored deeply by my time using React, where it is encouraged to separate “smart” connected components and “dumb” stateless components
Also, in React the hierarchies tend to be quite deep, and that seems less likely with Workflow, so the downsides of forcing this participation may be less strongly felt
z
It gets hard to re-use a workflow that injects a bunch of dependencies since it’s not clear how they are scoped. E.g. in your case, if I wanted to re-use the leaf node somewhere else, I’d have to figure out where 
CurrentDocumentRepository
comes from, who owns it, make sure I’m injecting the right one into everyone who needs it, etc. For one dependency, not a big deal. But as the list grows, it gets very hard to manage (this was actually one of the big problems in our codebase that workflows were designed to solve).
It is more boilerplate to write initially, but it’s easier to maintain and reason about in the long run.
e
👍
Super impressed with all the hard work & deep thinking put into Workflow
It’s been really fun to dive into and figure out how it works 🙂
z
I’m glad it’s been a positive experience so far! Btw we have discussions like this with other devs internally all the time – some things seem counter-intuitive but there’s usually a reason.
d
Yeah, reworking things in a way that parent contains the state made things much simpler. Thanks for the tips. Really impressive library, as Eric has mentioned, it has been fun dissecting it over this past week
8 Views
Open in Slack
PreviousNext
Powered by