Components: cdk proposal: framework for rich text editors ("draftjs" for angular)

[fxck]

tl;dr https://draftjs.org/ for angular

I've been searching the internets and there is nothing that comes even close to draftjs, which is built on top and requires react. What does it do? It solves most of the contenteditable issues and provides api for people to build their own rich text editors on top of it.

Rich text editor doesn't necessarily mean WYSIWYG textarea, it can help with anything from mentions, hashtags to replacing text emoticons with images etc.

Some of the most popular draftjs plugins can be found here and here, it should give you an idea what can be done with it.

worth reading:

• https://code.facebook.com/posts/1684092755205505/facebook-open-sources-rich-text-editor-framework-draft-js/
• https://medium.com/@rajaraodv/why-draft-js-and-why-you-should-contribute-460c4a69e6c8
• https://medium.com/@rajaraodv/how-draft-js-represents-rich-text-data-eeabb5f25cf2

I think this could be a great fit for CDK, given that you are eventually planning on creating WYSIWYG anyway.. what do you think?

@jelbourn @mmalerba @kara @andrewseguin @DevVersion @crisbeto

[devversion]

Thanks for the links. Why aren't we moving that conversation to the issue https://github.com/angular/material2/issues/2949?

[fxck]

Because that guy's looking for WYSIWYG, this is something you'd build WYSIWYG on top of, two very different things I think.

It's basically the difference between Overlay and dialog.

[devversion]

Yeah but I think this both relates together and it would be helpful to have a general discussion about it first.

[fxck]

Nope, it's like a separate issue for Overlay and dialog/menu/select.

[devversion]

In the past my opinion was that this should be rather part of another repository or just a 3rd party library. Now though, I can see how the components monorepo could benefit from providing such a framework. Fair enough that these are separate issues. I didn't realize before.

[fxck]

I understand why you'd think so, but look into what draftjs actually does (or watch this video https://www.youtube.com/watch?v=feUYwoLhE_4), it basically doesn't care about visual representation at all, which is what that guy in #2949 is ultimately looking for - a component with buttons that do stuff..

The reason I'm really asking here is because google/angular team has enough brain power and experience to actually do something like this (it's in a way similar to angular compiler). If you search the internet you won't find anything remotely close to draftjs, everyone's creating mentions inputs, emoticon replacers, WYSIWYG textareas, only facebook took a step back and asked what's in the core of such features. I really find it similar to what other CDK services do. It could greatly empower other component creators, it's a really powerful high level service.

[mlc-mlapis]

I did not go to the details but it looks that https://quilljs.com (used in PrimeNG UI components for Angular https://www.primefaces.org/primeng/#/editor) is very similar from the concept point of view?

[fxck]

Quill looks like WYSIWYG to me. If there's anything similar, it's slate, again, just for react. Read the comparisons.

Also https://youtu.be/gxNuHZXZMgs?t=1791 this guy saying that he talked to angular people who decided to add react/draft as a dependency simply because they couldn't find anything similar in angular world.

[mlc-mlapis]

From the first point of view sure but I meant mainly the background of it. Its internal structure, API, ...

[fxck]

I don't know, I think their own comparison to draft speaks for itself https://quilljs.com/guides/comparison-with-other-rich-text-editors/#draft they are out of the box usable wysiwyg, draft is just a high level service that allows you to build rich text editors (not necessarily wysiwyg editors).

Simple test is to see if quill, or any other lib, can also be used to smaller, "simple" things like facebook-like mentions. You won't really find a quill plugin for that (it was never made with that in mind, to quote their own site "Quill’s only use case is rich text content"), and if you do, you'll find that it relies on DOM data-* attributes to carry data, unlike draft which stores them in a JSON structure, which I think is a better approach in angular world.

Also worth watching to understand how draftjs works internally https://www.youtube.com/watch?v=vOZAO3jFSHI

[mlc-mlapis]

Yeah, it is certainly true. I did not go so deep, I just looked at some basic operations as

quill.setContents([
  { insert: 'Hello ' },
  { insert: 'World!', attributes: { bold: true } },
  { insert: '\n' }
]);

and corresponding Deltas representing the changes which use JSON format.

[jelbourn]

We have chatted about this in the past (and one Angular team member actually has a decent amount of experience with this kind of thing). It's something we'd like to do, but is pretty far down on the priority list.

[mlc-mlapis]

Oh, really? Sounds positive. 👍 Is it possible to share some more details?

