[HOLD for payment 2023-09-13] [$500] Mobile distance confirmation screen initially starts on Atlantic City no matter what your start/finish destinations are

[JmillsExpensify]

Oddly, on iOS and Android the confirmation screen starts off panned on Atlantic City, no matter what start/finish destinations someone has entered.

Reproduction video below.

RPReplay_Final1693858456.MP4

I wasn't able to reproduce this on mWeb.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01347969a6fa0bd52c
• Upwork Job ID: 1698811053702803456
• Last Price Increase: 2023-09-04
• Automatic offers:
• jjcoffee | Contributor | 26496310
• Pujan92 | Contributor | 26496378
• situchan | Contributor | 26499786

[melvin-bot]

Current assignee @JmillsExpensify is eligible for the Bug assigner, not assigning anyone new.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01347969a6fa0bd52c

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

Current assignee @JmillsExpensify is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @jjcoffee (External)

[Pujan92]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Confirmation route starts from incorrect point in distance flow

What is the root cause of that problem?

We are not providing the initialState in confirmation page for the MapView which we are providing for the distance page.

App/src/components/DistanceRequest.js

Lines 238 to 245 in 8150ce0

	<MapView
	accessToken={mapboxAccessToken.token}
	mapPadding={CONST.MAPBOX.PADDING}
	pitchEnabled={false}
	initialState={{
	zoom: CONST.MAPBOX.DEFAULT_ZOOM,
	location: CONST.MAPBOX.DEFAULT_COORDINATE,
	}}

What changes do you think we should make in order to solve the problem?

We need to add initialState in the ConfirmedRoute page.

 initialState={{
      zoom: CONST.MAPBOX.DEFAULT_ZOOM,
      location: CONST.MAPBOX.DEFAULT_COORDINATE,
  }}

App/src/components/ConfirmedRoute.js

Line 92 in 8150ce0

<MapView

Simulator.Screen.Recording.-.iPhone.11.-.2023-09-05.at.03.21.49.mp4

OR

We can set the first waypointMarkers coordinate to the initialState.

initialState={{
      zoom: CONST.MAPBOX.DEFAULT_ZOOM,
      location: waypointMarkers[0].coordinate,
  }}

Simulator.Screen.Recording.-.iPhone.11.-.2023-09-05.at.03.21.14.mp4

[b4s36t4]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Mobile distance confirmation screen initially starts on Atlantic City no matter what your start/finish destinations are

What is the root cause of that problem?

For web mapview we have a default start state which is San Fransico https://github.com/Expensify/react-native-x-maps/blob/c7d24166b7744e1e5310ddb49588ccd70c513ef2/src/MapView/MapView.web.tsx#L11

But for mobile we haven't defined initial state where to start the map.

https://github.com/Expensify/react-native-x-maps/blob/afabed2d2d85c14401354413cd9e5e0db2fdb4cb/src/MapView/MapView.tsx#L9

What changes do you think we should make in order to solve the problem?

We can pass the initial state of location inside ConfirmedRoute just like as we do in DistanceRequest component.

App/src/components/DistanceRequest.js

Line 242 in d2bdaec

initialState={{

initialState={{
    zoom: CONST.MAPBOX.DEFAULT_ZOOM,
    location: CONST.MAPBOX.DEFAULT_COORDINATE,
}}

App/src/components/ConfirmedRoute.js

Line 92 in 1e0a249

<MapView

What alternative solutions did you explore? (Optional)

Or we can just define initial state in react-native-x-maps just as we do for web map

[MahmoudHemaid]

Proposal

Mobile distance confirmation screen initially starts on Atlantic City no matter what your start/finish destinations are

What is the root cause of that problem?

We calculate the map on screen focus which triggered after the screen is already visible so the it's not the initial load for the map

useFocusEffect(
    useCallback(() => {
        if (waypoints?.length && isIdle) {
            if (waypoints.length === 1) {
                cameraRef.current?.setCamera({
                    zoomLevel: 15,
                    animationDuration: 1500,
                    centerCoordinate: waypoints[0].coordinate,
                });
            } else {
                const {southWest, northEast} = utils.getBounds(waypoints.map((waypoint) => waypoint.coordinate));
                cameraRef.current?.fitBounds(northEast, southWest, mapPadding, 1000);
            }
        }
        return () => {
            setIsIdle(false);
        };
    }, [mapPadding, waypoints, isIdle]),
);

What changes do you think we should make in order to solve the problem?

Add bounds to initial state and pass it from ConfirmedRoute

const waypointMarkers = getWaypointMarkers(waypoints);
const {southWest, northEast} = utils.getBounds(waypointMarkers      .map((waypoint) => waypoint.coordinate));
const initialMapState = {
    bounds: {
        paddingBottom: CONST.MAP_PADDING,
        paddingLeft: CONST.MAP_PADDING,
        paddingRight: CONST.MAP_PADDING,
        paddingTop: CONST.MAP_PADDING,
        ne: northEast,
        sw: southWest,
    }
};

Simulator.Screen.Recording.-.iPhone.13.-.2023-09-05.at.01.12.30.mp4

What alternative solutions did you explore? (Optional)

N/A