-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Image block: fix undo step with temporary URL #30114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
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: