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
