Live data from Hacker News

Slate – A completely customizable framework for building rich text editors

github.com

41–50 of 52 posts

Re: Slate – A completely customizable framework for building rich text editors

#41
post #32

Have been building https://saga.so with Slate for the last 12 months. Can confirm it was a bumpy ride, but it also gave back a lot. The main reasons for using Slate over Prosemirror were the almost complete API for managing and editing a block based page, and the fact that it's written in Typescript (although partial types support is a recent addition). We still have quite a few Slate-related bugs, and the size of ou…

Curious if you looked into Editor.js at all when building? Im in the middle of sizing up text editors myself, seems like editor.js would require less work, but wondering if I’m missing any red flags and should go with Slate or tiptap (prosemirror) instead. At some point down the road I’d love to implement collaborative editing.

We did look into editor.js and the API seems not as advanced as Slate's, mostly because Slate tries to replicate the DOM's behavior with Nodes and Ranges, so you can make edits in a very fine grained way.

If you're going for a new text editor, I'd start with Tiptap and try to check how to do advanced custom stuff with Prosemirror. Maybe if Tiptap 2 was out a year ago, we would have started with that.

For collaborative editing, definitely check out https://yjs.dev

Re: Slate – A completely customizable framework for building rich text editors

#42

Word of warning, their readme says 'Some of its APIs are not "finalized" and will have breaking changes over time as we discover better solutions.' I started using this library several years ago and have eventually had to rework it using prosemirror because I just couldn't keep up with the breaking changes. Both libraries work in very similar ways, with slate using React for its rendering layer. However Prosemirror h…

I had a similar experience. On a project I'm working we had to support IE11. Slate docs mentioned that it doesn't fully support IE11 out of the box, but that support can be achieved using polyfills. This turned out to be false and that part of documentation was very old and inaccurate unfortunately.

After few weeks of development we ran into IE11 issues we couldn't fix and Slate devs expressed that they are not at all interested in supporting IE11 in any way, which is a fair point of course since IE11 is on its way out and supporting it is a big chore. There were some PRs that were supposed to address some of the issues, but development is kinda all over the place on Slate so we weren't confident enough to go with it and decided to switch to ProseMirror.

It hasn't been easy and ProseMirror can be complicated, but we managed to work it out and created what we needed.

Re: Slate – A completely customizable framework for building rich text editors

#43

I would rather want a Typora-like (but nicely embeddable) MarkDown editor with realtime visualization (instantly applying relevant visual formatting to MarkDown elements) to ensure user's mental model of the document and the actual underlying model are always the same. IMHO classic WYSIWYG editors are evil.

Milkdown looks promising

https://github.com/Saul-Mirone/milkdown

Re: Slate – A completely customizable framework for building rich text editors

#44

Earlier quoted context omitted.

I've been using Slate heavily this year. I'm not a Slate developer, but I've read a lot of the source code, follow all the Github issues, etc., and I'm "owning an aging fork". As far as I can tell, the API instability mentioned elsehwere in this thread resulted from a nearly complete rewrite (inspired by immerjs) that launched in May 2020; for over a year since then, the API has been very stable, mainly because Ian T…

How does virtualization play with text search? Did you end up having to roll your own? I'm still working on migrating my team's Slate implementation from 0.47 to 0.5x.. the new API is simultaneously simpler but also.. harder for me to grok? Maybe I just am having trouble with the documentation because I end up reading the source more often than not.

Yes, I very much have to implement my own text search. There are many custom elements, so I would have to roll my own anyways at some point.

In my experience, I think the official documentation is just an introduction and overview, and that you have to read the source code of Slate when you're serious about doing development using it. This is not necessarily bad, since the source code is pretty readable, and the fact everybody seriously using slate is reading the source increases the number of contributors.

Re: Slate – A completely customizable framework for building rich text editors

#45

Earlier quoted context omitted.

I've been using Slate heavily this year. I'm not a Slate developer, but I've read a lot of the source code, follow all the Github issues, etc., and I'm "owning an aging fork". As far as I can tell, the API instability mentioned elsehwere in this thread resulted from a nearly complete rewrite (inspired by immerjs) that launched in May 2020; for over a year since then, the API has been very stable, mainly because Ian T…

