hamedandClaude Opus 4.8
fbb2279b49
With the backend now returning 200 (lazy-created profile) instead of 404, align the consumers: the profile lives at res.data.data (the endpoint double-nests), so the booking detail and dashboard read that instead of res.data / the raw envelope. Drop the obsolete 404 special handling (empty editable form now comes from the 200 payload), seed the dashboard empty state when the profile has no real data yet, and make the profile POST fall back to PATCH on 409 (already lazy-created). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
86 lines
6.4 KiB
Markdown
86 lines
6.4 KiB
Markdown
# همخوانکردن مصرف پروفایل کاربر با endpoint اصلاحشده (بدون 404 برای کاربر جدید)
|
|
|
|
## پروژه
|
|
|
|
`nobat724_front` — سایت عمومی. **بعد از پرامپت backend اجرا شود.**
|
|
|
|
> **Cross-repo:** وابسته به اصلاح `GET /api/v1/user-profile/{uuid}` در
|
|
> `clinicpro/.claude/prompt/user-profile-resolve-by-user-uuid.md`
|
|
> که بعد از آن، endpoint با **user-uuid** هم کار میکند و برای کاربر بدون پروفایل، پروفایل خالی (200) برمیگرداند بهجای 404.
|
|
|
|
## زمینه
|
|
|
|
`getUserProfile(uuid)` در سه جا با **uuid کاربر** (از کوکی) صدا زده میشود:
|
|
`components/appointment/index.js` (دو جا) و `components/dashboard/userAccount/detailUser/information/index.js`. قبل از اصلاح backend، این فراخوانی برای کاربر تازهلاگینکرده 404 میداد و کد مجبور بود حالت 404 را بهصورت ویژه هندل کند (فیلدها قابلویرایش، خالی). بعد از اصلاح backend، همان فراخوانی **200 با پروفایل خالی** برمیگرداند و دیگر 404ای در کار نیست.
|
|
|
|
## مشکل / هدف
|
|
|
|
۱. تأیید کن که با endpoint اصلاحشده، مرحلهی Detail نوبت و داشبورد، پروفایل را درست لود میکنند (دیگر 404 نمیگیرند).
|
|
۲. منطق ویژهی 404 که دیگر لازم نیست را ساده کن (بدون شکستن حالت «پروفایل خالی»).
|
|
۳. شکل پاسخ را با backend همخوان نگهدار: پاسخ `{ success, data: {...profile...} }` است → بعد از interceptor، پروفایل در `res.data`.
|
|
|
|
## فایلهای مرتبط
|
|
|
|
| فایل | نقش |
|
|
|------|-----|
|
|
| `components/appointment/index.js` | `getUserProfile(parsedData.uuid)` در mount و step 3؛ منطق 404 موجود |
|
|
| `components/appointment/detail/SubmitData.js` | بعد از تغییر اطلاعات، PATCH/POST پروفایل (`uuid` پروفایل لازم است) |
|
|
| `components/dashboard/userAccount/detailUser/information/index.js` | `getUserProfile(parsedUserInfo.uuid)` |
|
|
| `services/response.js` | `getUserProfile`, `postUserProfile`, `patchUserProfile` |
|
|
|
|
## وضعیت فعلی (کد واقعی)
|
|
|
|
### `components/appointment/index.js` — هندل ویژهی 404
|
|
|
|
```js
|
|
const res = await request.getUserProfile(parsedData.uuid);
|
|
if (res?.data) {
|
|
const newData = buildProfileData(res.data, usernameFromCookie);
|
|
setData(newData);
|
|
setPrevData(newData);
|
|
}
|
|
// ...
|
|
} catch (error) {
|
|
if (error?.response?.status === 404) {
|
|
setData(prev => ({ ...prev, national_code: { value: "", isEdit: true }, ... })); // دیگر لازم نیست
|
|
}
|
|
}
|
|
```
|
|
|
|
### `SubmitData.js` — انتخاب POST یا PATCH بر اساس وجود `uuid`
|
|
|
|
```js
|
|
if (uuid) {
|
|
await request.patchUserProfile(payload, uuid); // uuid پروفایل
|
|
} else {
|
|
await request.postUserProfile(payload);
|
|
}
|
|
```
|
|
|
|
> `uuid` اینجا از `data.uuid` میآید که در `buildProfileData(profile)` برابر `profile.uuid` (uuid پروفایل) ست میشود. حالا که backend برای کاربر جدید پروفایل خالی (با `uuid` واقعی پروفایل) برمیگرداند، `data.uuid` همیشه پر است و مسیر PATCH درست کار میکند.
|
|
|
|
## وظایف
|
|
|
|
### ۱. تأیید جریان لود پروفایل (appointment + dashboard)
|
|
|
|
- مطمئن شو هر سه فراخوانی `getUserProfile(uuid)` با **uuid کاربر** (از کوکی) کار میکنند و `res.data` پروفایل را میدهد.
|
|
- `buildProfileData(res.data, ...)` باید `uuid` پروفایل را از `res.data.uuid` بگیرد (نه user uuid) تا PATCH بعدی درست باشد. بررسی کن `buildProfileData` فیلد `uuid` را از `profile.uuid` میخواند (پاسخ backend شامل `uuid` پروفایل و `user_uuid` است).
|
|
|
|
### ۲. سادهسازی هندل 404 منسوخ
|
|
|
|
- در `components/appointment/index.js`، بلوک `if (error?.response?.status === 404) { ... }` در هر دو `useEffect` دیگر لازم نیست (backend دیگر 404 نمیدهد). آن را حذف کن یا به یک هندل خطای عمومی ساده تبدیل کن (toast سراسری از قبل خطاها را نشان میدهد). حالت «پروفایل خالی» حالا از خود پاسخ 200 میآید، نه از catch.
|
|
- مراقب باش منطق `defaultData`/`prevData` نشکند: اگر `res.data` فیلدهای null دارد، `buildProfileData` باید آنها را به `{ value: "", isEdit: true }` تبدیل کند (همان رفتار فعلی برای فیلدهای خالی).
|
|
|
|
### ۳. سازگاری POST/PATCH در `SubmitData.js`
|
|
|
|
- چون backend حالا پروفایل را lazy-create میکند، `data.uuid` برای کاربرِ «خودش» همیشه پر است → مسیر `patchUserProfile(payload, uuid)` طی میشود. مطمئن شو این درست است و مسیر `postUserProfile` (که ممکن بود 409 بدهد چون پروفایل از قبل ساخته شده) دیگر طی نمیشود مگر واقعاً `uuid` نباشد.
|
|
- اگر `postUserProfile` به هر دلیل 409 داد (پروفایل از قبل هست)، آن را به PATCH تبدیل کن یا نادیده بگیر (نه خطای کاربر).
|
|
|
|
## نکات مهم
|
|
|
|
- **وابستگی cross-repo:** بدون اصلاح backend، این هندلها هنوز 404 میگیرند. اگر backend هنوز اصلاح نشده، **اول آن را اجرا کن**.
|
|
- **شکل پاسخ:** `{ success, data: {...} }` → پروفایل در `res.data` (interceptor یکبار باز میکند). `res.data.uuid` = uuid پروفایل (برای PATCH)، `res.data.user_uuid` = uuid کاربر.
|
|
- **توهمسازی نکن:** فیلدهای null پروفایل را خالی و قابلویرایش نشان بده، نه مقدار جعلی.
|
|
- RTL/Jalali/multi-domain حفظ شوند.
|
|
- **تست:** `npm run build`؛ سپس دستی با کاربر `09210651788` (که پروفایل نداشت): بعد از لاگین، مرحلهی Detail نوبت و صفحهی داشبورد باید **بدون 404** فرم خالی قابلویرایش نشان دهند؛ ذخیره (PATCH) باید کار کند. سپس commit.
|