Hooks in Workflow [Idea] [RFC]

[dhavalshreyas]

Introducing HooksWorkflow, this allows Workflows to use stateful data without using the Workflow's State. Similar to React's hooks.

To use a stateful property:

let (color, colorUpdater) = HookWorkflow(defaultValue: ColorState.red)
            .rendered(in: context)

To update:

colorUpdater(.green)

[zach-klippenstein]

How would you handle multiple hooks with the same type? I think you'd need to use keys, right?

E.g.

let (foregroundColor, fgColorUpdater) = HookWorkflow(defaultValue: ColorState.red)
            .rendered(in: context)
let (backgroundColor, bgColorUpdater) = HookWorkflow(defaultValue: ColorState.blue)
            .rendered(in: context)

[dhavalshreyas]

Yes, those would need keys similar to multiple workflows.

let (foregroundColor, fgColorUpdater) = HookWorkflow(defaultValue: ColorState.red)
            .rendered(in: context, key: "fgColor")
let (backgroundColor, bgColorUpdater) = HookWorkflow(defaultValue: ColorState.blue)
            .rendered(in: context, key: "bgColor")

[AquaGeek]

Why would we not want to store state in State? I get that it's more boilerplate, but having these side channels feels antithetical to a lot of the consolidation work we've done over the past year.

[zach-klippenstein]

In kotlin, we could use property delegation to whittle this down even more:

var foregroundColor by context.hook(defaultValue = Color.Red, key = "fg")
var backgroundColor by context.hook(defaultValue = Color.Blue, key = "bg")

[zach-klippenstein]

One potential issue with this is that every hook "write" causes a complete render pass. That's fine if you're only updating one value at a time, but if you have an event handler that wants to update multiple values, you'll have a bunch of redundant render passes and potentially stale data (since each update "write" implicitly closes over the complete state from when it was initially executed).