blog

Merosi ma'lumotlarning o'zgarishi

NEXTREE.

• 5 min read
Merosi ma'lumotlarning o'zgarishi

- Zamonaviy tuzilishga o'tkazish uchun vanilla JS asosidagi so'rovnoma shaklini ishlab chiqish-

Ushbu postda men yaqinda amalga oshirilgan loyiha doirasida o‘tkazilgan so‘rovnoma shakli tahrirchisi rivojlantirish tajribasi va uning asosiy arxitekturasi bilan o‘rtoqlashmoqchiman.

1. Foni va muammo vaziyati

Mavjud tizimda mavjud bo'lgan so'rovnoma shakli oddiy JavaScript (Vanilla JS) dan foydalanib, ekranni bevosita HTML ga chizish va har bir ob'ektga berilgan noyob raqamli ID asosida DOM ni topib kodni yuborish orqali juda an'anaviy usulda yaratilgan edi. Ushbu meros tuzilishi faqatgina ekranda so'rovni tasvirlash va javob berishda muammo tug'dirmasa-da, hal qiluvchi muammo bor edi. Bu aniq Ahamiyati savol va javoblarining qatlamli tuzilmasini yozingyangio'rganilgan ma'lumotlar orqali tushunishqiyin qiyin edi, Olingan ma'lumotlarni statistika va vizualizatsiya uchun qayta ishlashda juda qiyin edi.

Shunday qilib, oddiygina legasini React-ga o‘tkazishdan tashqari, mavjud maydonga qo‘yilgan va parchalangan ma’lumotlarni haqiqiy savol-javob tuzilishiga (Label, Question, Option) mos keladigan zamonaviy tuzilishga o‘zgartiradigan yangi format tahrirlovchisi kerak edi.

2. Tahrirlovchi komponent arxitekturasi va qat’iy qiziqishlardan ajratish

Murakkab ma'lumotlarni boshqaradigan tahrirlovchi sifatida, eng muhim qism shundaki, Har bir tahrir bosqichida biznes mantiq va ekran holatlari aralashmasligi uchun komponentlarni qat'iy ajratishdiredi.

Umumiy muharrir oqimi va tabni o'zgartirish eng yuqori darajadagi konteyner bo'lgan TemplateEditorContainer tomonidan boshqariladi va uning ostida har bir bosqich uchun wrapper komponentlar mustaqil ravishda joylashtirilgan tuzilma mavjud.

  • QADAM 01. FormMapping: Meros elementiga belgi, savol, javob kabi xususiyatlarni belgilovchi bosqich
  • QADAM 02. FormGrouping: elementlar o'rtasidagi mantiqiy qatlam va guruhlarni bog'lash bosqichi
  • QADAM 03. Qoidalar tayyorlash: Dinamik hodisalar va hisoblash mantiqini ta'minlaydigan bosqich

[Mapper va Formning ajralishi]Har bir bosqichning wrapper komponentiga kirganingizda, ekran yana chap tomondagitahrirlash yon paneli (Mapper)va o'ng tomonda format ekrani (Form)View komponentiga bo'lingan. Mapper STEP bo'yicha to'liq o'ziga xos, lekin Form oddiy render komponenti sifatida toza saqlanib, qayta ishlatish mumkinligini oshirdi.

  • MapperElementning xususiyatlarini o'zgartirish yoki harakatlarni beruvchi manipulyatsiya UI'si.
  • FormAslida so'rovnomalar tasavvur qilinadi va muharrir burchagida elementlarni to'g'ridan-to'g'ri bosish orqali tanlash mumkin bo'lgan asosiy ekran.

[Nima uchun buni shunday loyihalashtirdik?]Tahrirchi foydalanuvchining bosish va kiritishiga qarab ko'plab holat (State) o'zgarishlari yuz beradi. Ekranda chizilgan elementlar soni ko'p va har bir elementning o'ziga xos uslubi yoki holat qiymatlari ko'pdir.

Agar buni bitta komponent yoki bo'shashgan tuzilma ichida to'liq hal qilingan bo'lsa, 'elementni belgilash' bosqichidagi kod 'qoidalarni yaratish' bosqichida istalmagan yon ta'sirlarni yuzaga keltirishi yoki holatni qayta ishlash samaradorligi pasayib, ekran juda sekinlashishi xavfi juda katta bo'lar edi.

Har bir tahrir bosqichida (STEP 01~03) mutlaqo mustaqil qoplama komponentlarini tashkil etib, u yerda Mapper va Formni kombinatsiyalash usulini tanlash orqali, ma'lum bir bosqichning domen mantiqining boshqa bosqichga kirib borishini to'liq bartaraf etdik. Bu, kodning murakkabligini pasaytirishga va texnik xizmat ko'rsatish hamda rendituvchanlik barqarorligini sezilarli darajada oshirishga yordam berdi.

