nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Najděte více příspěvků označených jako

Accepted answers

All comments

EvonFranklin

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

YannCabon

Hi Yang,

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

<SPAN class="keyword token">function</SPAN> <SPAN class="token function">whenZoomChange</SPAN><SPAN class="punctuation token">(</SPAN>view<SPAN class="punctuation token">,</SPAN> callback<SPAN class="punctuation token">)</SPAN> <SPAN class="punctuation token">{</SPAN>
&nbsp; <SPAN class="keyword token">let</SPAN> oldScale<SPAN class="punctuation token">;</SPAN>

&nbsp; view<SPAN class="punctuation token">.</SPAN><SPAN class="token function">watch</SPAN><SPAN class="punctuation token">(</SPAN><SPAN class="string token">'stationary'</SPAN><SPAN class="punctuation token">,</SPAN> <SPAN class="punctuation token">(</SPAN>isStationary<SPAN class="punctuation token">)</SPAN> <SPAN class="operator token">=</SPAN><SPAN class="operator token">></SPAN> <SPAN class="punctuation token">{</SPAN>
&nbsp;&nbsp;&nbsp; <SPAN class="keyword token">if</SPAN> <SPAN class="punctuation token">(</SPAN><SPAN class="operator token">!</SPAN>isStationary<SPAN class="punctuation token">)</SPAN> <SPAN class="punctuation token">{</SPAN>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; oldScale <SPAN class="operator token">=</SPAN> view<SPAN class="punctuation token">.</SPAN>scale<SPAN class="punctuation token">;</SPAN>
&nbsp;&nbsp;&nbsp; <SPAN class="punctuation token">}</SPAN>
&nbsp;&nbsp;&nbsp; <SPAN class="keyword token">else</SPAN> <SPAN class="punctuation token">{</SPAN>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <SPAN class="keyword token">if</SPAN> <SPAN class="punctuation token">(</SPAN>oldScale <SPAN class="operator token">!==</SPAN> view<SPAN class="punctuation token">.</SPAN>scale<SPAN class="punctuation token">)</SPAN> <SPAN class="punctuation token">{</SPAN>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <SPAN class="token function">callback</SPAN><SPAN class="punctuation token">(</SPAN><SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">;</SPAN>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <SPAN class="punctuation token">}</SPAN>
&nbsp;&nbsp;&nbsp; <SPAN class="punctuation token">}</SPAN>
&nbsp; <SPAN class="punctuation token">}</SPAN><SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">;</SPAN>
<SPAN class="punctuation token">}</SPAN><SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">;</SPAN>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍<SPAN class="line-numbers-rows"><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN></SPAN>

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.

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.

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.

RRubalcava

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?

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.

rscheitlin

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

YCabon-esristaff‌

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

ThomasSolow

You can watch any property that is an accessor property. Most classes in the 4.xyz 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);

rscheitlin

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.

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.