[fxck]

@jelbourn I got in touch with the guy who made draftjs, to see if he or the team would be willing to share experience and help you out, he's not working at facebook anymore but said he'd pass the message along.

He also told me that the whole model of draftjs does not depend on react, so in theory you'd only need to create a component that fixes all of the contentEditable problems, which should, again in theory, be very similar to how draftjs does it. But there's one problem, draftjs uses "decorators" to visually change selected node, basically to wrap its contents, and it does it with components, and as far as I know, that would require this https://github.com/angular/angular/issues/6886, which is problematic, I think?

Anyway what I'm saying is there's a chance to port draftjs to angular, maybe as a temporary solution until angular team works on their own implementation, which by the sound of it, could take a while.

[fxck]

So I started messing with it yesterday, I managed to port the whole (or well, most of it) model part to typescript, you can check the prototype here.

With it, you can create EditorState, ContentState, SelectionState, which is pretty cool, now there are two more major parts missing, first is the actual fix of contentEditable, which I'm gonna work on today and which should be possible to more of less copy from draft, the other part are decorators, I don't think it's even possible to do something like that in angular, so I'm gonna look for some help.

[axtho]

@fxck are you going to continue with the prototype? The suggestion is really good.

[fxck]

@axtho I ran out of time I could dedicate to it, tried to get couple of people on board, but none was really interested

[fxck]

@jelbourn now that almost all of the components are done (or at least will be by the end of the year), any approximate idea when this could happen? Q1 / Q2 18?

[jelbourn]

We might start exploring the space in Q2 depending on how other stuff goes. In terms of larger projects, virtual-scrolling, tree, table improvements, and data visualization are all higher up on the list.

[fxck]

The way angular.io handles docs / https://github.com/wardbell/ng-dynamic-app/blob/master/src/app/docviewer/docviewer.component.ts might actually be a way (and probably the only way without including the whole compiler) to do something like draftjs decorators https://draftjs.org/docs/advanced-topics-decorators.html#content

[fxck]

@jelbourn Q2 still a go for the exploration? Will Ivy help this? Or angular/elements?

[jelbourn]

Probably not at this point; it's looking now that Q2 is mostly going to be finishing up drag/drop and virtual, addressing some tech debt and productivity issues (mainly trying to speed up the rate at which we can sync stuff into Google), and support/validation for Ivy work.

[wynfred]

I wrote a directive. It implements MatFormFieldControl to make contenteditable compatible with MatFormField.
I'm pretty new to web development, so I basically just copy/paste stuff from matInput. The errorstate and some other stuff are a little confusing for me and I'm not sure I implemented them correctly. I hope I can get some help from material team to test/improve/fix my implementation.

[naveedahmed1]

@jelbourn are there any guidelines for third-party WYSIWYG editor developers who want to add support for Angular Material 2?

For example CKEditor 5 which has been completely rewritten in ES6 and provides all the necessary tools to easily integrate it with modern applications and technologies such as Angular. And they officially support Angular https://github.com/ckeditor/ckeditor5-angular. They seems to be interested in officially supporting Angular Material as well but clarity on best approach is needed.

Please take a look at:
https://github.com/ckeditor/ckeditor5-angular/issues/21
and
https://github.com/ckeditor/ckeditor5-angular/issues/21#issuecomment-427815650

[jelbourn]

It's not clear to me what "adding support for Angular Material" would mean. Could you clarify?

[naveedahmed1]

@jelbourn To be more specific I am referring to the support of WYSIWYG editor inside MatFormFieldControl. In case of ckeditor they have a separate plugin ckeditor/ckeditor5-angular for Angular.

Now, to support ckeditor inside MatFormFieldControl, should they have a separate plugin e.g ckeditor5-angular-material? since in order to support MatFormFieldControl they have will to add @angular/material a peer or explicit dependency in package.json file. And since its not necessary that everyone using ckeditor/ckeditor5-angular would also be using Angular Material, so it would be an additional dependency for them. Or is there any other solution that can allow this without importing it to satisfy the angular DI.

[jelbourn]

All you would really need is a directive that implements MatFormFieldControl in order to work with mat-form-field (similar to MatInput). That's something that would best fit in its own package so any existing packages don't have to pull in dependencies.

[fxck]

Any updates?

[wynfred]

Not sure if the material team is interested in taking something like this into the official lib.

[jelbourn]

No plans to work on this at least through 2020.