Thinking About ProseMirror and MarkupEditor

[stevengharris]

I came across ProseMirror the other day, and it made me wish it had existed in the form it is in now when I started MarkupEditor. I found this writeup comparing it to CKEditor to be useful, too. As I snarkily said in the MarkupEditor README, there are plenty of nice JavaScript WYSIWYG or rich text editors, but I'm working in a Swift world, and they didn't really fit well for me.

On the other hand, ProseMirror has a level of abstraction that makes a lot of sense to me. This is especially true because the 11,000 lines of JavaScript in the MarkupEditor are almost all centered around manipulating the DOM and dealing with the consequences of manipulating the DOM. ProseMirror exposes what looks like a well-thought-out document model of its own, along with first class representation of the editor state. The fact that the view is cleanly separated also means they have a well-formed notification mechanism for changes, something the MarkupEditor relies on to notify the Swift side of changes. All this leads me to believe that I could replace about 80% of the JavaScript code by introducing a - shudder - dependency on ProseMirror.

A few more of my thoughts on the topic, and then I hope others might pipe in with their own thoughts (and definitely with any direct experience with ProseMirror)...

1. The undo/redo mechanism in the MarkupEditor is a really nice hack IMO, but it is a hack nonetheless. It allows me to mix the browser-standard undo mechanism in with MarkupEditor code execution in cases where I modify the DOM. (For example, insertion into a list, but there are many more). It would be great to offload that entire thing and the painstaking undo/redo/undo-again logic in complex DOM manipulations.
2. The choice to use clean HTML for documents has been something that has, for me, paid off many times over. The idea of having a proper document model that can be transformed to clean HTML or Markdown without introducing even more dependencies is appealing to me (although I have admittedly not tried ProseMirror, so maybe this is an illusion).
3. In terms of adopting ProseMirror as a dependency, I think it would be largely transparent to most MarkupEditor users, but that really remains to be seen. I think the MarkupDelegate callbacks and the MarkupWKWebView calls to modify the document (like bold, etc), which are really the MarkupEditor API, would remain mostly unchanged. The MarkupToolbar would remain unchanged. The mechanisms to deal with custom scripts and css would have to be adapted and likely change, but I think the same capabilities would be supported (I need them myself!).
4. I think that some of the bugs I've encountered over time, like this horrible only-fixable-by-Apple one and the current ones involving iOS keyboards disappearing here and here would not be issues. These bugs fall in a realm where MarkupEditor relies on WebKit behaving in a way that is, in essence, undocumented, so it ends up being subject to changes on Apple's side between releases that Apple might not even consider to be a regression. These types of issues are also very difficult to test-for on the MarkupEditor side.

The last item has me envisioning MarkupEditor users thinking: "Just fix my damned bug, don't even think about ripping things apart!". Okay, a legitimate concern, but I am also a user, and my ability to address bugs is quite bandwidth-limited. If introducing a ProseMirror dependency offloaded 80% of the JavaScript code and probably even more of the maintenance issues, then I would have a lot more time to devote to bug fixing (and, say, changing the iOS keyboard experience)

If anyone has thoughts or experience on this topic, I'd greatly appreciate you contributing to this discussion.

[stevengharris]

I have been looking into using ProseMirror some more, and I am feeling quite good about it. I am impressed by how well-thought-out ProseMirror is. The documentation is very complete, and the forums have useful support info as I was trying to get things to work. At this point, I have everything in the demo working except for the "insert" options like link, image, and table. As expected, the net reduction in my own JavaScript code is about 80% (I'll have actual numbers before long). I have made essentially zero Swift-side changes for this to work so far, so my belief that it would be transparent for users who have not forked markup.js is holding true.

From a development perspective, if you want to modify the JavaScript code (now in MarkupEditor/rollup/src/js/markup.js) you need to use a JavaScript bundler. I used rollup.js, mainly because that is what is used in ProseMirror examples. Essentially the bundler produces the new markup.js by combining the MarkupEditor markup.js and its new dependencies from ProseMirror into a single new markup.js by invoking npm run build in the MarkupEditor/rollup directory. This way, all of the MarkupEditor mechanics for the MarkupWKWebView lifecycle just work. In the end, though, this means JavaScript side customizations of the MarkupEditor will require npm and rollup in your toolchain. That may be a bit of a pain for first-timers to set up, but running rollup takes less than a second.

Right now all of this work is on a markupmirror branch if you want to try it out with the SwiftUIDemo. Here is what it looks like...

It should look familiar, because it is just like the "normal" demo, except that it currently shows the ProseMirror example toolbar as part of the MarkupWKWebView. This will go away, but it's been handy to check the operations that are invokable from the SwiftUI-based MarkupToolbar at the top. If all of this looks unimpressive in the demo, then that is success, because the code making changes to the displayed web page and the HTML you can see at the bottom all come from invoking ProseMirror functionality, not from my code manipulating the DOM. Undo/redo work beautifully, too!

And here's a bonus... The issues (#214, #159) of the iOS keyboard disappearing on bold, italic, etc, and style changes are fixed in this version.