topic Re: weak event system in ArcGIS JavaScript Maps SDK Questions

weak event system

yangwen — Sun, 12 Dec 2021 16:15:55 GMT

I'm new to the arcGis JS API.

I'm trying to implement some fairly trivial and fundamental logic and came to the realization that there is a rather weak eventing system in the API. I want to confirm my findings here.

In trying to implement a callback to trigger upon a zoom action, research led me to eventually find a sample code where extent changes are detected via a watcher on a MapView property.

From this example: ArcGIS API for JavaScript Sandbox

watchUtils.whenTrue(view, "stationary", function() {

// Get the new extent of the view only when view is stationary.
 if (view.extent) {
   
}

})

Really? An event as significant as zoom, drag are all inferred by watching the stationary flag?

This article seems to confirm as such. Disable all zooming on the view | ArcGIS API for JavaScript 4.5

Or are there other APIs that I have missed? Thanks.

Re: weak event system

RobertScheitlin__GISP — Tue, 12 Dec 2017 19:17:43 GMT

Yang,

You are not missing anything. The 4.x api uses very few events, but properties can be watched so it is no big deal. I initially had your same reaction but now that I am use to using watchUtils it is second nature now to just use properties for things that use to have events in 3.x.

Re: weak event system

ThomasSolow — Tue, 12 Dec 2017 19:41:46 GMT

You can watch any property that is an accessor property. Most classes in the 4.XX JS API inherit from accessor (Accessor | API Reference | ArcGIS API for JavaScript 4.5 ), which allows properties to be watched.

Drag is different as it is a mouse event that can registered on a view.

https://codepen.io/solowt/pen/opNaXo?editors=1000

esri/core/watchUtils is useful for more complex stuff than just watching for a property change.

Really? An event as significant as zoom, drag are all inferred by watching the stationary flag?

I'm not sure what you mean by this. If I wanted to watch zoom for changes I would use view.watch("zoom", callback);

Re: weak event system

yangwen — Tue, 12 Dec 2017 19:50:37 GMT

Thomas, Your point about Drag being a mouse event, and the second link from my original post highlights the short coming of this event-less approach.

Drag can also be accomplished via directional button on the keyboard, as well as touch events. So just like the zoom example I linked above, in order to catch these higher level events, you must implement a verbose & imperative set of event handlers to catch the lower level events only to infer the intent of a higher level event.

Using the watcher on the zoom property is inferring that zoom had occurred, but since there is no event pipeline for zoom, we have have to utilize this anti-pattern to implement basic event based programming..

Re: weak event system

RobertScheitlin__GISP — Tue, 12 Dec 2017 20:00:26 GMT

Maybe we can get Yann to chime in on this discussion.

YCabon-esristaff‌

Re: weak event system

ThomasSolow — Tue, 12 Dec 2017 21:17:15 GMT

Okay, I think I understand your point.

You're interested in a zoom event, but you'd like to intercept the event at a point before the zoom has actually occurred. You're commenting that the only way to do this is to watch for "double-click," "mouse-wheel," "+", and "-," and add a callback to each of these events separately, and this is inconvenient.

That's a really good point, I can see how it would be helpful to allow a user to listen for a "zoom" event, inspect the event object, see what user input had triggered it, and decide on what to do from there.

Unfortunately I don't think there's a built-in way to do this.

Re: weak event system

ReneRubalcava — Tue, 12 Dec 2017 21:18:25 GMT

Do you have a sample or scenario of what it is you're trying to accomplish?

The equivalent of a zoom event in 4x is the watching of the zoom property to change. But now, you have the option of either doing something during the zoom transition or waiting until the end, which is what the view.stationary property would let you do. When you say Drag, do you mean Pan?

Re: weak event system

yangwen — Tue, 12 Dec 2017 21:26:24 GMT

Yes you've articulated my concern. I'm using the term first class events as a means to describe events that are cardinal to the mapping experience. Basic fundamental actions that 99% of map instances would enable for the user. For these events, my opinion is the API should elevate their prominence such that developers can interact with them conveniently.

Re: weak event system

yangwen — Tue, 12 Dec 2017 21:30:43 GMT

Watching the stationary or zoom flags are acceptable solutions for my use case. I need to take some action around the action of zooming. Doesn't matter it it's before or after zoom.

The discussion now is really more academic. I don't see the benefit of this event-less approach, other than less development for the esri team by just exposing the view instance's state properties.

Yes when I say drag I actually meant the act of panning, which can occur via multiple ways. There should be pan & zoom events that gets triggered regardless of how it's actually done.

Re: weak event system

EvonFranklin — Tue, 12 Dec 2017 22:08:57 GMT

I definitely think it would be worth it to have a different event listening system in place to accommodate this.

Re: weak event system

YannCabon — Sat, 11 Dec 2021 12:50:11 GMT

Hi Yang,

You don't really need to watch both properties. You can just watch for `stationary` and keep some info around:

function whenZoomChange(view, callback) {
  let oldScale;

  view.watch('stationary', (isStationary) => {
    if (!isStationary) {
      oldScale = view.scale;
    }
    else {
      if (oldScale !== view.scale) {
        callback();
      }
    }
  });
});
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

On the academic discussion, we made the choice to favor watching properties over events as it gives more control over events.

- Events don't give us access to the current state of the emitter. If your code gets a mapview object and it's already zooming, without a property expressing that you cannot know it, while `stationary` gives out this information.

- Having events AND properties just blows up the API with redundant information.

Re: weak event system

EvonFranklin — Tue, 12 Dec 2017 22:49:09 GMT

Understood, that would give you guys more control over the API system then.