Open ianstormtaylor opened 7 years ago
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.
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!
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.
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.
Closing, can re-open if it becomes an issue.
slate-vue is needed....
Agreed! This library has everything I want... except it is tied to React!
Is it possible to use Slate without any framework JS?
Is there any progress about this? In the end, does Slate want to be universal and framework-agnostic or not?
This is desperately needed!
For those who are looking for something similar for vue: https://github.com/heyscrumpy/tiptap
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.
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.
@pzuraq did you ever take a stab at an Ember version?
Haven't had the time unfortunately, I still want to though! I think this would be a great library to wrap 😄
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 👀
@pzuraq @knownasilya did you guys revisit this for ember.js/glimmer? or alternatives?
Not yet, but definitely on my list
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
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.
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.
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?
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 thedata
object that gets passed to handlers, ande.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 packageslate-dom
, which every view layer could then depend on instead of having to repeat lots of boilerplate browser-based code.