خطة — نقل صفحتي Samples (Collection) و Reception للباك إند

بناءً على تقرير الأداء: الصفحتين بيعتمدوا على نداءات متعددة بـper_page ثابت + تجميع تقيل في المتصفح — وده خطر فقدان بيانات في الأيام المزدحمة (مش بطء بس). الخطة دي بتطبّق نفس النمط اللي نجح في الورك ليست: نقل التجميع للباك عبر endpoints مخصصة، بأمان ومراحل متحقَّقة.

🗓️ 2026-06-08🧬 LIS — Collection + Receptionالتقييم: جيد · أعلى خطر: Pagination · الأولوية P1/P2

0 الوضع الحالي (من الكود)

الصفحة	الحجم	التحميل الحالي	الخطر
Collection (Samples)	1,587 سطر	~7 نداءات (4 requests + 3 samples) + تجميع client-side	per_page ثابت → فقدان بيانات
Reception	376 سطر	`listByFilter per_page:200` بدون فلتر حالة/تاريخ صريح	overflow فوق 200
endpoints مخصصة بالباك	مش موجودة لسه — لا `/lis/collection-worklist` ولا `/lis/reception-worklist`

✅ ميزة كبيرة

دي نفس مشكلة الورك ليست اللي خلّصناها — فعندنا نمط مُجرَّب وناجح (BE ContextService + endpoints + opt-in toggle + parity harness). هنعيد استخدامه.

1 اللي التقرير لقاه

المشكلة الجوهرية (الأخطر)

🚨 خطر فقدان بيانات — `per_page` ثابت

Collection: per_page=100 (requests) + 200 (samples). Reception: 200. في يوم مزدحم، السجلات اللي بعد الحد بتختفي من الشاشة — ده يأثر على دقة البيانات مش الأداء بس. (نفس باگ الـ25/صفحة اللي عالجناه في الورك ليست.)

باقي المشاكل

المشكلة	الصفحة	الحل المقترح	أولوية
تجميع client-side (دمج samples/requests، حساب التيوبات/الحالات)	Collection	ينتقل للباك	P1
Auto-aliquot أثناء `loadData` (فتح الصفحة بيعدّل بيانات!)	Collection	ينتقل لمرحلة إنشاء الطلب أو زرار صريح	P1
Collect All = نداءات منفصلة لكل تيوب	Collection	استخدام `bulkCollect` الموجود	P2
كل Receive = `deliver` + reload كامل للقائمة	Reception	optimistic update + تحديث خلفي	P2
`bulkReceive` موجود بس مش مستخدَم	Reception	multi-select / scan queue + bulk	P2
تغذية راجعة للباركود ضعيفة (صوت/لون/رسالة ثابتة)	الاتنين	feedback ثابت + حارس تكرار المسح	P2
بحث client-side على كل ضغطة	الاتنين	debounce (عملناه في الورك ليست) + بحث سيرفر	P2
Reject dialog مش بيعرض تجميع البنل	Reception	عرض رؤوس البنل وأعضاءه زي Samples	P3
عدّادات منفصلة + عرض responsive لشاشات المعمل الكبيرة	الاتنين	عدّادات (داخلي/B2B/مرفوض/مستلَم اليوم) + width مرن	P3

2 المعمارية المستهدفة (نفس نمط الورك ليست)

قبل: Angular ──~7 نداءات──► API ──خام──► [دمج + تيوبات + حالات + aliquot في المتصفح] ──► رسم بعد: Angular ──نداء واحد──► /lis/collection-worklist ──كروت جاهزة──► رسم بسيط Angular ──نداء واحد──► /lis/reception-worklist ──صفوف جاهزة──► رسم بسيط └─ كل المنطق في CollectionWorklistService / ReceptionWorklistService (الباك)

الباك (جديد)

CollectionWorklistService — تجميع الكروت + التيوبات + الحالات (pending/deferred/cancelled/sent-out/history)
ReceptionWorklistService — صفوف الاستلام (to-receive/rejected/history) + عدّادات + فلتر مصدر/تاريخ
endpoints: /lis/collection-worklist · /lis/reception-worklist — بترجّع كل الصفحات (مفيش حد per_page)

