"grouped" transforms
See original GitHub issueHere’s an idea for people to think about…
Right now we have transforms, and if you want to do an async transform, we say just later on call editor.onChange(newState)
. This works fine for applying the transform.
But in terms of the history, this ends up with a weird result, where a new change is inserted at a potentially later time, not when the user was expecting it. Usually it’s not really an issue, but if the async task takes a while to complete, there might be other transforms that have occurred since. Or if the original change was a “two part” change, now you’ve got this extra undo step that puts it in an indeterminate state…
For example:
- User pastes an image
file
. - Transform: insert an
image_block
withdata.file = file
- Transform: read the
file
locally and setdata.preview = dataUri
- Upload the file to your server
- Transform: set
data.url = url
when the upload completes
Now you’ve got three different undo steps. The first change was when the user actually committed the action. The second one was when there the first visual feedback for their action being completed. And the third is when the data is actually “saved/stable” as far as your data model is concerned.
You probably don’t want the user to be able to undo in steps.
It would be cool if there was a way to “defer” operations in a transform. Such that you could create one initial transform, and later add operations to it, so that they are grouped into a single undo step.
Not sure what the API might look like. Thoughts welcome!
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:8 (8 by maintainers)
I might be totally out of line but, if each save point has an id, async transform could refer it to save(group) itself with that save point.
Nevermind the question about “merge” and “save”.
I just realized setting “merge” and “save” won’t cut it if some other transform happens in-between.