Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

split core plugin into slate-react and slate-dom #1110

Closed
ianstormtaylor opened this issue Sep 11, 2017 · 23 comments
Closed

split core plugin into slate-react and slate-dom #1110

ianstormtaylor opened this issue Sep 11, 2017 · 23 comments
Labels

Comments

@ianstormtaylor
Copy link
Owner

ianstormtaylor commented Sep 11, 2017

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
Copy link
Owner Author

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
Copy link
Collaborator

lxcid commented Sep 13, 2017

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
Copy link
Owner Author

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
Copy link
Contributor

oyeanuj commented Sep 13, 2017

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
Copy link
Owner Author

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

@guotie
Copy link

guotie commented Apr 27, 2018

slate-vue is needed....

@bbbford
Copy link

bbbford commented May 24, 2018

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

@ianstormtaylor ianstormtaylor reopened this Jul 3, 2018
@alxmagro
Copy link

alxmagro commented Jul 9, 2018

Is it possible to use Slate without any framework JS?

@bitkris-dev
Copy link

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

@bbbford
Copy link

bbbford commented Sep 26, 2018

This is desperately needed!

@jumika
Copy link

jumika commented Oct 9, 2018

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

@ianstormtaylor
Copy link
Owner Author

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
Copy link

pzuraq commented Nov 16, 2018

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.

@ianstormtaylor ianstormtaylor changed the title split core plugin into slate-react and slate-browser split core plugin into slate-react and slate-dom May 2, 2019
@knownasilya
Copy link

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

@pzuraq
Copy link

pzuraq commented Jul 27, 2019

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

@nolaneo
Copy link

nolaneo commented Sep 10, 2019

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 👀

@erichaus
Copy link

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

@knownasilya
Copy link

Not yet, but definitely on my list

@code2nguyen
Copy link

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

@dvincitravis
Copy link

Hi! Is there any news about this idea?

I'm looking for a good structured content editor. Slate looks very promising – but I'm in Vue-land.

@dylans
Copy link
Collaborator

dylans commented Mar 8, 2022

The closest I saw was https://github.com/marsprince/slate-vue .

If someone wants to do the work to split things into two packages, I'm happy to review and land. Part of that effort should really involved writing more tests as slate-react doesn't have a lot of tests.

@AndreKR
Copy link

AndreKR commented May 7, 2023

Could you use React to build your Slate-based editor and then embed the whole thing into a Vue application like you would do with any other JS library?

@rbirkby
Copy link

rbirkby commented Feb 8, 2025

Appears to be implemented through #5731

@dylans dylans closed this as completed Feb 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests