Expose enabled and active states on interaction handlers

[averas]

Fixes #2173.

While working on this I found this anomaly: #2237, please let me know if you think that one should be tracked down and addressed as part of this PR.

[lucaswoj]

Are you using active anywhere?

[averas]

Some of the handlers, such as BoxZoomHandler, already had a public (no leading underscore), albeit non-documented, active property on them. I just took the opportunity to make the code, behaviour and documentation consistent with the new enabled property.

[lucaswoj]

Got it! Thanks 😄

[lucaswoj]

Looks great! Let's give @bhousel a chance to look this over and then we can merge it.

[averas]

Btw. @lucaswoj. There was a discussion on #2085 related to this. Obviously now that the handler has knowledge of whether it in fact is enabled or not the fallback of always disabling a handler before enabling it could be removed in favour of simply making enable() and disable() noops if the desired state is already present.

Let me know if you prefer this refactoring instead of the current fallback behaviour.

[bhousel]

A problem with the previous code, but active should probably be an accessor not a public property. For example in the dragpan handler, somebody could start panning, and if code elsewhere sets that public active=false, the handler will never run the things in _onUp().

It's necessary for some handlers to know which other handlers are active, but no code outside the handler should be allowed to modify that state.

[averas]

@bhousel That's true, and obviously an inherent problem with mutable properties.

With the same reasoning I take it you are for keeping the disable() fallback call in the enable() functions, rather than making them noops based on current state (as outlined in my previous comment). Otherwise you may run into the same problem with the enable property, i.e. the property being mutated directly from outside bringing the handler into a degenerative state. With the disable() call present the handler will be able to recover from such a state.

[lucaswoj]

Next Steps

• prefix _active and _enabled with underscores to mark them as private properties
• add and document public isActive and isEnabled accessor methods
• add a brief documentation note about the difference between "active" and "enabled"

Anything else we should add to this list @bhousel?

[averas]

@lucaswoj The reason I went down the path of public properties in favour of accessors was @mourner's decision in #2173. Of course we can change that in accordance with your outline. Your suggested changes will be breaking, but I highly doubt anybody is currently using the non-documented active property.

In regards to your TODO list I'd love a comment about whether to keep the fallback disable() in the enable() functions or whether we should make enable() and disable() noops if already in the desired state. If the properties are made private as you suggest there should be no risk in relying on state the handler property reflects.

[lucaswoj]

The reason I went down the path of public properties in favour of accessors was @mourner's decision in #2173. Of course we can change that in accordance with your outline. Your suggested changes will be breaking, but I highly doubt anybody is currently using the non-documented active property.

My outline isn't cannon. I'm always open to discussion about the right way to do things. 😄

I'm not afraid of breaking changes to undocumented properties, as long as we're changing it to something we're comfortable documenting and supporting in the long haul. (Ah, the perks of being < 1.0.0 in semver).

In regards to your TODO list I'd love a comment about whether to keep the fallback disable() in the enable() functions or whether we should make enable() and disable() noops if already in the desired state. If the properties are made private as you suggest there should be no risk in relying on state the handler property reflects.

I don't have a strong preference. Whatever you think best.

[averas]

@lucaswoj np. I'll provide a new set of commits...

[averas]

Changes made according to @lucaswoj outline.

👀 @lucaswoj @bhousel

[lucaswoj]

Thank you @averas! I'm going to test all the interaction handlers by hand and then I feel good about 🚢 this!

• KeyboardHandler
• DragPanHandler
• TouchZoomRotateHandler
• ScrollZoomHandler
• DoubleClickZoomHandler
• DragRotateHandler
• BoxZoomHandler

Edit: Everything here looks great! (Except #2237 😬 but that's an orthogonal problem)

[averas]

@lucaswoj Great! I made some additional comments on #2237 on that issue.

[lucaswoj]

Merged in 494e2bb! Thanks again @averas! 🚢 🚀