Slate: split core plugin into `slate-react` and `slate-dom`

[ianstormtaylor]

This is more of an idea, and maybe a bit longer-term, since I think keeping focused on React-only for now is best. But just thinking about if Slate were to be architected in a way that makes it possible to have view layers for different libraries (React, Vue, etc.)... in light of #1106 where we introduce the slate-react package.

Right now there's lots of logic in the <Content> component that controls things like the data object that gets passed to handlers, and e.preventDefault() to suppress browser behaviors. Lots of that stuff would want to be shared between different view libraries, since it's all just browser-specific, not necessarily React-specific.

(This separation also applies if Slate were to support React Native I think, although I don't have experience there.)

Instead, the logic inside slate-react would probably be split into another package slate-dom, which every view layer could then depend on instead of having to repeat lots of boilerplate browser-based code.

[ianstormtaylor]

Actually, the biggest question of this issue is:

Does Slate eventually want to be a the best React editor, or a set of tools that allow you to make the best editor in any view framework?

And right now I'm honestly not sure what the right answer is. The biggest place this has impact is on plugins, specifically third-party open-source ones.

If we want to be not coupled to React, then the majority of plugins shouldn't depend on React, which makes things like #835 impossible potentially. I think trying to get too far in the direction of this issue could cause us to make decisions that block potentially optimal paths in the React-specific land.

[lxcid]

My personal take is that slate should be focus on being the best editor in React (which imo it's already is). The splitting up of slate to logical components (great work btw) show that slate is build in a well design layered architecture, which make this ticket a possibility.

But ultimately, these view libraries, which all based on virtual dom diffing, will eventually diverge. For example, React support for async rendering in 16 is going to something a lot of the other libraries want to ask if they want to follow. That might significant effort to support in multiple front.

Though if there's a clear separation of concern, it shouldn't be hard for someone to take the slate-react and port it to slate-vue.

So I think this answer will be clearer as time passes.

Great work btw for recently changes. Loving it!

[ianstormtaylor]

Nice, thank you @lxcid for commenting! I think I agree with you, I don't think I'd want to make tradeoffs that _could_ be amazing if we only focused on React just because we need to sink to the lowest common denominator.

Especially because it wouldn't be the worst for the duplication to happen in a potential other-view-library version of Slate, if it meant that both libraries were perfect for the view library they were built around.

[oyeanuj]

I agree with the sentiments here as well - letting Slate continue being first focused on solidifying and optimizing its core APIs and mental models (like in #835).

As more users adopt it, I imagine we will first see folks build compat layers for more compatible frameworks like Vue and then for other places out there. Those ideas that they bring in will help in the de-coupling of Slate with React eventually (or duplicating), which I feel is a more natural way to evolve.

Also, I imagine ReactNative support is going to be more of a concern for folks already building on React, so that decoupling of the web and native would end up being a sooner concern.

[ianstormtaylor]

Closing, can re-open if it becomes an issue.

[guotie]

slate-vue is needed....

[bbbford]

Agreed! This library has everything I want... except it is tied to React!

[alexandremagro]

Is it possible to use Slate without any framework JS?

[bitkris-dev]

Is there any progress about this? In the end, does Slate want to be universal and framework-agnostic or not?

[bbbford]

This is desperately needed!

[jumika]

For those who are looking for something similar for vue: https://github.com/heyscrumpy/tiptap

[ianstormtaylor]

FWIW, as of 0.19 there are now two separate plugins being used inside slate-react, one for React-specific stuff and one for DOM-specific stuff. It's almost completely decoupled, would need one more pass to do so. But then that DOM plugin could be packaged on its own and used by others for other view layers.

[pzuraq]

Just popping in to say that I'm loving the primitives from what I'm seeing so far and am going to look into making an Ember/Glimmer based wrapper when I have the time. Definitely 👍 on being framework agnostic, can't find another library that's doing it as well so far.

[knownasilya]

@pzuraq did you ever take a stab at an Ember version?

[pzuraq]

Haven't had the time unfortunately, I still want to though! I think this would be a great library to wrap 😄

[nolaneo]

I'm also definitely interested in an Ember/Glimmer version of this! I wonder could we figure out an MVP of the current React components in Glimmer; there still seems to be some stuff that could be extracted further 👀

[burritoIand]

@pzuraq @knownasilya did you guys revisit this for ember.js/glimmer? or alternatives?

[knownasilya]

Not yet, but definitely on my list

[code2nguyen]

Hi, last week, I converted slate-react to slate-lit element which is a web component, I need to modify some selection logic on react version to support Shadow Dom.

It looks promising, will continue adding more demo on document when I have time.

Demo : https://code2nguyen.github.io/slate-lit/index.html?path=/story/slate-lit--rich-text
Github: https://github.com/code2nguyen/slate-lit