12 مرحلوں کا فارم۔ مشروط توثیق۔ پیچھے جانے کا بٹن لازماً کام کرے۔

مرحلہ گننے والا شمارندہ صرف ابتدا میں کافی تھا۔ پانچویں مرحلے تک بہاؤ، مقام، جمع شدہ ڈیٹا، توثیقی نقائص، لوڈنگ، مکمل مراحل اور مشروط ضروریات کا حساب رکھتا تھا۔ دسویں مرحلے تک ایک جزو تقریباً 800 سطروں کا ہوگیا اور 'کیا یہ صارف آگے بڑھ سکتا ہے؟' کا جواب چھ الگ جگہوں پر دیا جاتا تھا۔

بارہ اسکرینیں دکھانا سیدھا تھا۔ پہلے درج کیا گیا ڈیٹا کھوئے بغیر آگے، پیچھے، اسینکرونس اور جمع کرانے کی منتقلیاں ہم آہنگ رکھنا سیدھا نہیں تھا۔

useState نے فارم میں ایسی حالتیں یکجا ہونے دیں جو ساتھ نہیں ہونی چاہییں: لازمی ڈیٹا صاف ہونے کے بعد اگلی اسکرین پر پہنچ جانا، جمع کراتے وقت پیچھے جانا، یا دکھائی دینے والا مشروط خانہ خالی ہوتے ہوئے فارم کو درست قرار دینا۔ useReducer تازہ کاریاں ایک جگہ جمع کرسکتا تھا، مگر جب تک ہر شاخ منتقلی کا پورا نقشہ دوبارہ نہ بناتی، وہ ہر موجودہ مرحلے میں ریڈیوسر کے نافذ کردہ ہر ایکشن کو قبول کرتا رہتا۔

@xstate/react کے ساتھ XState v5 نے یہ نقشہ واضح کردیا۔ واقعہ پھر بھی بھیجا جاسکتا ہے، مگر غیر متعین یا گارڈ سے رد منتقلی، مشین کو نہیں چلاتی۔

مشین نے سات واقعات استعمال کیے: NEXT، PREVIOUS، GO_TO_STEP، UPDATE_FORM_DATA، SET_CREATED_BUYER_ID، SUBMIT اور RESET۔ سیاق میں currentStep، formData، errors، isLoading، investorId اور createdBuyerId تھے۔

CONTACT_PREFERENCES: {
  on: {
    NEXT: {
      target: 'TARGET_MARKETS',
      guard: 'CAN_PROGRESS_FROM_CONTACT_PREFERENCES'
    },
    PREVIOUS: 'INTRO',
    UPDATE_FORM_DATA: { actions: 'UPDATE_FORM_DATA' }
  }
}

NEXT پر گارڈ تھی۔ جمع کرانے کے عمل سے باہر PREVIOUS دستیاب رہا تاکہ صارف فارم کا سیاق صاف کیے بغیر پہلے کا ڈیٹا درست کرسکے۔ UPDATE_FORM_DATA نے صرف بدلے خانے جمع شدہ سیاق میں ملائے۔

گیارہ گارڈز نے CAN_PROGRESS_FROM_[STEP_NAME] طریقہ اپنایا۔ Zod اسکیما نے کم از کم ایک فون نمبر یا ای میل کا ہونا لازمی قرار دیا، اور امریکی فون نمبر درج ہونے پر ہی اس کی توثیق کی۔ ہدف منڈیوں، جائیداد کی اقسام اور حکمتِ عملیوں میں ہر ایک کے لیے انتخاب لازم تھا؛ رینج اسکرینز میں کم از کم قیمت یا زیادہ سے زیادہ قیمت میں سے ایک درکار تھی۔

const canGoNext = state.can({ type: "NEXT" })

CAN_PROGRESS_FROM_CONTACT_CARD: ({ context }) =>
  Boolean(context.createdBuyerId)

رابطہ کارڈ کا گارڈ ابتدا میں بلاشرط true واپس دیتا تھا۔ بعد کی اصلاح نے اسے createdBuyerId سے جوڑا تاکہ بیک اینڈ میں خریدار کامیابی سے بننے تک مشین وہ حالت نہ چھوڑے۔ اسی state.can({ type: "NEXT" }) معاہدے نے بٹن کی حالت اور خود منتقلی دونوں کو کنٹرول کیا۔

فارم نے رابطے کی تصدیق اور خریدار بنانے کے لیے جنریٹ شدہ APIs بھی شامل کیں۔ فون اور ای میل کی جانچ ڈی باؤنس کی گئی تھی، اور مسلسل بڑھتی درخواست ID نے نئی قدر داخل ہونے پر پرانا جواب رد کردیا۔ ہدف منڈی کی تجاویز مشین کے سیاق میں جانے سے پہلے مختصات کی بنیاد پر دہراؤ ہٹاتی تھیں۔

خریدار، رابطہ کارڈ کی حد پر بنتا تھا۔ SET_CREATED_BUYER_ID نے بیک اینڈ سے تصدیق شدہ ID کو مشین کے سیاق میں محفوظ کیا؛ بعد کی ترجیحی اسکرینوں نے اپنی API تازہ کاریوں کے لیے وہی ID استعمال کی۔

پرووائیڈر نے useMachine کو لپیٹا اور currentStep، formData، canGoNext، isSubmitting، handleNext، handlePrevious، handleUpdateFormData اور خریدار ID کا عمل فراہم کیے۔ ہر مرحلے کے اجزا نے خانے دکھائے اور پہلے یا بعد کا راستہ جانے بغیر تازہ کاریاں بھیجیں۔

نیویگیشن کی مالک مشین ہے۔ ہر React مرحلہ خانے دکھاتا، سیاق تازہ کرتا اور واقعات بھیجتا ہے۔ تین مراحل کے فارم کے لیے میں XState استعمال نہ کرتا؛ بارہ اسکرینوں، مشروط توثیق اور بیک اینڈ پر منحصر منتقلیوں نے یہاں واضح نقشے کی اضافی ترتیب کو مفید بنایا۔

اطلاق نے اسکیما اور براہ راست منتقلیوں کے لیے 538 سطروں کی اکائی جانچ شامل کی۔ ان آزمائشوں نے React اجزا ماؤنٹ کیے بغیر مشین میں واقعات بھیجے اور حالت کی تصدیق کی۔ مزید 359 سطروں کی Playwright جانچ نے مکمل بہاؤ، فون اور ای میل کے قواعد، بیک اینڈ میں خریدار کی تخلیق اور پیچھے جانے پر ڈیٹا کا تحفظ جانچا۔

• 12 مراحل
• سات واقعات
• آگے بڑھنے کی 11 نام زدہ گارڈز
• نیویگیشن کو قابو کرنے والی ایک مشین فائل
• اسکیما اور مشین آزمائشوں کو براؤزر تعامل کی آزمائشوں سے الگ رکھا گیا