weak event system

[yangwen]

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.

[RobertScheitlin__GISP]

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.

[ThomasSolow]

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);

[yangwen]

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..

[RobertScheitlin__GISP]

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

YCabon-esristaff‌

[ThomasSolow]

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.

[yangwen]

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.

[EvonFranklin]

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

[ReneRubalcava]

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?

[yangwen]

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.