Hi, I couldn’t find a solution for this, so I thought a new topic is appropriate.
I’ve build an image upload plugin, which works well so far. The widget decorators get updated to show the upload progress and are removed when the image is fully uploaded or the upload fails. But if I drop multiple files, the decorators are created at the same cursor position (or index, as described in the guide). So as the progress is updated, the decorators will jump around the same position and won’t keep order (DecorationSet). Is there a solution to this problem?
Right now I’m experimenting with node decorators. But that means I have to add a node first, add the node decorator to that new node, style it in a different way and update or remove it after upload/failure. Is that a viable solution? And how do I handle the history in that case? If an upload fails for example, I don’t want the user to be able to get an empty image node on undo.
create a node decorator for that newly added image node:
let resolvedPos = this.view.state.doc.resolve(pos);
let after = pos+resolvedPos.nodeAfter.nodeSize;
let decorator = Decoration.node(pos, after, {style: `width:${200+percentCompleted}px;`}, {id, filename, filesize});
let tr = this.view.state.tr;
this.decorators = this.decorators.add(tr.doc, [decorator]);
this.view.dispatch(tr);
while uploading, delete the decorator and create a new one with the progress
when done uploading, delete the decorator and replace the node with a new node containing the src attribute:
let node = editorSchema.nodes.image.create({
src: this.getFileURL(uniqueName)
});
let tr = this.view.state.tr;
let selection = NodeSelection.create(tr.doc, pos);
tr.setSelection(selection);
tr.replaceSelectionWith(node, tr.doc.resolve(pos));
this.view.dispatch(tr);
So for this to work, I have to create multiple transactions. When I undo after the upload completes, I get this error:
history.js:130 Uncaught ReferenceError: Cannot access 'mirrorPos' before initialization
at eval (history.js:130)
at Leaf.forEachInner (index.mjs:102)
at Leaf.forEach (index.mjs:55)
at Branch.remapping (history.js:128)
at Branch.popEvent (history.js:55)
at histTransaction (history.js:346)
at undo (history.js:430)
at Plugin.eval (keymap.js:90)
at eval (input.js:116)
at EditorView.someProp (index.js:242)
The image gets removed, but the placeholder node stays in place and I have to delete it manually. Interesting is that it works as intended (the image and the placeholder node get removed with a single undo) when I have a fast connection. Maybe the steps must be send in one go to the collaboration server? Or can I make this steps atomic in the history or ignore them?
Interesting. I can’t see anything specifically wrong with your code, but it also has too many moving parts to easily reproduce. Can you try to reduce the code that causes this to the most minimal shape that still triggers the issue? (Replacing your remote collaboration service with a, possibly intentionally slowed down, client-side stub.)
But if I drop multiple files, the decorators are created at the same cursor position (or index, as described in the guide). So as the progress is updated, the decorators will jump around the same position and won’t keep order (DecorationSet). Is there a solution to this problem?
Not sure what the issue is here, but I have an identical use-case. In my implementation, if multiple files are added as decorations to the same position while they upload, I give each one a different side value. If another file is added to the same position, it is given the next available side value at that position. Maybe because of this, the attachments keep their order as they upload?