New event to hide/show all elements

[Indigo744]

Hiding and showing slices is available through a click on legend element (if legend.area.hideElemsOnClick.enabled if set to true).
I needed a function to hide/show all elements at once (and it seems related to #26, no workaround would be needed).

This patch implements a new event call hideAllElems which accept a boolean parameter hide. It allows to show/hide all elements at once. I'm up to debate for this event name, but I think it's the most simple and similar to hideElemsOnClick.

Also, it corrects an issue in the update event where the Reset hidden map elements parts would never do its job because el.hidden is actually never set (no error was thrown since we check for its existence, but it didn't do anything).

[Indigo744]

Wow, I miss an issue... This should be set to false of course...

$self.trigger("hideAllElems", false);

My bad...

[neveldo]

Hello,

Thank you for the PR !

I think $("[data-type='elem']").each() should be replaced by $("[data-type='elem']", $(this)).each(), otherwise, in case there are more than one map on a page, all legends items of all the maps will be hidden when the event is triggered on a specific map container.

Regarding the name, we could keep 'hideElemsOnClick', or maybe something like that : 'toggleLegendElemsState' will be more explicit (but a bit too long ?)

[Indigo744]

Right! Good catch :-)
I made a commit to correct this.

Regarding the name, the thing is that this event hide or show all the elements. This is not a toggle: elements already hidden will stay hidden for instance (or already shown will stay shown).
I'm not really fond of the name either, to be honest. However, I can't think of another name...

[neveldo]

Thank for the fix :) What do you think about "updateLegendElemsState" instead ? Otherwise, we will keep 'hideElemsOnClick' for the event name.

[Indigo744]

updateLegendElemsState would be OK.

However, the more I think of it, the more I wonder if we shouldn't integrate this inside the existing update event, in the opt object parameter for instance: opt.setLegendElemsState (value shown|hidden). What do you think ?

[neveldo]

I didn't thought about this alternative, but I agree with you, I think that the 'update' event is an appropriate place ... and no more headhache to choose the event name :) Could you update the PR to move the code within the 'update' event as you have explained ?

I think I will clean the "update" event signature later (and make it backward compatible with the current signature) in order to have a single object as parameter and get something like that :

var options = {
  'mapOptions' : {},
  'replace' : true/false // whether mapsOptions should entirely replace current map options, or just extend it,
  'newPlots' : {},
  'newLinks' : {},
  'deletedPlots: [],
  'deletedLinks' : [],
  'setLegendElemsState' => '...'
  'afterUpdate' => ...,
  'animDuration' : ...
};
$(".container").trigger('update', [options]);

[Indigo744]

Here is the commit. What do you think?

[Indigo744]

Regarding the cleaning of update event, I think you shouldn't be backward compatible.
With a new major release with some breaking change, you can avoid using this kind of legacy code that will only bloat the code.

[neveldo]

It's ok for me, approved !