Please trigger events on the dom element additionally to callbacks

[BernhardBaumrock]

Hi Oli, thx for the awesome library. I've been working with it now for quite some time and there's only one thing left that really causes me headache: Events and callbacks.

The problem

I'm developing a module for the CMS https://processwire.com/ - my module will help closing the link between the data (cms) and the presentation (tabulator). It will have helpers for ajax calls etc... So far, so good. The problems arise when it comes to multiple developers providing multiple plugins for extendes features.

In case of formatters there is already the concept of extending modules: http://tabulator.info/docs/4.9/modules#extend; That is great, but only for modules and not for events!

Imagine me having a standard grid setup that ships with my module: A grid, that has headerfilter enabled by default and uses a predefined ajax endpoint so that I can manage data via my CMS on the PHP side.

Now imagine developer BOB wanting to add a great feature: When someone clicks on a row, he wants to show an alert "Hi, this is Bob, you clicked row ...". Right now - if I'm not missing anything - it's the only way to define that in the initial table setup:

var table = new Tabulator("#example-table", {
    ...
    rowClick:function(e, row){
        alert("Hi, this is Bob, you clicked row " + row.getData().id + " Clicked!!!!");
    },
});

Sounds simple enough? Yes and no... Now imagine me as the dev of my module wanting to add some magic when a user clicks on a row on any of my "rockgrids"... where would I define this callback? Or imagine developer John wanting to also show an alert "Hi, this is John, you really clicked on row...". And Bob wants to ship his feature as a module in a separate folder and John wants this as well.

That's simply not possible.

Proposed solution

It would be really easy if tabulator exposed events on the dom element. Then me, Bob and John could listen for those events and simply fire our alerts without modifying (damaging) the initial table setup! Bob could do:

table.on('rowClick', function(e, row) {
  alert('Hi, this is Bob, you clicked row ...');
});

And John could simply do the same:

table.on('rowClick', function(e, row) {
  alert('Hi, this is John, you really clicked row ...');
});

Another example could be some kind of info-screen:

table.on('rowSelectionChanged', function ...);
table.on('dataFiltered', function ...);

Those plugins could be loaded depending on a setting on the CMS side (eg via checkboxes "show header filter, show filter info, show column sums") and split into several separate js files. Right now I'd have to place all this logic into the initial table setup and that's a no-go.

I hope that my request is clear - I think that should be quite a little effort to trigger every callback event on the dom element but it can have huge benefits for developers!

[olifolkerd]

Hey @BernhardBaumrock

I think this is a great idea! i will look at adding it to the 5.0 release.

Cheers

Oli :)

[BernhardBaumrock]

Thx @olifolkerd really glad to hear that! Should I close this issue or leave it open?

[olifolkerd]

Leave it open, I will close it shortly once I have finished the upgrades to the event system that this concers.

Cheers

Oli

[olifolkerd]

Hey @BernhardBaumrock

These updates are now available on the 5.0-alpha release. Checkout the Release Notes for more details.

Cheers

Oli :)

[BernhardBaumrock]

@olifolkerd THIS IS GREAT!! :) Thank you!

Just a quick idea without a real world need yet, but coming from the https://processwire.com/ CMS which has a great concept of hooks (https://processwire.com/docs/modules/hooks/) - which is very similar to the new events feature - there are two more things we can do with hooks:

1. We can define a hook priority to tell processwire which hook runs earlier and which later (https://processwire.com/docs/modules/hooks/#hook-priority)
2. We can prevent all following hooks from being triggered: https://processwire.com/docs/modules/hooks/#how-can-my-hook-replace-another-method-entirely

Not sure if point 2 is already possible using .off() ? But now that everything is fresh in your head it might be worth thinking about these two concepts as well :)