41–45 of 45 posts
I love these initiatives. It does, though, need thorough testing in an office environment. Things that users, not developers, will come out. For example, I tried cutting and pasting from Word. Forget about formatting, none of the line breaks carried over. That's not to discount this. It'll be great in certain settings, but it has far to mature if it's goal is to compete with tinyMCE.
This is great! I agree that I think this kind of editor composing is the way forward for most content editing on the web. I was deep into Draft a while back, and there are some downsides to it though. It's document model is flat, which makes it hard to model nested structures like tables, captions, etc. It also treats a lot of the built-in logic in privileged ways which makes it hard to override and add custom logic.…
I've built and am maintaining a rich text editor that is a lot like Gmail's except it also supports dynamic variables, snippet insertion, and a few other things like that. Nested content hasn't been a concern for me, so DraftJS has been pleasant for the most part. Using Immutable for core state makes my life so much easier.
But I do agree with your assessment that Draft's API and docs are lacking, and some of the design decisions are a bit odd. Doing relatively simple operations can require quite a few more steps than you would expect, meaning I had to implement a lot of helpers (that you think would be included) myself. Slate's Transform API looks a lot more capable and straightforward out of the box.
HTML serialization, something you would expect to be part of the core library, only has a half-assed implementation that isn't customizable and that doesn't handle anything more than anchor tags.. so you have to install a third-party library to do it.
Just one question: if you can have nested blocks, do you really even need marks? Are they just there for convenience?
This is great! I agree that I think this kind of editor composing is the way forward for most content editing on the web. I was deep into Draft a while back, and there are some downsides to it though. It's document model is flat, which makes it hard to model nested structures like tables, captions, etc. It also treats a lot of the built-in logic in privileged ways which makes it hard to override and add custom logic.…
Slate looks awesome. I wish I had seen it when I was looking for a replacement for our core rich text editor library.. although I probably would still have gone with Draft merely because of the Facebook support. Should they stop updating it, I know what ship I'll be jumping to. It looks like the concepts are similar enough that porting wouldn't be too painful. I've built and am maintaining a rich text editor that is…
> If you can have nested blocks, do you really even need marks? Are they just there for convenience?
Interesting question!
It depends slightly on your use case, but I think for most of the "rich text editing" use cases, you'll probably want them.
They're beneficial in that they have separate semantics to inline nodes in the tree, since they aren't nested. Such that you can apply them in any order, and the JSON data structure is the same. This is useful because you don't have to worry about ordering when doing things like bold(italic(strikethrough(comment(TEXT)))). Which is usually simpler for users to understand, and simpler to work with in code anyways.
The inline nodes are only really useful for what you'd model in HTML as `display: inline-block`, for things that aren't really running "text" but can appear in the middle of the document, like inline images, latex, etc.
But if you're able to avoid inline nodes altogether, it's easiest to model things as blocks and marks.
This has me thinking about whether it's possible to get rid of "inline" nodes though, that's interesting.
This looks really good. I'm only missing an option to put in formatted code or something.