I needed a way to cause both the markdown editor, and the webview, to update, without actually changing the contents of the editor. For the editor, I was able to accomplish that with this:
// in index.ts
await joplin.commands.execute('editor.execCommand',
{ name: 'replaceRange',
args: [ '',
{ line: 0, ch: 0 },
{ line: 0, ch: 0 } ]
});
which I could reliably detect in my editor plugin’s update function with
if (update.transactions.some(tr => tr.annotations.some(annotation => annotation.value === 'input.type.compose')))
I haven’t found any similar way that I can force the webview to re-render without changing the editor’s content. Is there a way, either from my editor script or index.ts? Preferably a way which is invisible to the user and doesn’t send the note in question to the top of the most recently edited notes list?
I’m bumping this because I still really need something like this, and I found my own thread from 3 months ago when searching for a way to do it again. For some added context, I’m working on my collapsible block plugin, and the in-development version makes headings collapsible in both the editor and webview. When in split view I’d like them to stay in sync, so collapsing a heading in one view should collapse it in the other view too - but the state of the heading as collapsed or not collapsed is saved in code, not in the actual note text. So since the text content of the editor doesn’t change, toggling the collapsibles does not cause an update in either view.
Using the method in my above post, I can update the heading in the editor just fine when the user collapses or expands the corresponding heading in the webview. But if the user collapses or expands a heading in the editor, then I currently know of no (good) way to make it also update in the webview. At least, not any acceptable way - I can modify the content of the note but that’s both dirty and sends the note to the top of the most recently edited notes list undesirably, which is the part of that method I really don’t like.
Is this not currently possible or am I just completely missing something?
If you want mobile support, there definately is no way you can do this other than to switch to another note and switch back (which is poor user experience and adds to the back history). On desktop, I think I was able to do this using the openNote command and supplying a random uid as the hash parameter in addition to the note id. I can’t remember whether or not you lose the scroll position when doing this, but the intention of the hash parameter is to scroll to a certain heading in the note, and specifying an invalid value triggers a reload but then ignores an invalid reference to scroll to. It may add to the back history on desktop as well, but if it does it’s probably less of an issue on desktop as you can easily switch to notes via clicking the note list, instead of having to navigate back all the time.
Mobile support isn’t super important here since this capability is only relevant in split view, which mobile lacks. For Desktop, I tried to implement what you described like this:
const randomHash = Math.random().toString(36).substring(2);
await joplin.commands.execute('openNote', noteId, randomHash);
(where noteId is the note ID of the currently opened note), and it didn’t seem to work - the webview neither updated nor did anything wacky with its scroll position. Did I misunderstand what you were describing?
You understood correctly. Maybe this requires the note content to have actually changed then for the refresh to do anything. Or more likely it only applies to the editor, not the viewer of the markdown editor.
1 Like
No worries, I appreciate the attempt. I’ll keep playing around, but I don’t have super high hopes - hopefully someone else will know a way, or I might have to settle on a solution that modifies the note content.