Edit Widget Slow to Load

[VictoriaC]

Real-world Problem

In search and rescue, we need the field users to be able to do basic mapping of their search areas without assistance from GIS Specialists. This means our maps often have many reference layers related to all possible disasters (flood models, hurricane forecast, earthquake Shakemap).

Technical Problem

To do this we provided the “Intel Manager” which was originally based on Web App Builder but are transitioning to Experience Builder. The Edit widget in Experience Builder leverages the Map SDK for JavaScript widget, and the issue described below can be observed across the different apps who depend on this component (Map Viewer, Experience Builder, Instant Apps).

The Editor widget is very slow to load the first time it opens (sometimes 5 seconds, sometimes 1-2 minutes!). By inspecting the error and network console, we believe this delay may be caused by the way the JS SDK loads all layers in the map, even when they are not initially visible, and that the Editor waits for all the layers to be loaded to check for the valid editable layers.

Here is our Sandbox application for testing, see the reproduction steps here: https://github.com/pjdohertygis/SARCOP/issues/450. 

Only a few layers are editable and have feature templates, while most of the layers in the map are for reference only to support the different editing and analysis workflows.

Possible Solutions

We’ve had recommendations from Esri in the past to hide/turn off layers in the map that are only needed by users on demand to improve loading performance. Based on the current use case, it appears this workaround is not applicable. While we are attempting to reduce the number of layers in our map, we feel the performance for loading layers in the map and the Editor widget should be optimized.

We feel there should be logical checks when loading layers in maps and apps, so that data is only loaded when necessary. Furthermore, if data cannot be loaded because it is not accessible for any reason, it should not excessively slow down or prevent the loading of the rest of the map/app.

While it seems this may need to be addressed on the JS SDK, perhaps there could be an app level check. For example, provide an option to “bypass” any layers not included in the Edit widget configuration in Experience Builder?

@PaulDoherty3 @JaredDoke @ChristopherPierson1 

[Tristan_Morrison]

Hi Victoria, thank you very much for reporting this issue. The very long startup time you are seeing with the Editor widget is due to a bug introduced in version 4.32, when we added support for shared editing templates.

In general, what you describe as your expectation is indeed the way it is supposed to work. In the Maps SDK for JavaScript, when a layer is added to a map but is not initially visible, it is not loaded. It remains unloaded unless and until it becomes visible in the view. (Note that, in prior versions, all layers in a map were loaded, regardless of their visibility. The change to avoid loading layers unless and until they are visible was made in version 4.31.) Moreover, the Editor widget does not load layers by itself. It will only allow editing features in layers that have been loaded and are editable by the current user.

The long startup times you are experiencing — and the large number of requests you are seeing in the network console — are not for loading layers; rather, they are loading feature services. (You can tell this because their URLs end in /FeatureServer, not /FeatureServer/<layer_id>.) This request was added in version 4.32 as part of our support for shared templates because it is necessary in order to determine whether a service supports shared templates. This request should only be sent for the feature services to which the visible, editable layers in the map belong. However, it appears that, inadvertently, Editor is loading the feature service information for all layers in the view — even layers that are not visible, not editable, or not loaded.

I have logged this issue, and we will work on fixing it in our next release.

[LindsayRaabe_FPCWA]

Glad someone has found this and reported it - I was about to do so as it's driving me nuts! Not just the slow loading, but having to wait for it every time I make a change to a problem Edit widget and try to test the updated App with a different account with lower role privileges. 

[JasonWarzinik1]

Please, big Upvote from me for a quick fix ESRI.  Editing is a core function for what we do and needs to be fast! 

[ericsamson_tract]

Hey All,

I reported this a month ago, they stated that it was fixed but it was not. Here are the IDs:

ENH-000175894: Allow the Edit widget of Experience Builder application to load faster.

BUG-000177171: The Edit widget queries all layers in the web map, even though it is configured to only function with one editable layer, and does not load until all queries are complete.

Both of these are "implemented" but it was not actually fixed in the new version. The new edit widget within experience builder still queries every single layer on the map. This also results in more memory consumed by the application, significantly slowing it down. This should be a top priority fix.

I plan on opening a new bug tomorrow, but saw this here and wanted to contribute

[SteveWing]

I've had the same issue which I have logged and my case has been attached to ENH-00175894. However I'm also slightly concerned that the state of this is closed and status is implemented.

This must be a common problem for a lot of users where you have a few edit layers and a larger number of reference layers.

The optimisation suggestions I have also had around reducing the number of layers and/or layer visibility aren't really relevant. While it is good practice to not get excessive with the number of layers I don't want the overhead of multiple applications for different scenarios when the actual number of edit layers is very small.

For reference I also built an application with Web AppBuilder using the same reference and edit layers and that doesn't exhibit any of the latency on load. But clearly not the way to go with its impending retirement.

I would be keen to know that this on the list for the next release as its critical functionality.

[Adam_Bourque]

We are having the same issues Steve, our case number is #03969602 . hope to hear more about this, seems to be both on the new map viewer and experience builder. 

Update: Field maps works fine, so does classic web map (even though we don't use that). Did not try classic web app like you did but expect the same.

[SteveWing]

In an attempt to establish whether this is going to get fixed I've had this response from ESRI UK :

Regarding your question about whether this will be addressed in an upcoming release: since the enhancement is currently marked as implemented/closed, it’s unlikely to be revisited unless there’s clear user demand.

Doesn't sound like it is going to get fixed anytime soon.

[Adam_Bourque]

I'm very shocked that there are not more users reporting this? Maybe people are thinking it's other factors causing it, but it's a very noticeable difference over the past couple of months. We help manage lots of utilities and many are distressed from the loading speeds, let alone us on the GIS end of things trying to minimize layers by default etc.. while it actually does not help the browser CPU at all or minimally. 

[SteveWing]

Quite agree. This is not how this was working before the last update. To be told this should be considered as an enhancement and to post in the forums to get it upvoted is ridiculous. It is a bug and should be addressed as such.