Add `Remove` button to `Track distance` > `Map` flow on web and mobile

[jamesdeanexpensify]

Background

Coming from this convo, we'd like to add a Remove button to the Track distance > Map flow, specifically on the page where you enter an individual address. Both on web and mobile.

Details

This is exactly where we want to add the Remove button, on the second screen below:

cc @Expensify/design

Issue Owner

Current Issue Owner: @mollfpr

[melvin-bot]

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

[PiyushChandra17]

🚨 Edited by proposal-police: This proposal was edited at 2026-01-22 23:59:49 UTC.

Proposal

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

Add Remove button to Track distance > Map flow on web and mobile

What is the root cause of that problem?

Improvement

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

1. Add a Remove button in IOURequestStepWayPoint

App/src/pages/iou/request/step/IOURequestStepWaypoint.tsx

Lines 231 to 275 in 59db900

	<FormProvider
	style={[styles.flexGrow1, styles.mh5]}
	formID={ONYXKEYS.FORMS.WAYPOINT_FORM}
	enabledWhenOffline
	validate={validate}
	onSubmit={submit}
	shouldValidateOnChange={false}
	shouldValidateOnBlur={false}
	submitButtonText={translate('common.save')}
	shouldHideFixErrorsAlert
	onScroll={onScroll}
	>
	<View>
	<InputWrapperWithRef
	InputComponent={AddressSearch}
	locationBias={locationBias}
	canUseCurrentLocation
	inputID={`waypoint${pageIndex}`}
	ref={(e: HTMLElement | null) => {
	textInput.current = e as unknown as TextInput;
	}}
	hint={!isOffline ? translate('distance.error.selectSuggestedAddress') : ''}
	containerStyles={[styles.mt4]}
	label={translate('distance.address')}
	defaultValue={waypointAddress}
	onPress={selectWaypoint}
	maxInputLength={CONST.FORM_CHARACTER_LIMIT}
	renamedInputKeys={{
	address: `waypoint${pageIndex}`,
	city: '',
	country: '',
	street: '',
	street2: '',
	zipCode: '',
	lat: '',
	lng: '',
	state: '',
	}}
	predefinedPlaces={recentWaypoints}
	resultTypes=""
	caretHidden={caretHidden}
	onValueChange={resetCaretHiddenValue}
	/>
	</View>
	</FormProvider>

<View>
    <Button
        large
        style={[styles.mt3]}
        text={translate('common.remove')}
        onPress={handleDeleteWaypoint}
    />
</View>

2. We already have handleDeleteWayPoint here, perhaps onPress will trigger that function

App/src/pages/iou/request/step/IOURequestStepWaypoint.tsx

Lines 161 to 174 in 59db900

	const handleDeleteWaypoint = async () => {
	const result = await showConfirmModal({
	title: translate('distance.deleteWaypoint'),
	prompt: translate('distance.deleteWaypointConfirmation'),
	confirmText: translate('common.delete'),
	cancelText: translate('common.cancel'),
	shouldEnableNewFocusManagement: true,
	danger: true,
	});
	if (result.action !== ModalActions.CONFIRM) {
	return;
	}
	deleteStopAndHideModal();
	};

3. Updated Code:

<FormProvider
    style={[styles.flexGrow1, styles.mh5]}
    formID={ONYXKEYS.FORMS.WAYPOINT_FORM}
    enabledWhenOffline
    validate={validate}
    onSubmit={submit}
    shouldValidateOnChange={false}
    shouldValidateOnBlur={false}
    submitButtonText={translate('common.save')}
    shouldHideFixErrorsAlert
    onScroll={onScroll}
    shouldRenderFooterAboveSubmit
    footerContent={
        waypointAddress && (
            <Button
                large
                style={[styles.mt3]}
                text={translate('common.remove')}
                onPress={handleDeleteWaypoint}
            />
        )
    }
>

What alternative solutions did you explore? (Optional)

