Improve lifecycle docs on Workflow, RenderContext

[rjrjr]

Quoth @Armaxis:

In Workflow.kt docs there’s a paragraph stating:

This context allows the workflow to interact with the outside world by doing things like listening for events, subscribing to streams of data, rendering child workflows, and performing cleanup when the workflow is about to be torn down by its parent. See the documentation on RenderContext for more information about what it can do.
I searched around the RenderContext but haven’t found anything about the cleanup process of workflows. Is there anywhere I can read more in-depth?

Context: I was searching for a way to cancel payment when Workflow is no longer rendered, and it took quite some time to find LifecycleWorker. I wish Workflow would point better to it?

My first instinct was to search for onCleared/onCanceled somewhere in workflows -> then dig around RenderContext -> Cmd+F for cancel -> LifecycleWorker

[zach-klippenstein]

We should probably focus the docs on runningSideEffect which is more flexible and encourages better coroutine-based code.

[rjrjr]

Shall we delete LifecycleWorker? The only interesting thing about it is its subtle choice of preferring a finally block around a suspend call, and I'm not so sure that's actually interesting.

…

On Fri, Mar 5, 2021 at 8:49 AM Zach Klippenstein ***@***.***> wrote: We should probably focus the docs on runningSideEffect which is more flexible and encourages better coroutine-based code. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#356 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOMCHKXNDSFIUYOVSZVM6LTCEDSZANCNFSM4YVQ3CBA> .

[zach-klippenstein]

Every time this comes up I am less convinced it serves a real purpose. I would be ok with deprecating it.