Image block: fix undo step with temporary URL#30114
Conversation
|
Size Change: +40 B (0%) Total Size: 1.41 MB
ℹ️ View Unchanged
|
|
This sounds like a good approach to me. Though, not something we could implement in things like transforms where the temporary url is assigned from outside the block (like drag and drop a file). Any thoughts about that? |
|
Haven't thought about it much. I'm checking the issues on a case by case basis and trying to find a simple solution to at least get rid of some brokenness. Perhaps we do need a better long term solution to fix all cases, but maybe it's good to reduce broken undo levels quicker if we have the opportunity to do it with a simpler change. |
Yeah, it's this sort of stuff that made #8119 so thorny to handle, and why at some point we entertained the idea of "transient attributes" or "silent attributes" or even "silent attribute changes", but we were never fully satisfied with either. That said, I'm happy that, Ella, you're working on this, and, as you say, we can polish case by case. 👍 |
61eb7a4 to
b8fa21b
Compare
|
Tested again and this seems to work well. Let's merge and iterate. Worth noting that transforms are also slightly different in that the image problem didn't create an undo trap, only a broken undo level with a temporary blob URL. |
Description
Partly fixes #8119.
The proposal is simple: keep the temporary image in local state until it is uploaded. Only then set the block attributes.
Downside: the image addition is not immediately added to the post content state, so it's not immediately undoable and the undo history might not be in the right order if the user makes changes while the image is uploading. This seems like a small enough downside that is better than a broken undo level. Usually image uploading is fairly fast.
I'm sure there's other more sophisticated solution, but this seems like a good small temporary solution.
How has this been tested?
Screenshots
Types of changes
Checklist: