search

hadrysmateusz / slate-plugin-system

Add complex functionality to slate apps with a single import
Other
2 stars 0 forks source link

Pros/cons/rational vs slate-plugins-next? #1

Open beorn opened 4 years ago

beorn commented 4 years ago

Hi,

Just wondering, if you don't mind sharing, what the rationale was for forking slate-plugins-next, and what your long-term plans are (if you have made those)? It might help people decide which project they align with and how they relate to each other.

hadrysmateusz commented 4 years ago

Hi, Short answer: you should probably use slate-plugins-next

Long answer: this is a fork that I'm using for my current personal project. It contains a few changes from slate-plugins-next such as putting all editorOverrides into the plugin object. The differences are minor and I intentionally tried to maintain compatibility with plugins created for slate-plugins-next. My goals were to maintain only the core of the library along with some utilities in this repo with all plugins being stored elsewhere. I have a set of plugins using the system that I use for my own project along with what was supposed to be a template repository for plugins that I never got to publishing. I also tried to play around with the typescript types but that is something that I'm still in the process of figuring out. Contrary to what the size of the readme might suggest I never expected anyone to use this library, at least not for a while and I haven't actively worked on it for some time as other parts of the project are eating away at my time. I see that the slate-plugins-next team has made huge strides in the time I was inactive and so I doubt this library will be of use to anyone right now.

If there is any interest in it I might consider supporting it but right now it's mostly for personal use.

beorn commented 4 years ago

Thanks for the answer. I think separating the core of the plugin system from the plugins totally makes sense, as I think just as you, others (including me) have the same use case: using the core of the plugin system but having their own set of plugins (that's the point of a plugin system anyways).

Also, the core should probably get a lot more love and care than peripheral plugins, so it makes sense to be split out for that reason too. I thought your Editable.tsx looked smaller/cleaner than slate-plugins-next's EditablePlugins.tsx + its utils, hence my question.

Maybe some of your good ideas can be shipped back to slate-plugins-next then? They seem to be set up for a mono-repo with packages, but so far there's only one (mono-)package.

hadrysmateusz commented 4 years ago

Thanks :)

To be honest my Editable.tsx is basically their EditablePlugins.tsx from a few weeks ago with a few minor modifications and the addition of editorOverrides. They seem to have refactored it into a set of utilities and used the "useCallback" hook for performance and while passing the dependencies for all of them to the Editable component seems pretty weird to me at first glance, the gained performance is probably worth it.

I would love to contribute to slate-plugins-next but honestly I wouldn't know what parts would be worth it at the moment. I also think that some of their design choices (e.g. not including editorOverrides in plugins) are by design and I currently lack the slate experience to know what the unintended consequences might be.

I do think that the main issue with slate-plugins-next is the fact that their core is bundled together with their plugins but on the other hand it's tree-shakeable so it's probably not an issue (I dont' know enough about bundling and tree-shaking to really know).

If you have any concrete ideas on what should be shipped back to slate-plugins-next then let me know and maybe when I get back to working on the plugin system I will make some pull requests there.

However they seem to be working on that package very actively and so probably when I get around to it, they will have found a completely different solution already.

beorn commented 4 years ago

Ok, thx for the clarification. I will play more with slate-plugins-next and your slate-plugin-system and let you know.

My general feeling is to learn from ProseMirror and Tiptap in terms of a modular architecture and suitable core features (some would be in Slate, some in plugin/extension system, some in actual plugins/extensions). I think Slate is a nice and modern base, but could use a layer on top that makes it easier for us to share and reuse functionality.