Where do you store the current value in workflows that are editors?

[zoltish]

Hej!

First of all, Im sorry for the out of place question; its more related to state machines, but given that workflows are such machines I still think this might be the best spot for it. I hope Im not wrong!

How do you deal with workflows that are editors?

If we go with a simple example like editing a number, its clear that the editor workflow renders something that allows editing the value, but where should the current value actually be stored? I think there are 2 alternatives?

1. When the editor workflow is initially rendered, the value is stored in its state as the current one, any edits to the value are stored in its state. When the editor is done, the value is emitted to the parent workflow and then cleared locally.

2. The input/props include the value, and every change emits an output with the new value, which the parent stores in its state.

How do you deal with this? Are there other alternatives? Ive personally leaned towards 2, but that includes more work for the parent workflow and reusability becomes more of a chore. Please enlighten me?

[rjrjr]

We tend to use the second approach, and StatelessWorkflow is particularly good for that.

[zoltish]

Thanks, it feels good knowing that youre also doing this!

[zach-klippenstein]

Text editing, specifically, is really tricky. We're still experimenting with things internally to find something that is really reliable and ergonomic.

[zoltish]

Agreed! I would say that your solution of effectively replacing the text contents works really well though. I was using a custom view prior to it, but an extension function works just as well (and solves the situation where you might want a different edit-text subclass).

Id say in general, bridging the gap between workflow states & android ui can be a hassle, e.g. some views require you to add-once/register-unregister listeners between renders so that a checkbox doesnt fire a new checked event when you set the value, etc. I guess its extension function all the things.

[zach-klippenstein]

Yes that's definitely an issue. Luckily the future Android views is Compose, which handles this stuff much more naturally.