Closed askvortsov1 closed 3 years ago
I like your proposal. As to your question, I think that we should bundle a decent WYSIWYG by default that includes mentions. Yet allow for a fully trimmed down Composer as well. So removing the bundled editor should provide the option for alternate solutions, even if that means having to lose mentions functionality as well. A good mentions extensions will never fully be independent from the editor, because rendering, parsing and linking suggestions while keeping user privacy in mind is not easy.
fully be independent from the editor, because rendering, parsing and linking suggestions while keeping user privacy in mind is not easy
Well, actually, it kind of is. If we continue to literally encode mentions as @USERNAME, the current approach of hovering a dropdown above and entering that into the composer via the editor interface works fine. And of course we could adopt something like https://www.npmjs.com/package/prosemirror-suggest for cleaner integration, but that's just style.
What I means is that if we want to abstract away the username in favor of id / display name, https://github.com/flarum/core/issues/1734#issuecomment-644391424 would make it cumbersome to type out mentions, so it would integrate well with proseMirror but not the standard editor.
To clarify: the milestone item is the above-listed 4 PRs that switch to an editor driver solution. Once that's merged I'll be releasing a third-party rich text editor extension. I designed it to be highly extensible; as a proof of concept, I'll also be releasing an update to https://discuss.flarum.org/d/18922-markdown-tables, which includes support for editing the table via WYSIWYG.
There are currently no plans for core to include a rich text editor directly due to the bundle size increase involved (the solution I got working performs extremely well and is extensible, but is ~350 kb minified, which is equivalent to all of core's forum JS. This would be the case for other editors as well). We might decide to ship one as a bundled extension sometime in the future, but that decision has not yet been made, and will not be made until after stable is released.
Another benefit of the above refactors I forgot to mention: TextEditor
is now completely detached from composer
: all it cares is that a composer
attr is passed in, and it'll set the editor driver instance as a property on that. But that composer
attr could be anything. So it should be very easy to use TextEditor
for other stuff (moderator notes/warnings, discussion templates, etc).
Sometime in the future (separate from this PR), we should moveTextEditor
and the editor driver from forum
to common
; that way, it will be usable in the admin dashboard, e.g. for flarum/issue-archive#360
A WYSIWYG editor is probably among the most requested Flarum features of all time (https://discuss.flarum.org/d/1537-pick-three-features-you-d-love-to-see-in-flarum), with numerous extension attempts (https://discuss.flarum.org/t/extensions?q=editor). However, this has been challenging for several reasons:
execCommand
is a no-go (https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand)So I set out to experiment and explore potential improvements that would enable smooth integration of a WYSIWYG editor with Flarum. For this experiment I used proseMirror, a library for building editors. Other options:
Try 1
I attempted to do what most rich text extensions so far have done, and extend/override various methods of
TextEditor
. This works on a basic level. https://github.com/askvortsov1/flarum-rich-textObservations:
TextEditor
'stextarea
html element in a div wrapper, then manipulating that. We can't assume thattextarea
will existSuperTextarea
to act as a full abstraction for the text editorTry 2
I tried going in a significantly different direction, and including a basic proseMirror setup directly in core. I added styles and customizations so that it exactly resembled the html textarea-based solution. Then,
flarum/markdown
could extend that basic proseMirror config to add markdown support. I was also hoping to get mentions working with this solution, but wasn't able to get that done. https://github.com/flarum/core/pull/2567, https://github.com/flarum/markdown/pull/23Observations:
package.json
. Furthermore, the markdown config modifications required those same packages again, meaning that either we'd have duplicated code, or we needed to load literally all of it into expose loader, and extend webpack config for markdown. I ended up going with the latter, since when I tried the first option, the duplicate packages broke the editor. Needless to say, this was a huge mess, and we should keep config together as much as possible.My Proposal
I don't think core should include a complex, full rich text editor. It's messy, and IMO it goes against the Flarum philosophy. That being said, with a few simple steps, Flarum could do a lot better in terms of enabling WYSIWYG as an extension. I propose the following:
app.composer.editor
.SuperTextarea
and some methods fromProseMirrorEditor
(focus
,destroy
, etc)buildEditorDriver
method ofTextEditor
apply
utils should be brought into core (https://github.com/flarum/core/issues/1872) as part of that main driverOutstanding questions: