Skip to content
This repository has been archived by the owner on Nov 6, 2023. It is now read-only.

request view update after drop to excalidraw view #10

Open
zsviczian opened this issue Sep 11, 2021 · 3 comments
Open

request view update after drop to excalidraw view #10

zsviczian opened this issue Sep 11, 2021 · 3 comments

Comments

@zsviczian
Copy link

zsviczian commented Sep 11, 2021

Because you only add the block reference to the source line once the drop event is confirmed, the block reference does not resolve to the source text correctly in excalidraw.

Demo

2021-09-11.10-45-56.mp4

Note that I have Excalidraw switched to preview mode.
image

  • The first drop is displayed as a block reference because at the time of drop, the source reference does not exist and Excalidraw is unable to parse it to resolve the block contents.
  • The second drop is displayed correctly as the source text because by that time the block reference exists.
  • By switching back to raw mode and to preview mode again, the first reference is also resolved correctly.

Suggested solution

Note that you will need Excalidraw 1.3.6 (not yet released - but should be by the time you look at this) to accept text drops.

I think the following lines should resolve this issue if you add them here.

mdEditor2.replaceRange(stringToReplace, { line: startLine, ch: 0 }, { line: endLine, ch: endOfLine })

} else {
    mdEditor.replaceSelection(selectedText);
    //@ts-ignore
    if (thisApp.workspace.activeLeaf.view.getViewType() === "excalidraw") {
         //@ts-ignore
         thisApp.workspace.activeLeaf.view.plugin.triggerEmbedUpdates();
    }
}
@GitMurf
Copy link
Owner

GitMurf commented Sep 11, 2021

Cool! I will add, thanks!

@zsviczian
Copy link
Author

I was thinking about this... an alternative would be, that you add the block reference to the line the moment the drag action starts. The reason for dragging is to drop the block reference to another document - why wait until the drop happens.
This would solve the update issue, because by the time you are ready to drop, the block reference is already there in the file.

@GitMurf
Copy link
Owner

GitMurf commented Sep 12, 2021

I’ve gone back and forth on this. The reason I did it this way is in case the user decides to cancel the drop. They would then need to go back and undo the creation of the block reference. Although I guess I could check on cancel and then go back and remove the block ref if cancelled. Let me think about this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants