JS+ modular design

Plugin interaction

Today's web is completely modular in one form or another.
Just like CMS use modules, content editors use plugins (add-ons). There are plugins for CKEditor, TinyMCE, and now for Bootstrap Editor.
To allow a plugin to interact with the product it is designed for, the product should contain the code implementing behaviour of the available extensions.

Here is how plugins interact with CKEditor/TinyMCE:
Interaction of CKEditor/TinyMCE with plugins

As you can see, each plugin has one connection point to the editor. Usually, it happens as follows: upon loading the plugin declares to CKEditor or TinyMCE that its has some button with this icon and that text. Upon clicking on the button, the editor should delegate control to the plugin. In response, the plugin shows some window and makes changes to the document when the user clicks "OK".

Elaborating this idea further, we come to the the thought that plugins can evoke each other. This will reduce their size and make integration easier. Here is an obvious example. The Quick Image Upload add-on can evoke the Image Editor add-on to allow the user make changes to the uploaded image. And the image tag configuration window can further evoke a plugin to load images, and so on.

Here is a diagram to illustrate this principle:
Plugins connected with each other

Of course, plugins should implement a way to call them externally. This is what the JS+ team is doing right now - we design plugin interaction interfaces to make them become something more than just plugins. The idea is: plugins are more than tools doing just one function each as they were before; they should converge to a logically connected and sensible instrument.

As for CKEditor and TinyMCE, it is clear now. But let's move on and add Bootstrap Editor to this system. The trick here is that it already has CKEditor on board, and many of its plugins are equivalents to corresponding CKEditor plugins that are merely executed in different context. So, we not just reuse functionality of the CKEditor plugin? And here is what we end up with.

Bootstrap Editor and plugins

The design is good, but it does not take into account some nuances. First of all, different plugins can be loaded at different time. This is not about loading priority, it's more about the loading is asynchronous. Well, so we need a "headquarters" - some plugin manager where every addon can register upon loading and declare its capabilities. Any other addon that needs some third-party functionality can refer to this manager and "ask" whether such function is available. And it does not have to be upon loading only: the check can be held until the first display if the dialog with external functionality.

So the resulting scheme is:
Plugins manager

From the point of view of a Bootstrap Editor user, everything looks as if Bootstrap Editor supports CKEditor plugins. It does, but technically it is CKEditor plugins that should support Bootstrap Editor. With JS+ plugins this is it.

A few words on modular architecture

The major question you may ask is: can this architecture lead to dependency hell? What are the chances that developers using JS+ extensions will end up fighting endless dependencies of one plugin on another one?
Answer: no, there will be np such problems. The modular architecture resides inside the plugins. From outside, there are only interfaces for optional usage of the functionality by other plugins.
In other words, every addon carries its own instances of libraries it needs (they are pretty lightweight), and everything it gots externally is completely optional. Simply add a plugin to CKEditor or TinyMCE and it instantly starts to work and share its functionality with other applications.

Typical modular system:
Typical modular system
JS+ modular system:
JS+ modular system