n/A

Result

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[mkzie2]

Proposal

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

Add Remove button to Track distance > Map flow on web and mobile

What is the root cause of that problem?

Improvement

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

Add a button to waypoint form here

App/src/pages/iou/request/step/IOURequestStepWaypoint.tsx

Lines 231 to 242 in 59db900

	<FormProvider
	style={[styles.flexGrow1, styles.mh5]}
	formID={ONYXKEYS.FORMS.WAYPOINT_FORM}
	enabledWhenOffline
	validate={validate}
	onSubmit={submit}
	shouldValidateOnChange={false}
	shouldValidateOnBlur={false}
	submitButtonText={translate('common.save')}
	shouldHideFixErrorsAlert
	onScroll={onScroll}
	>

                    shouldRenderFooterAboveSubmit
                    footerContent={
                        !!waypointAddress && (
                            <Button
                                text={translate('common.remove')}
                                style={[styles.mb3]}
                                onPress={handleDeleteWaypoint}
                                large
                            />
                        )
                    }

We'll use existing handleDeleteWaypoint as this button's functionality since its usage matches the requirement, or we can create a similar function to handle the remove button.

Other styling details can be discussed in PR phase.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[abbasifaizan70]

Proposal

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

In the Track distance > Map flow, when users are on the individual address entry screen (where they enter/edit a waypoint address), there is no easily accessible "Remove" button to delete the waypoint. Currently, users can only remove waypoints through the three-dots menu in the header, which is only visible when there are more than 2 waypoints. This creates a poor user experience as the remove functionality is hidden and not immediately discoverable.

What is the root cause of that problem?

Improvement

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

Add a "Remove" button to the address entry screen, positioned above the "Save" button. This button will call the existing handleDeleteWaypoint function, which shows a confirmation modal before removing the waypoint.

File: App/src/pages/iou/request/step/IOURequestStepWaypoint.tsx

Changes Required:

1. Import Button component:
   

   App/src/pages/iou/request/step/IOURequestStepWaypoint.tsx

   Line 7 in 1870f15

   import FullPageNotFoundView from '@components/BlockingViews/FullPageNotFoundView';

   • Add Button import from @components/Button (line 7)

2. Memoize callback functions:

App/src/pages/iou/request/step/IOURequestStepWaypoint.tsx

Lines 105 to 111 in 1870f15

	if (backTo) {
	Navigation.goBack(backTo);
	return;
	}
	Navigation.goBack(ROUTES.MONEY_REQUEST_CREATE_TAB_DISTANCE.getRoute(CONST.IOU.ACTION.CREATE, iouType, transactionID, reportID));
	};

• Wrap goBack in useCallback (already implemented)

App/src/pages/iou/request/step/IOURequestStepWaypoint.tsx

Lines 157 to 160 in 1870f15

	removeWaypoint(transaction, pageIndex, shouldUseTransactionDraft(action));
	goBack();
	};

• Wrap deleteStopAndHideModal in useCallback (already implemented)

App/src/pages/iou/request/step/IOURequestStepWaypoint.tsx

Lines 162 to 175 in 1870f15

	const result = await showConfirmModal({
	title: translate('distance.deleteWaypoint'),
	prompt: translate('distance.deleteWaypointConfirmation'),
	confirmText: translate('common.delete'),
	cancelText: translate('common.cancel'),
	shouldEnableNewFocusManagement: true,
	danger: true,
	});
	if (result.action !== ModalActions.CONFIRM) {
	return;
	}
	deleteStopAndHideModal();
	};

• Wrap handleDeleteWaypoint in useCallback (already implemented)

