Plugins for Mapael?

[Indigo744]

Hello,

I was thinking and I wondered if we should implement something to easily allow plugins.

For instance, the plots/links selection of #40 would be a great fit for a plugin (since not everyone will want this).

Also, maybe the Zoom feature could take the form of a plugin? It's already an opt-in (disabled by default). It represents almost 20% of the code base, which is not used at all by some people.

I'm just thinking out loud. What do you think?

Of course, such major changes would be for version 3.0 ;-)

---

Here is a list of possible extensions idea:

Non-existing features:

1. Support GeoJSON format #330
2. Drill down map #183
3. Plot selection with rectangle #40
4. Text overlapping check #276

Existing features (that can be extracted as an extension):

1. Zoom
2. Tooltips
3. Legends
4. Links between plots

[neveldo]

@Indigo744 ,

I think it could be indeed a great improvement because, as you pointed out, some of the feature of Mapael have a very sparse use and represent a lot of code. (I'm also thinking about the "link" feature for instance.

However, I'm not familiar with the building of such a plugins mechanim for a JS library. Are you ? Maybe we could dive into some other lib' to learn how it's done. I'm think about Datatable for instance, in which they have a plugin mechanism that is easy to work with (from a user point of view). For instance, there is a plugin that provide a "reponsive" feature for the tables.

[neveldo]

Another question to answer is : should we move some of the existing features of Mapael into plugins (and, as you said, it will lead to a new major version), or should we use the plugin mechanism only for the next features that will be added to the library ?

[Indigo744]

Datatable is a great jQuery plugin, it's a good idea to check there.

I've looked into it, and I came to the conclusion that there exists to types of "datatable plugins":

1. Extensions: they extends the functionality of Datatable with new features (quite big) such as editing or responsive layout. They are made (and owned) by the Datatable developers. There doesn't seems to be a way to submit or easily develop an extension by someone externally. There are no documentation available.
2. Plugins: they are smaller plugins that provide smaller features such as custom sorting or pagination. They are made by a large number of different people, and new plugins can be easily submitted to be featured on the DT website. Documentation is available.

So, to sum up, extensions are internal and plugins are external.

In our case, I guess the Zoom feature would be an extension, and the additional maps are like plugins.

[Indigo744]

From a technical point of view, the extensions uses the following approach:

1. They listen to Datatable events for initialization Example with colReorder extension:

   // Attach a listener to the document which listens for DataTables initialisation
   // events so we can automatically initialise
   $(document).on( 'preInit.dt.colReorder', function (e, settings) {
   }

2. They register new events/functions with a call to api.register:

   // API augmentation
   $.fn.dataTable.Api.register( 'colReorder.reset()', function () {
   return this.iterator( 'table', function ( ctx ) {
       ctx._colReorder.fnReset();
   } );
   } );

[neveldo]

Hello @Indigo744 , thanks for having dove into Datatable extensions mechanims and for the explanations ! This separation between extensions for big features and plugins for smaller one based on events listenning sounds interesting and logical.

You are right, the maps are already Mapael plugins in a way. If we go futher in this way for mapael, I think it should provide clear "extension" points through the events for the plugins (and provide some plugins samples). However, I don't see among the actual feature which ones could be moved to some plugins for now.

From my point of view, at least the zoom feature and the links feature could be moved to extensions. We could still of course keep them into the base package, but the users would have the choice to load only the base plugin jquery.mapael.js or both jquery.mapael.js and jquery.mapael.zoom.js for instance. However, I have no idea at all of the percentage of usage of the zoom features. Maybe 95% of the users enable it on their maps, hence moving it into an extension could add some complexity for no gain. Maybe some queries to Google could help us answer this, for instance : https://www.google.fr/search?q="+and+Mapael"

[Indigo744]

I've updated my first post to reflect a list of possible extensions.

If we don't want to add more complexity to the user, we could provide a tool on your website that generates the Mapael library with all needed extensions added (like is doing Datatable or jQuery UI, but less complicated)

[neveldo]

Hi @Indigo744 ,

Thanks for the work !

For my part, the more I think about it, the more I ask myself if mapael has reach the critical point that implies a separation of the code into plugins or not.

I think that providing a tool to generate the mapael package depending on the choosen plugins / extensions still imply some complexity as it will lead the user to think in advance about what he will need in order to build his map, and maybe being forced to build a new package if an extension was missing.

However, I agree with you on the fact that some of the current available feature are barely used. For my part, I mainly think about the links feature for now. However I think this is not the case for the tooltips or zoom for instance. I'm wondering if the base package doesn't provide zoom, tooltips and legends features, It will become only a sort a proxy for raphael.js.

Could we enumerate the pro and the cons of having a plugin mechanism vs the current ? Didn't think a lot about it, but for now I see :

Plugin pros :

• Allow to lighten the global pages weight as only the required code is downloaded, improve performances. (however is mapael weight really an issue today ? We are talking about ~30KB for the minified version, that drops to less that 10KB when transferred in gzip. For comparison, DataTable base package weight is more than 80KB.)

• Ease the build of external plugins from other users to add new custom features to Mapael

Plugin cons :

• Add complexity for the users (but it can be reduced in some way by adding an online package builder as you mentioned)
• Add complexity into the library itself

[Indigo744]

Add complexity into the library itself I do not agree. If we define a good architecture, it may even be less complex!

Right now, we have a single JS file with more than 2500 lines, with lots and lots of different functions one after another. I must admit that I get lost quite a lot in this file... And potential contributor may be reluctant to dive into this...

I think having extension could help bring some separation of concerns between some vastly different features.

[neveldo]

Hello @Indigo744 ,

After some thoughts on this topic, I think you are right on the point that the current code is a huge set of functions, and sometimes maybe some useless spaghetti code.

As you said, some separation of concerns could be welcome to enhance the overall architecture of the plugin.

We could also take a look at how jQuery (for instance) is built ( https://github.com/jquery/jquery ). The code is separated into small pieces and t's seems they lie on grunt to build the final package.