Datatable select event propagation issue/bug (not bubbling as expected)

PajamaJam

Our application leverages delegated event listeners attached to the document element to handle a few datatable scenarios. Unfortunately, datatable events such as "select", "deselect" and "user-select" do not propagate beyond the table element.

Test page: http://live.datatables.net/zebetipa/1/edit?js,console,output

Is this behavior by design or a bug? It feels like a bug given that other datatable events such as "draw", "processing", "init", etc. all bubble beyond the table element (as I would expect).

For what it's worth, I understand that I can attach event listeners to the table instead of the document to work around the problem, but I'd like to avoid this due to the way our app works (destroying/recreating tables on the client).

allan

Its not a bug. The select event should not bubble. You are correct that the core events do bubble, but the events from the extensions typically do not.

Thanks for highlighting this though - I need to update the documentation to show what does bubble and what doesn't.

The reason for some events not bubbling is performance - it takes time to propagate up the DOM.

Allan

PajamaJam

Hi Allan. Very much appreciate the quick reply.

The decision to have some events propagate but not others presents two issues: 1) it breaks the way event bubbling works by default and 2) the implementation doesn't align with the rational.

Here's my $0.02...

Event propagation should work the way event propagation works by default: all events bubble up through the DOM.

If performance is the rational for preventing some events from bubbling but not others, I would expect the performance impact difference between the events in question to be substantial. For example, while "scroll" and "mouseover" events are high-volume events that may impact performance if managed improperly, events like "click" and "keyup" are not. While it could be argued that "scroll" and "mouseover" events should therefore not propagate to reduce the likelihood of them impacting performance, in reality these events propagate the same way the low-volume "click" and "keyup" events do. The benefit is that the model works consistently and provides the greatest flexibility. The drawback is that it's up to developers to manage events properly.

Consider the datatable events I listed in my initial message: "draw", "processing", "init", "select", "deselect" and "user-select". None of these events are high-volume events, yet only half of them are allowed to propagate beyond the table element. It's hard to imagine how allowing the "draw" event to propagate up the DOM poses less of a performance risk than the "user-select" event, yet that's how things work.

For what it's worth, I appreciate the focus on keeping datatables performant. I just don't think the rational for limiting how some events propagate makes sense or that the benefits outweigh the drawbacks. In my scenario, the decision to prevent some events from propagating as expected is creating a performance issue, not solving one. It's not the end of the world since I can work around it, but it does mean additional code to write and maintain that otherwise wouldn't be necessary.

Whew.

Thanks for all the great work and the time spent on these forums helping people out. All very much appreciated!

allan

Thanks for the feedback! Much appreciated.

And I agree - I think the select event and similar should bubble and that it would be useful. I've added that to my bug (/feature) list.

Moreover, in general I know I need to go over all of the events and sort the propagation of them out. The events in DataTables internally are somewhat messy (frankly). With the next major update I want to sort them out and provide an API for the extensions so they can all use the same structure (at the moment, each implements their own - even if it is basically a call to jQuery).

In the short term, if you do want it to propagate, you could change the tigglerHandler call here to just trigger.

Regards,
Allan

PajamaJam

That all makes sense to me, Allan.

Thanks again for the prompt and courteous feedback. I know contributing to these forums take time and patience on your end, both of which are very much appreciated.

Best to you, and keep up the great work.

allan

Its a pleasure when getting great feedback like this - thanks!

Allan

allan

A quick update on this one - the change discussed here will be in the next release of Editor. This is the change.

Allan