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

[Docs]When I can use editor API and when I need a custom build? #1393

Closed
pjasiun opened this issue Dec 5, 2018 · 6 comments
Closed

[Docs]When I can use editor API and when I need a custom build? #1393

pjasiun opened this issue Dec 5, 2018 · 6 comments
Labels
resolution:expired This issue was closed due to lack of feedback. status:stale type:docs This issue reports a task related to documentation (e.g. an idea for a guide).

Comments

@pjasiun
Copy link

pjasiun commented Dec 5, 2018

There are 2 ways to add plugins to the editor. Simple plugins can be added using the config to the build, but many plugins need you to do a custom build to install them.

Why there are these 2 ways?
What are the pros and cons of using each way?
Up to what point I can use the API to add a plugin and when I need to build it?
What are the limitations when I use API?
Why there is no extents Plugins in some plugins?
Why sometimes I cannot require other plugins?

These are questions one may have reading documentation about some plugins (for instance reading comments integration guide which suggests adding a custom plugin to the build using the extraPlugin configuration). We need a single guide where all of these topics are clearly explained to everybody who is not familiar with modern JS. Then we will be able to link to this guide from all other places when such question may appear.

@pjasiun pjasiun added the type:docs This issue reports a task related to documentation (e.g. an idea for a guide). label Dec 5, 2018
@oleq
Copy link
Member

oleq commented Dec 18, 2018

Only today I responded to a couple of issues regarding this topic on GH. So there's some confusion.

Mainly cc @Reinmar but also @AnnaTomanek.

@pjasiun
Copy link
Author

pjasiun commented Dec 19, 2018

Another case why this docs is needed: https://github.com/ckeditor/ckeditor5-core/issues/146#issuecomment-448296031

@ssougnez
Copy link

Hello,

first of all, I really admire whole the work that have been done for ckeditor. Really a great tool. That being said, may I argue a bit about the fact that this "issue" is explained by "modern JS" ?

Take for example the "rxjs" library. The version 5 introduced the operator "pipe" allowing user to chain observable and using webpack tree-shaking mechanism to only include used operators in the bundled. I actually expected ckeditor to do the same. Basically, you could use the "BalloonEditor", then when you import the "Underline" plugin for example, webpack takes it into account and make it available.

I read about both available solutions right now but I think that they both have huge disadvantages making them barely usable:

  • Creating a custom build (as stated in the doc) requires to have a dedicated project for ckeditor and being able to publish it somewhere (npm seems a bit overkill for a private project, therefore, another tool must be used). This means that I also have to maintain it by pulling new changes and hoping that mine are not colliding with the new ones, etc... This seems pretty unrealistic to have to maintain such a big project for an application that could be way smaller.
  • Integrating build process of ckeditor with the main application build process seems to be a better solution but still way over the top. Indeed, this is something that developers would have to maintain and ensure that the ckeditor configuration does not collide with the project configuration (I'm aware that webpack-merge could be used to leverage this complexity but still). Moreover, if the build process of ckeditor changes, these changes have to be reflected in the main configuration in case of update of ckeditor. More globally, when using a library such a ckeditor, one can expect to just reference it in the code and that's it. It's pretty uncommon that third-party library (other than JS framework) forces the user to change the build process of the application it belongs to.

Still with all the respect I have for you guys (I'm really not complaining, just trying to open the debate), I really find it unbelievable not to be able to simply add a plugin to the "extraPlugins" property to make it available in the editor. When you look at it from above, the result is that you need to have a custom project or make big changes to your project to add an "Underline" button to the toolbar.

I never took the time to check the code of ckeditor in depth but how come importing a plugin in the source code does not "simply" adds the plugin to the bundle and make it available globally? I'm pretty sure that there is a good explanation, otherwise, you would have developed it that way.

Once again, I think that ckeditor is a really awesome library but when you think about it, a basic use case would be:

  • Install ckeditor package
  • Configure the toolbar
  • Enjoy it

The first step is pretty straightforward but if I want to use a complete toolbar, then it becomes very complex.

Thanks a lot and please, don't be offended by the message, I have difficulty to express myself in a way that does not look agressive, but be sure that there is not a ounce of aggressiveness in this post :-D

@oleq
Copy link
Member

oleq commented Dec 19, 2018

@ssougnez It looks like we replayed to one another in different issues at the same time 😀. Check out my reponse.

@Reinmar Reinmar added this to the next milestone Mar 25, 2019
@pomek pomek removed this from the nice-to-have milestone Feb 21, 2022
@CKEditorBot
Copy link
Collaborator

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

@CKEditorBot
Copy link
Collaborator

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).

@CKEditorBot CKEditorBot added the resolution:expired This issue was closed due to lack of feedback. label Nov 7, 2023
@CKEditorBot CKEditorBot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution:expired This issue was closed due to lack of feedback. status:stale type:docs This issue reports a task related to documentation (e.g. an idea for a guide).
Projects
None yet
Development

No branches or pull requests

6 participants