الفرونت

خدمة رفيعة بتستهلك الـendpoints وترسم الجاهز
الأكشنات تستخدم bulkCollect/bulkReceive
optimistic updates + باركود feedback + debounce
toggle ?serverReception=1 للتجربة والرجوع

3 المراحل (آمنة، بنفس دروس الورك ليست)

مرحلة 0

Quick-win فوري — إيقاف خطر فقدان البيانات Frontend سلامة

الهدف: نوقف اختفاء السجلات حالاً، قبل أي إعادة معمارية.

استبدال per_page الثابت بـتحميل كل الصفحات (نمط listAll() الموجود) في الصفحتين.
إضافة بانر "بيانات غير مكتملة" لو فشل تحميل جزء.
تغيير منخفض المخاطر، بيدّي قيمة فورية.

مرحلة 1

endpoints الباك المخصصة Backend

الهدف: مصدر حقيقة واحد، بيانات جاهزة للعرض.

ReceptionWorklistService + /lis/reception-worklist (الأبسط — نبدأ بيه).
CollectionWorklistService + /lis/collection-worklist (الأعقد — التيوبات/الأقسام/البنلات/aliquot).
بترجّع كل الصفحات + عدّادات + فلاتر (حالة/تاريخ/مصدر).
Parity harness يقارن الجديد بالقديم على بيانات حقيقية — زي ما عملنا بالظبط.

مرحلة 2

توصيل الفرونت خلف toggle + تجربتك Frontend سلامة

الهدف: تجرّبه حيّ قبل ما يبقى أساسي.

خدمة رفيعة تستهلك الـendpoints، خلف ?serverReception=1 (الافتراضي قديم).
تجرّب Reception ثم Collection على بياناتك → تأكّد → نخلّيهم أساسي.

مرحلة 3

التحسينات التشغيلية Frontend Backend

الهدف: سرعة المسح والإدخال.

bulk: Collect All عبر bulkCollect، Reception scan-queue + bulkReceive.
optimistic update: الصف يتحدّث فوراً + تحديث خلفي (مفيش reload كامل).
باركود: تأكيد ثابت (اسم المريض/رقم الطلب/الباركود) + تحذير صوت/لون للمفقود + حارس تكرار.
auto-aliquot: ينتقل لزرار صريح أو وقت إنشاء الطلب (مش وقت فتح الصفحة).

مرحلة 4

UX Frontend

الهدف: واجهة معمل سريعة.

عدّادات منفصلة (داخلي ينتظر / B2B ينتظر / مرفوض / مستلَم اليوم).
Reject dialog يعرض تجميع البنل (رؤوس + أعضاء).
عرض responsive يستغل شاشات المعمل الكبيرة.

4 دروس من الورك ليست هنطبّقها

✅ Parity أولاً

مانفعّلش الجديد قبل ما يطابق القديم 1:1 على بياناتك (harness آلي).

✅ opt-in ثم default

toggle، إنت تجرّب الأول، الـlab على القديم لحد ما تأكّد.

✅ بناء آمن

مانمسحش البندل القديم إلا لو البناء نجح (الدرس اللي اتعلمناه).

✅ git = رجوع

كل خطوة commit منفصل، رجوع فوري.

5 قرارات قبل ما أبدأ

نبدأ بإيه؟ أنصح مرحلة 0 (Quick-win: إصلاح خطر فقدان البيانات) فوراً على الصفحتين — أأمن وأسرع قيمة. توافق؟
أي صفحة الأول للباك؟ أنصح Reception (أبسط، 376 سطر) كـpilot، بعدها Collection (1,587 سطر). تمام؟
auto-aliquot: موافق ننقله لزرار صريح / وقت إنشاء الطلب (بدل ما فتح الصفحة يعدّل بيانات)؟ ده تغيير سلوك محتاج تأكيدك.

ملخّص

الخطة بتكرّر نجاح الورك ليست على Samples/Reception. أقدر أبدأ بمرحلة 0 (الأمان) حالاً وأرجّعلك، وأكمّل الباك تدريجياً متحقَّق. مستني موافقتك على المسار + القرارات الـ3.