@autobusal/routes-order 1.32.0 → 1.33.0

package/services.ts

@@ -4,7 +4,7 @@ import { apiClient } from '@autobusal/providers';
 import { RoutesSearchForm } from '@autobusal/routes-search/types';
 import { FoundData, FlexOffer } from '@autobusal/providers/types/routes';
 import { CouponData } from '@autobusal/providers/types/orders';
-import { BillingData, PersonData } from '@autobusal/providers/types/persons';
+import { BillingData, PersonData, SavedPassengerRecord, SavedPassengersData } from '@autobusal/providers/types/persons';
 import { FoundDay, ActionData, SaveData, OrderedData, CouponForm, AddonsSelection, AlternativesData, PriceAlertRequest, PriceAlertData } from './types';
 
 export const useGetDepartures = (data: RoutesSearchForm): UseQueryResult<FoundData[]> => (
@@ -313,3 +313,77 @@ export const usePostPriceAlert = (): UseMutationResult<PriceAlertData, AxiosErro
     retry: false
   })
 );
+
+/**
+ * The travellers this account has saved, measured against THIS journey.
+ *
+ * Edited: Claude - Date: 2026-08-20
+ *
+ * The price ids are what make the answer journey-specific: obtapi puts a
+ * `missing` array on every row naming the fields these particular routes
+ * collect and this particular saved traveller has not got (see
+ * Account\PassengersController::browse). Without them the rows come back
+ * with no `missing` key at all, which is a different answer from an empty
+ * one - so they are always sent from here.
+ *
+ * `enabled` is the whole gate, and it is not an optimisation. The endpoint
+ * is `role:visitor`, so a guest or a member of staff gets a 404 - a correct
+ * refusal that confirms nothing, and one this UI must never turn into an
+ * error on somebody's checkout. Not asking is the only way to be sure of
+ * that; `retry: false` covers the case where the account changes underneath
+ * a query already in flight.
+ */
+export const useGetSavedPassengers = (
+  departurePriceId: (number | undefined),
+  returnPriceId: (number | undefined),
+  enabled: boolean
+): UseQueryResult<SavedPassengersData> => (
+  useQuery({
+    queryKey: ['saved-passengers-checkout', { departurePriceId, returnPriceId }],
+    enabled: enabled && departurePriceId !== undefined,
+    retry: false,
+    queryFn: async () => (
+      await apiClient
+        .get('/api/account/passengers/browse', {
+          params: {
+            departure_price_id: departurePriceId,
+            return_price_id: returnPriceId
+          }
+        })
+        .then(response => (
+          response.data
+        ))
+    )
+  })
+);
+
+/**
+ * One saved traveller, passport included.
+ *
+ * Edited: Claude - Date: 2026-08-20
+ *
+ * A mutation for a GET, deliberately. This is not data the screen renders -
+ * it is fetched at the moment somebody picks a name out of the chooser, and
+ * what comes back is written into a form rather than displayed. A query
+ * would need the chosen id in render state and an effect to notice it
+ * landing; `mutate(id, { onSuccess })` is the same fetch with the answer
+ * arriving where the decision was made.
+ *
+ * This is also the ONLY request in the app that returns a stored passport
+ * number, which is why it is one traveller at a time and only after a
+ * customer has said who is sitting in this seat.
+ */
+export const useGetSavedPassenger = (): UseMutationResult<SavedPassengerRecord, Error, number, unknown> => (
+  useMutation({
+    mutationKey: ['saved-passenger-record'],
+    mutationFn: async (id: number) => (
+      await apiClient
+        .get('/api/account/passengers/get', {
+          params: { id }
+        })
+        .then(response => (
+          response.data
+        ))
+    )
+  })
+);