The Slate rewrite looks much better than the previous version. It was a big step for them to remove Immutable, which had to happen given the state of that project (which, incidentally, got new maintainers last week). I'm not surprised it's rolling steady now. It's good that Ian delegated smoothly. I wondered how he did that rewrite while simultaneously working at Segment as a cofounder… I agree that Slate is nicer th…

Slate has a bunch of people that are making PR's, which is why there are 80+ open PR's right now. There's evidently been 403 distinct contributors to Slate. I don't know how to see on GitHub, but I remember a Slate developer saying Ian had delegated something like 10+ people as having commit rights for Slate (I'm not one of them). The introductory documentation that Ian wrote for Slate is also really useful and a pleasure to read, and when you need more deeply technical documentation the source code serves that purpose well. Thanks regarding the encouragement regarding cocalc+Slate; I need to get back to that part of Cocalc soon!

Re: Slate – A completely customizable framework for building rich text editors

#46
post #32

Have been building https://saga.so with Slate for the last 12 months. Can confirm it was a bumpy ride, but it also gave back a lot. The main reasons for using Slate over Prosemirror were the almost complete API for managing and editing a block based page, and the fact that it's written in Typescript (although partial types support is a recent addition). We still have quite a few Slate-related bugs, and the size of ou…

Very cool project. Thanks for sharing.

Re: Slate – A completely customizable framework for building rich text editors

#47

Earlier quoted context omitted.

How does virtualization play with text search? Did you end up having to roll your own? I'm still working on migrating my team's Slate implementation from 0.47 to 0.5x.. the new API is simultaneously simpler but also.. harder for me to grok? Maybe I just am having trouble with the documentation because I end up reading the source more often than not.

Yes, I very much have to implement my own text search. There are many custom elements, so I would have to roll my own anyways at some point. In my experience, I think the official documentation is just an introduction and overview, and that you have to read the source code of Slate when you're serious about doing development using it. This is not necessarily bad, since the source code is pretty readable, and the fact…

I don't mind reading the source, but it can feel a lot slower than it needs to to get the information I need. Of course, it's completely understandable that it would be lacking because it did just (relatively speaking) undergo a major refactor.

I can tell though that I'm going to have to write my own documentation (for my coworkers) about how to use Slate, because for me, having explicit examples of proper function usage is incredibly helpful and there isn't much of that in the documentation.. so we're basically just left with the existing examples which don't come close to covering all of the options each function has.

I'll also probably have to include a migration guide (e.g. if you used to do (a) with the old API, try (b) in the new one.. (it's probably just Editor.nodes))

Re: Slate – A completely customizable framework for building rich text editors

#48

Been looking for something like this but minus React for _ages_. I'd like our users to build their own RTE according to their needs, having a common data model on every one of them. Is there such a thing out there?

Quill is ok

My quibble with Quill is its long-standing and may not ever be fixed lack of support for tables.

Re: Slate – A completely customizable framework for building rich text editors

#49

Earlier quoted context omitted.

Just wanted to note to those thinking of using it: beware of Quill. I used it for my project, but it was not made for saving and then displaying the rich text. At least for me, it was a hassle figuring out how to accomplish this.

I’ve started using quill recently (for users to write, save and then display). I’m just rendering the saved structure and disable the editor parts for “display”. I’m happy with it

That is not how anyone would reasonably expect to be able to display rich text.

Re: Slate – A completely customizable framework for building rich text editors

#50

I would rather want a Typora-like (but nicely embeddable) MarkDown editor with realtime visualization (instantly applying relevant visual formatting to MarkDown elements) to ensure user's mental model of the document and the actual underlying model are always the same. IMHO classic WYSIWYG editors are evil.

Milkdown looks promising https://github.com/Saul-Mirone/milkdown

Nice, thank you.

I have tried the demo[1] and couldn't find how to switch to MarkDown code mode. In Typora I can just press Ctrl+Slash.

[1] https://saul-mirone.github.io/milkdown/#/online-demo

Post reply on HN