3. Create Remove button footer content:
   

   App/src/pages/iou/request/step/IOURequestStepWaypoint.tsx

   Line 206 in 1870f15

   return (

   • Add a memoized removeButtonFooterContent that renders a Button component using default styling

const removeButtonFooterContent = useMemo(
    () => (
        <View style={[styles.mb3]}>
            <Button
                text={translate('common.remove')}
                onPress={handleDeleteWaypoint}
                large
                isDisabled={!waypointAddress}
            />
        </View>
    ),
    [styles.mb3, translate, handleDeleteWaypoint, waypointAddress],
);

4. Add footerContent to FormProvider:
   

   App/src/pages/iou/request/step/IOURequestStepWaypoint.tsx

   Lines 231 to 242 in 1870f15

   	<FormProvider
   	style={[styles.flexGrow1, styles.mh5]}
   	formID={ONYXKEYS.FORMS.WAYPOINT_FORM}
   	enabledWhenOffline
   	validate={validate}
   	onSubmit={submit}
   	shouldValidateOnChange={false}
   	shouldValidateOnBlur={false}
   	submitButtonText={translate('common.save')}
   	shouldHideFixErrorsAlert
   	onScroll={onScroll}
   	>

   • Add footerContent={removeButtonFooterContent} prop
   • Add shouldRenderFooterAboveSubmit prop set to true to position the Remove button above the Save button

     submitButtonText={translate('common.save')}
                    shouldHideFixErrorsAlert
                    onScroll={onScroll}
                    footerContent={removeButtonFooterContent}
                    shouldRenderFooterAboveSubmit
                >

Implementation Details:

The Remove button will:

• Use the default Button component styling (matching existing button patterns in the app)
• Use the large size to match the Save button
• Be disabled when waypointAddress is empty (using isDisabled={!waypointAddress})
• Call handleDeleteWaypoint when pressed, which shows a confirmation modal
• Be positioned above the Save button using FormProvider's footerContent and shouldRenderFooterAboveSubmit props
• Be memoized with useMemo to prevent unnecessary re-renders
• Update its disabled state automatically when the address field changes

Benefits:

1. Improved discoverability: The Remove button is now prominently displayed on the screen
2. Consistent UX: Matches the pattern of having action buttons (Remove, Save) on detail/edit screens and uses standard button styling
3. Always accessible: Available regardless of waypoint count (unlike the three-dots menu)
4. Smart disabled state: Button is automatically disabled when there's no address to remove, preventing unnecessary actions
5. Reuses existing logic: Uses the existing handleDeleteWaypoint function, maintaining the confirmation modal behavior
6. Cross-platform: Works on both web and mobile using React Native components
7. Performance optimized: Uses useMemo and useCallback to prevent unnecessary re-renders

Demo

Screen.Recording.2026-01-23.at.5.06.36.AM.mov

[github-actions]

⚠️ @abbasifaizan70 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[mkzie2]

Note for C+: Please take a look at proposal edit timestamps when reviewing proposals, thanks!

[PiyushChandra17]

Note for C+: Please take a look at proposal edit timestamps when reviewing proposals

I think this is a straight-forward technical task and i was the first one to post proposal for this one and link to the correct file location (if you look at the first two edits that should be enough). Thanks!

cc: @jamesdeanexpensify @bernhardoj

[bernhardoj]

I'll check this tomorrow..

[bernhardoj]

Looking at the edit, it looks like really low effort.

I would choose @mkzie2, but I need to confirm the behavior first.

@jamesdeanexpensify will the Remove button behave the same way as Delete waypoint? Delete waypoint is only shown when there are more than 2 waypoints.

w.mp4

[PiyushChandra17]

Looking at the edit, it looks like really low effort.

@bernhardoj

1. Yes i agree, perhaps i think i have updated my Proposal accordingly

2. I still think this is a straight-forward task and should be selected on the basis of first come, first serve basis according to the CONTRIBUTING.md

3. However if you look at the Proposal edit timestamps, my latest comprehensive proposal (5th edit) is still the first to address this issue.

PS: In future, i'll keep this in mind while posting proposals ....

Note: I think some minor styling changes can be discussed in the PR phase 🤔. Thanks!

cc: @jamesdeanexpensify