Map rendering glitch/bug in AGOL EXB

04-25-2023 07:24 AM
New Contributor III

I've built an experience in which a selection made on the first map causes the layers in the second map to be filtered.

In general it works well, but in some cases the second map fails to re-render all the layers after their filters have been applied, so the graphics for records that have been "filtered out" can tend to remain visible on one or two of the layers, until the map is zoomed in or out or otherwise forced to redraw.

It seems like the sensible thing would be for all filtering and selection logic to be applied before zooming and panning actions, with a final redraw of everything just for good measure. I get the feeling that the order of execution is to some degree influenced by the order in which the actions are listed, but I'm not sure whether it's simple as the first item in the list being executed first (or last), or if there is already some kind of effort in place to reprioritise the different kinds of actions. So I feel like I'm just winging it to get it to work!

I switched one of the misbehaving layers from a "framework-based filter" to a "map-based filter", and added a selection action on the other one, and have played around with the order in which the map actions are listed. And thankfully that seems to force enough redraws to end up with a map that is rendered correctly.

Is this a known "vulnerability" of experience builder, and if so are there established practices for handling it (e.g. a recommended order in which to list the different actions, so that they "agree" with the map rendering)? If not, could it please be attended to fairly urgently, as it could threaten to make such apps unpublishable!

Tags (4)
2 Replies
Esri Regular Contributor

Hi @AndrewVentham - thanks for bringing up what you've experienced. When you mentioned 'filter', does that mean you have a filter widget configured with the capability of applying on load? We have some similar feedback but based on the later description, I doubt they are the same issue.


Since it could be quite difficult to reproduce, I suggest that you reach out to Esri Support and the support analyst can help you build a reproducible environment.

0 Kudos
New Contributor III

Hi @TonghuiMing - many thanks for getting back to me; I've logged a call now.

I have added a filter widget to the first map, but removing it doesn't seem to affect the interactions with the second map. What I was referring to above was that when I select a feature on the first map, it is configured to carry out a series of actions on the second map, to zoom it in around the selected feature, and filter several other contextual layers to show only the features that share a unique ID with that selected feature. I've attached a screenshot of the series of actions that are currently configured against the first map.
The second map is in a separate view from the first map, so these actions are effectively "queued" until that other view is selected and re-rendered. But then when the second map is rendered, the unfiltered data is requested and rendered before or even while the filtering and zooming actions are being applied. Ideally this wouldn't be happening at all, and instead all the changes that need to be made to the second map's extent and layer where clauses would be applied before (rather than during or after) it is rendered.

0 Kudos