improve loading speed of application

[allisonmuise]

The app is slow to load, and then slow to load each map. LEt's look for improvements in efficiency for next release.

[CTLocalGovTeam]

@allisonmuise ,

We are working on this enhancement and will keep you updated.

--Pratik Gohil

[CTLocalGovTeam]

@allisonmuise

Are you experiencing that the app is slow to load under certain circumstances/data/maps/layers or it is always slow to load?

One of the areas where the app does a lot of work while loading up is processing all the webmaps. It goes through each webmap, each layer in the webmap to see if its editable, has popups enabled, has editable fields, and so on. All this processing is done up front and only maps/layers that work are displayed in the app. This is done using the "createmap" function which initializes the map in background for each webmapid. Due to this, performance is inversely proportional to number of webmaps.

We went the "createmap" route as it provides all properties we need to check in one go for a webmap. However, it also adds some overhead. We did explore an alternative to using "createmap", by executing only the queries that are necessary, and provided significant increase in performance. However, this requires a rewrite of the map-list-panel component of the app and is high LOE and high risk.

Reporter too, uses the same map-list-panel component, do you notice performance issues in reporter too?

[allisonmuise]

ok, Let's leave this for now and revisit when we need to move to the 4.x API

[topowright-zz]

This is an issue that we are still seeing. We see this whenever we have more than a few hundred features in a feature service. @CTLocalGovTeam and @aparveen can we take a look at these issues for the coming release?

[aparveen]

@topowright, we fixed the performance issue on Select All functionality #291 only this release, we deferred this issue for next generation 4.x app, because this will require us to rewrite a component in the Manager, which involves high level of effort and risk, also JS API 3.x will go to mature support in 2020, so taking such a large project for a platform which will be in mature support only within couple of years is our another concern. So we are thinking about addressing this issue when we move to JS API 4.x.