Files
waseel/store/index.ts
KrikoriosandClaude Opus 5 8807ff41c5 Waseel: driver capture, chat/calls, dispatch, and session fixes
Driver onboarding now photographs the licence, ID card and vehicle
registration and reads the credential fields off them, plus a camera-only
profile selfie riders check the arriving driver against. Adds in-app chat
and WebRTC calls, push-backed ride offers, ratings, cancellation and
payment sheets, settlement, and the owner dashboard endpoints behind them.

Camera permission on Android:
  - Declare CAMERA and READ_MEDIA_IMAGES in the manifest. expo-image-picker's
    own plugin never declares CAMERA, and Android denies a request for an
    undeclared permission instantly and silently — no dialog is ever shown,
    which is indistinguishable from the app not asking at all.
  - Handle canAskAgain: once Android stops showing the dialog, repeating why
    we need it is a dead end, so offer Open Settings instead (lib/capture-
    permission.ts), matching what the location flow already did.

Session: a 401 on a request that carried a token now ends the session
instead of being reinterpreted per-screen — driver-home had been reading it
as "this user has no driver profile" and showing an onboarding form to an
already-onboarded driver. Requests without a token are exempt so a failed
sign-in doesn't sign you out, and the notification is latched per token so
concurrent polls tear the session down once. (root) gains the auth guard
that turns that into the sign-in screen; app/index.tsx only guarded the way
in, leaving a session that ended mid-screen with nowhere to go.

Also ignore .uploads/ — it holds driver licence, ID and vehicle scans plus
profile photos, which are personal data and must not be committed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-26 02:17:55 +03:00

87 lines
2.4 KiB
TypeScript

import { DEFAULT_SERVICE, type ServiceId } from "@/constants/services";
import type { DriverStore, LocationStore, MarkerData } from "@/types/type";
import { create } from "zustand";
export const useLocationStore = create<LocationStore>((set) => ({
userAddress: null,
userLongitude: null,
userLatitude: null,
destinationLongitude: null,
destinationLatitude: null,
destinationAddress: null,
setUserLocation: ({
latitude,
longitude,
address,
}: {
latitude: number;
longitude: number;
address: string;
}) => {
set(() => ({
userLatitude: latitude,
userLongitude: longitude,
userAddress: address,
}));
},
setDestinationLocation: ({
latitude,
longitude,
address,
}: {
latitude: number;
longitude: number;
address: string;
}) => {
set(() => ({
destinationLatitude: latitude,
destinationLongitude: longitude,
destinationAddress: address,
}));
},
/**
* Forget where the rider was going.
*
* The destination is a search in progress, not durable state, but nothing
* ever cleared it — so once a rider had looked up an address it stayed in
* the store for the life of the process. Android keeps that process alive
* across backgrounding, so reopening the app showed a route to a trip that
* had already finished, and the map stayed zoomed out to fit a destination
* the rider had long since arrived at.
*
* Called when a ride reaches a terminal state and on sign-out. The origin is
* deliberately left alone: that's the rider's own position, still true.
*/
clearDestination: () => {
set(() => ({
destinationLatitude: null,
destinationLongitude: null,
destinationAddress: null,
}));
},
}));
type ServiceStore = {
service: ServiceId;
setService: (service: ServiceId) => void;
};
/** Which service the rider picked on the home screen. */
export const useServiceStore = create<ServiceStore>((set) => ({
service: DEFAULT_SERVICE,
setService: (service: ServiceId) => set(() => ({ service })),
}));
export const useDriverStore = create<DriverStore>((set) => ({
drivers: [] as MarkerData[],
selectedDriver: null,
setSelectedDriver: (driverId: number) =>
set(() => ({ selectedDriver: driverId })),
setDrivers: (drivers: MarkerData[]) => set(() => ({ drivers })),
clearSelectedDriver: () => set(() => ({ selectedDriver: null })),
}));