Shuningdek, ma'lumotlar oqimi element o'zgarishi (React State) → qo'llash (React Hook Form orqali o'rta holatni ushlab turish) → saqlash (RHF qiymatini server API standartiga aylantirib jo'natish) bosqichlariga optimallashtirildi, quyi komponentlar esa qayta foydalanish imkoniyatlarini hisobga olib, to'g'ri ajratildi va useCallback hamda memo to'g'ri foydalanilib, og'ir sahnalarda yuk ko'taradigan keraksiz qayta rendituvni oldini oldik.

3. 3-bosqich ma'lumotlar strukturalash jarayoni

O'tgan DOMga bog'liq ma'lumotlarni strukturaviy statistik ma'lumotlarga aylantirish jarayoni uchta asosiy bosqichga (Step) bo'lingan holda amalga oshiriladi.

1-QAT'AM. Elementni belgilash (Mapping) Avvalambor, ichki bo'lmagan sirtma (Flat) shakldagi merosiy ma'lumotlarni belgi (Label), savol (Question), variant (Option) dan biriga moslashtiramiz. Savol - foydalanuvchidan to'g'ridan-to'g'ri javob so'raydigan element, variant esa o'sha javobning haqiqiy 'qiymatini' anglatadi. Xususan, javob qiymatini olish uchun, ushbu elementni albatta 'variant' sifatida belgilashda qat'iy shart qildik, shunda ma'lumotlarning yaxlitligini ta'minladik.

Qadam 02. Guruh yaratish (Grouping) Belgilangan elementlarni bir joyga to'plab, mantiqiy qatlam yaratamiz. Bog'liq savollarni bitta karta ko'rinishi (bo'lim) orqali birlashtiruvchi 'guruh tuzish', bitta savolga bir nechta javoblarni birlashtiruvchi va avvalgi tasodifiy JavaScript yordamida alohida boshqariladigan Radio ishlashini RadioGroupga belgilash imkonini beruvchi 'javob guruhi', elementlarni vizual ravishda tartibga solish bilan birga, shuningdek, shunday joylashgan elementlarni harorat ko'rsatkichi, slayder, jadval shaklida belgilashga imkon beruvchi 'bir qator joylash' funktsiyasi orqali ma'lumotlarning qatlam tuzilishi va UI ning mukammalligi, so'rovlar foydalanish qulayligini bir vaqtning o'zida yaxshilandi.

STEP 03. Qoidalarni yaratish (Rule Making) Statik so'rovga dinamik harakat (logika) beriladi. Me'yoriy elementning o'zgarishiga qarab boshqa ob'ektlarni boshqaradigan 'voqealar' (masalan: boshqa elementni belgilaganda kiritish oynasini faollashtirish) va ma'lum javoblarning statik hamda dinamik raqam qiymatlarini olib, ularni yig'ish yoki ball to'plash imkoniyatini beruvchi ' hisoblash' funksiyasi amalga oshirildi.

4. Asosiy muammo yechimi: Ikki xil ID tizimini aralashtirish

Ushbu loyihada eng ko'p o'ylangan jihatlardan biri Identifikator(ID) tizimiAvvalgi meros tizimidan o'tgan elementlar mavjud bo'lgan noyob raqamga (masalan: formClauSn) ega edi. Ammo yangi zamonaviy arxitekturada strukturaviy L/Q/O har bir holatini aniqlash uchun yangi identifikator (UUID) kerak edi.

Agar foydalanuvchi tahrirlovchi elementni 'savol'dan 'yorliq'ga o'zgartirsa, elementning tabiati o'zgaradi va yangi UUID beriladi. Bunday holatda, ilgari ushbu elementga qo'yilgan 'qoidalar' maqsadlarini yo'qotishi va ishlamasligi mumkin bo'lgan jiddiy muammo paydo bo'lishi mumkin. Buni oldini olish uchun tahrirlovchi ikkita ID'ni maqsadga ko'ra ajratib ishlatdi.

  1. templateItemIdBu, mavjud meros tizimining identifikatoriga asoslangan o'zgarmas qiymatdir. Elementni belgilash (Mapping) bosqichi va qoidalar yaratish (Rule) bosqichida, elementning xussusiyati o'zgarishi mumkin bo'lsa-da, mavjud qoidalar saqlanishi uchun bu o'zgarmas qiymat identifikator sifatida mustahkamlandi.
  2. id (UUID): Guruh yaratish (Grouping) bosqichidan boshlab, yangi ma'lumot arxitekturasi uchun UUIDni identifikator sifatida foydalanish tabiiy ravishda amalga oshirildi.

5. Kod darajasidagi ma'lumotlarni uzatishni amalga oshirish

Ma'lumotlarni manipulyatsiya qilishni frontend muhitiga mos ravishda silliq tarzda amalga oshirish uchun TypeScript'ni to'liq joriy etib, maxsus hook'larga asoslangan ma'lumotlar uzatish tizimini yaratdik. Tahrirlovchiga kirish vaqtida, backend'dan eskirgan ma'lumotlarni olish va frontend'da qulay ishlash uchun qayta ishlash funksiyasi logikasi quyidagicha.

export const findQuestionnaireEditingViewByQuestionnaireTemplateId = async (payload: {
  questionnaireTemplateId: string;
}): Promise => {
  const url = `${templateLoadResource}/find-questionnaire-template-editing-view-by-questionnaire-template-id/query`;
  const response = await surveyAxios.post(url, payload);
  return transformTemplateTextAlign(response.data);
};

Shuningdek, qoidalar tahrirlash jarayonida yuzaga keladigan CUD ishlarini React Query yordamida deklarativ ravishda server holatini boshqarish uchun ishlatdik.

export const useRuleDeleteMutation = (questionnaireTemplateId: string) => {
  const queryClient = useQueryClient();
  return useMutation({
    mutationFn: (payload: RemoveItemRuleCommand) => removeItemRule(payload),
    onSuccess: () => {
      queryClient.invalidateQueries({
        queryKey: ruleQueryKeys.list(questionnaireTemplateId),
      });
    },
  });
};

Xulosa qilib

O'tmishdagi vanilla JavaScript'ning DOM manipulyatsiyasi bilan yopilgan meros uchun shakllarni zamonaviy frontend tuzilmasiga o'tkazish va statistik jihatdan qiymatli 'ma'lumot'ga aylantirish ushbu loyiha juda qiziqarli muhandislik chaqiruv bo'ldi. Kelajakda o'xshash migratsiyalar yoki murakkab editor ko'rinishlarini loyihalashda, ushbu tajriba foydali ma'lumot bo'lishini umid qilaman!

Hazel

Site footer