"Reselect Task" in edit mode zooms out very far

[mvexel]

Let me just describe this by example:

Load this task while in edit mode

Click Re-Select Task and watch Rapid zoom way out:

[CollinBeczak]

The button appears to work as expected in most challenges, I'm assuming that challenge is having issues because it has different default zoom levels:

[mvexel]

Regardless of what zoomlevel is set, when the user asks to reselect a task in edit mode it should zoom and pan so that the element involved is centered and fills the editor viewport with a small buffer.

[CollinBeczak]

This seems to only happen when you click on it while you have the task selected already from what i can tell. I investigated a solution for this awhile back, but it wasn't straight forward. I'm not working on it at the moment if someone wants to take over.

[jlewin]

This problem seems related to the fact that Reselect Task in the outer RapidEditor component is implemented by forcing the url hash from the outer component on the Rapid iframe and from what I can tell, this action resets and loses the effects applied in the WithSearch HOC. Ideally there would only be one source of truth for the view and trying to drive behaviors with the url hash in one case and with state driven effects in the other, seemingly produces the undesired results.

The HOC objects are very hard for me to track, but unless every aspect of their behavior is serialized into the url hash, and unless the outer component always observes and tracks the changes, then there's the potential for differing behavior on the forced hash reset.

Still trying to get a handle on it but sharing some thoughts after an initial review.

Active Repro
https://maproulette.org/challenge/51998/task/292009134

[jlewin]

The prior theory did not hold up under review. WithSearch has no effect on this, and the hash passed to Rapid is consistent in both cases. My latest understanding and theory is that MR is not in control of the view and is delegating to Rapid to by passing entity details (ala id=w686104654) in the hash to bring about select and fit behaviors, and seemingly Rapid behaves one way on load, and differently on update.

It looks like this comes down to behavior in Rapids MapSystem.js as _hashchange observes differences in currParams.get('id') and fires off selectEntityID for the given identifiers, and possibly fitEntities is conditionally invoked in some cases. Still digging in and trying to confirm. As always, I may be way off, but things are finally starting to make sense and there's a glint of clarity in the path of behavior to the problem.

[jlewin]

The attached code snippet confirms that Rapid is responsible for the variance. Or at least MR is relying on Rapid to fit the view to the given features, where it ignores the zoom/lat/lon params and zooms to the bounds of the target feature. On initial load, when the hash is analyzed, newIds != oldIds so selectEntityID is executed but on update they match and its bypassed. In this bypass mode the viewport falls back to the zoom/lat/lon param and thus the disconnect. Force resetting the id when the button is clicked confirms the theory and produces a valid result when the Reselect Task is clicked

It would be ideal if Rapid behaved consistently and applied the fit in both cases, but that might be hard to get pushed through.

Alternatively, MapRoulette could more fully control the viewport, as it does with the iD editor, which might solve a few open issues that are related to this aspect.

[jlewin]

With more investigation and for future reference, the leaflet map view that contrasts the Rapid/Edit view explicitly drives the map bounds and forces fit of task features via:

maproulette3/src/components/TaskPane/TaskMap/TaskMap.jsx

Line 472 in b0ba74d

map.fitBounds(layerGroup.getBounds().pad(0.2));

As discussed in Slack, ideally the map views presented on the Task page should present a consistent view of the content. I went so far as to suggest that once a user zooms/pans that switching views should retain that view and only reset when an explicit Home/Reselect Task operation is executed. Nonetheless, delegating the fit behavior to Rapid makes this difficult to ensure. Given that the Reselect Task behavior is really just rerunning the fit operation for the target entities, having a reference to how the leaflet map is driven at least helps along the idea of working on a Rapid prototype that does the same.