[SSF-226] Pantry Deleting & Editing Food Requests Frontend

[jiang-h-y]

ℹ️ Issue

Closes SSF-226

📝 Description

• added edit and delete buttons
• added editing view + delete request modal
• added success/error toasts
  • Note: the status for the toasts are temporarily incorrect + hard-coded since I recently refactored alerts in a different branch, and I would rather use the refactored version once it's merged.
• connected to existing backend endpoints
• edge case handling for if the user:
  • clears "Additional Information"
  • makes back-to-back edits without closing the modal
  • clicks "Update Request" but changes nothing

✔️ Verification

• tested edit/delete request flows
• verified that changes are committed to the database

Base Request Modal:

Editing View:

Delete Request Modal:

Success Toast Example:

🏕️ (Optional) Future Work / Notes

• not sure if some of my design choices (colors, hover, etc.) were consistent with the rest of the codebase
• sometimes received this error, but I couldn't reproduce it:
  Uncaught Error: Your focus-trap needs to have at least one focusable element

[dburkhart07]

few things, looking beautiful tho!!

[dburkhart07]

Note: Once you merge in your PR for fixing the alert messages, you'll need to adjust this to be a success (right now, it shows up as an error, but don't bother fixing that till your later PR comes in)

[dburkhart07]

We shouldnt display either of these buttons for a closed food request

[dburkhart07]

Thanks for looking into this. This might just be me, but I personally don't think we need any of this code, and may want to go with the simpler design approach. We could pretty easily get rid of all of this if we just use the actual state variables that we are changing in the form to compose the body as is. All of the fields are optional, so I think it's fine if we just pass them in anyways. This would mean just changing the function to something more like

const handleUpdate = async () => {
    try {
      await apiClient.updateFoodRequest(request.requestId, {
        requestedSize,
        requestedFoodTypes: selectedFoodTypes,
        additionalInformation: additionalNotes === '' ? null : additionalNotes,
      });
      onSuccess();
      setAlertMessage('Successfully updated food request.');
      setIsEditing(false);
    } catch {
      setAlertMessage('Food request could not be updated.');
    }
  };

This would also remove any baseline stuff, at the cost of a potential no-op network call which should be fine, and we can (and should) account for this in the service call. lmk if u disagree tho

[dburkhart07]

nit: both editButton and deleteButton are only used once within the code, so making a const for them outside of it is likely unnecessary, and inconsistent with how we have done most icons previously. can we make this change both in this file and pantryDeleteRequestModal?

[dburkhart07]

Can you ask our DL, Priya about this and adjust accordingly for both of these?

[dburkhart07]

nit: i think this is supposed to be #E4E4E7, not neutral 100

[dburkhart07]

can you change this to 6?

[dburkhart07]

This is what's causing your bug. We are doing conditional rendering for the dialog, as opposed to using the open prop. We want to keep the Dialog mounted whenever a request is selected, and let the open prop do the showing/hiding. We essentially don't want to keep mounting and unmounting like we are right now (when deleteRequest gets a value, the component becomes faulty and gets unmounted), and should change it to this:

{selectedViewDetailsRequest && (
    <RequestDetailsModal
      request={selectedViewDetailsRequest}
      isOpen={!deleteRequest} 
      onClose={() => {
        setSelectedViewDetailsRequest(null);
        if (initialRequestId) {
          navigate(location.pathname, { replace: true });
        }
      }}
      onSuccess={loadRequests}
      onDelete={() => setDeleteRequest(selectedViewDetailsRequest)}
    />
  )}

This way, we toggle visibility on the presence of the delete request rather than mounting and unmounting