Storybook yordamida yaratilgan mustaqil UI ishlab chiqish muhiti

1. Kirish

Loyiha rivojlanib borgani sari bitta ekranni yakunlash jarayoni ko‘pincha kutilganidan ko‘proq vazifalarga bo‘linadi.

Loyihalarda men ekran markupi, stillash va o‘zaro ta’sirlar kabi UI elementlarini amalga oshirish uchun mas’ulman. Avval nashr etish repositorysi va ishlab chiqish repositorysi jismonan alohida bo‘lgan, shuning uchun men faqat nashr etish repositorysi ichida ishlardim. Ekran markupi va stillar yakunlangach, developer ularni ishlab chiqish repositorysiga ko‘chirib, mantiq va API'larni qo‘shardi.

Biroq bu loyihadagi tuzilma boshqacha edi. Jarayon o‘zgardi: endi publisher to‘g‘ridan-to‘g‘ri ishlab chiqish repositorysida ishlashi, alohida branch ajratishi va developerlar bilan parallel ishlashi kerak edi. Bir xil repository va kod bazasidan foydalanish muayyan afzalliklarni berdi, ammo yangi qiyinchiliklarni ham yuzaga keltirdi. Bir xil repository ichida bir xil ekran ustida ishlayotgan bo‘lsak ham, bir-birimizning branchlarimizdagi ishlar merge qilinmaguncha, amalda yakunlangan ekranni birgalikda ko‘rish qiyin edi.

Nashr etish branchida ishlayotganimizda API hali tayyor bo‘lmasligi yoki boshqa branchda ishlab chiqilayotgan state boshqaruvi logikasi hali tugallanmagan bo‘lishi mumkin edi.

Ushbu maqolada bitta repository ichida nashr etish va ishlab chiqish ishlari branchlar bo‘yicha alohida olib boriladigan muhitda UI'ni mustaqilroq ishlab chiqish va ko‘rib chiqish uchun Storybook'ni qo‘llash tajribamni, shuningdek, amaliy amalga oshirish jarayonida duch kelgan muammolarimni umumlashtirmoqchiman.

2. Muammoni aniqlash: Bitta ekranni ko‘rib chiqish uchun nimalar kerak

Ish bir xil repository ichidagi branchlar bo‘yicha taqsimlangani sababli, “merge qilganimiz zahoti uni ko‘rishimiz kerakdek tuyuladi, ammo amalda bunday emas” degan asabiylashtiruvchi vaziyat yuzaga keldi. Mening branchimdagi markup va development branchidagi mantiq hali merge qilinmaganida, yakunlangan ekranni birgalikda ko‘rib chiqishning amaliy usuli yo‘q edi.

Bunday holatda muayyan ekranni haqiqiy muhitda ko‘rib chiqish uchun bir nechta shartlar talab qilinardi.

Avvalo, tegishli ekranni o‘z ichiga olgan development muhitini ishga tushirishimiz kerak edi, ayrim hollarda esa bir nechta ilova yoki development serveri birgalikda ishlashi kerak bo‘lardi. Bundan tashqari, tizimga kirilgan holat yoki API javoblarini talab qiladigan ekranlar uchun kerakli holatni yaratish maqsadida haqiqiy ma’lumotlarni tayyorlashimiz kerak edi.

Biroq hali merge qilinmagan branchda ishlayotganimizda, bu shartlar har doim ham tayyor bo‘lmasdi.

Masalan, API spetsifikatsiyasi aniqlangan bo‘lishi mumkin, ammo haqiqiy server hali amalga oshirilmagan bo‘lardi yoki muayyan holat uchun ma’lumotlarni ataylab yaratish qiyin bo‘lishi mumkin edi. Bo‘sh ro‘yxatlar, muayyan tugmalarni ko‘rsatish shartlari, arizani yakunlash holatlari va xatolik holatlarini shunchaki haqiqiy servisni ishga tushirish orqali ko‘rib chiqish har doim ham oson emasdi.

Natijada, hatto oddiy UI holatini tekshirish uchun ham butun development muhitini ishga tushirishimiz, kerakli ekranga o‘tishimiz va keyin muayyan shartlarni yaratishimiz kerak edi.

Bu jarayon quyidagi muammolarni keltirib chiqardi.

• Nashr etish ishlari development muhitining tayyorligiga bog‘liq bo‘lib qoldi.
• Muayyan UI holatlarini qayta-qayta yaratish qiyin edi.
• API ma’lumotlari har safar o‘zgarganida, ekranni ko‘rib chiqish jarayoni ham ta’sirlanardi.
• Ekran holatini ko‘rib chiqish uchun har safar development jamoasi ma’lumot yoki muhitni tayyorlashini kutishimiz yoki buni so‘rashimiz kerak edi.

Ayniqsa UI ishi nafaqat odatiy holatlarni, balki bo‘sh, istisno va yuklanish holatlari kabi turli vaziyatlarni ham ko‘rib chiqishni talab qiladi. Biroq haqiqiy development muhitida bu holatlarni har safar ataylab yaratish qo‘shimcha vaqt talab qilardi.

Shu sababli bizga ekranlarni shunchaki alohida ko‘rsatish usuli emas, balki muayyan komponentlar va ekranlarning holatlarini istalgan vaqtda izchil tarzda qayta yaratish mumkin bo‘lgan muhit kerak edi.

3. Yechim: Storybook yordamida mustaqil UI ishlab chiqish muhitini yaratish

Bu muammoni hal qilish uchun Storybook'ni qo‘lladim.

Asosiy maqsad API hali tayyor bo‘lmaganida — yoki hatto development muhiti orqali tizimga kirib, ekranga kirishning iloji bo‘lmagan eng og‘ir holatlarda ham — development jamoasidan ma’lumot yoki muhitni so‘ramasdan, ekran holatlarini darhol lokal kompyuterimda tekshira olish edi.

Storybook komponentlarni ilovaning umumiy muhitidan alohida tarzda mustaqil render qilish va ko‘rib chiqish imkonini beradigan vositadir. Biroq undan shunchaki komponentlar ro‘yxatini ko‘rish uchun foydalanish o‘rniga, loyiha UI'sini amalda ishlab chiqish muhitiga imkon qadar o‘xshash muhit yaratishni maqsad qildim.

Bunga erishish uchun uni quyidagi asosiy tamoyillar asosida sozladim.

• Storybook'da haqiqiy loyihadagi Vite konfiguratsiyasidan foydalanish
• Haqiqiy ilovada ishlatiladigan Provider muhitini qayta yaratish
• Development jamoasining API yoki login muhiti tayyor bo‘lmaganida ham, so‘rovlarsiz ekran holatlarini darhol lokal kompyuterimda tekshirish imkonini yaratish

3.1 Haqiqiy loyiha muhitini Storybook muhiti bilan moslashtirish

Storybook'ni alohida muhit sifatida sozlash qulay, ammo uning sozlamalari haqiqiy ilova sozlamalaridan farq qilsa, bu qo‘shimcha muammolarni keltirib chiqarishi mumkin.

Masalan, Storybook'da biror narsa to‘g‘ri ko‘rinishi, haqiqiy ilovada esa alias yoki style sozlamalari boshqacha qo‘llanilishi mumkin.

Bu tafovutni kamaytirish uchun loyihani amalda ishlatilayotgan Vite sozlamalaridan Storybook'da ham foydalanish mumkin bo‘ladigan qilib sozladim.

framework: {
  name: '@storybook/react-vite',
  options: {},
},
viteFinal: async (config) => {
  const { config: userConfig } = await loadConfigFromFile(
    path.resolve(__dirname, '../vite.config.mts'),
  );
  return mergeConfig(config, {
    ...userConfig,
    resolve: {
      alias: {
        '~': path.resolve(__dirname, '../src'),
      },
    },
  });
},

Ushbu konfiguratsiya yordamida haqiqiy loyihada ishlatiladigan alias va style'larni qayta ishlash usuli kabi sozlamalarni Storybook'da ham imkon qadar izchil saqlash mumkin bo‘ldi.

Bundan tashqari, haqiqiy ilovada ishlatiladigan Provider muhitini Storybook'ning preview sozlamalarida ham konfiguratsiya qildim.

Masalan, mavzularni ta’minlaydigan Provider, ma’lumotlar so‘rovlarini boshqaradigan Provider va bildirishnoma xabarlarini qayta ishlaydigan Provider'ni ham Storybook muhitiga qo‘lladim.

Bu jarayon shunchaki Storybook'ni ishga tushirish uchun konfiguratsiya qilish emas, balki Storybook va haqiqiy ilova o‘rtasidagi farqlarni kamaytirishga qaratilgan ish edi.

UI'ni mustaqil ko‘rib chiqish uchun muhit yaratgan bo‘lsak-da, agar u haqiqiy ilovadan juda farq qilsa, oxir-oqibat tekshiruvni ikki marta bajarishimizga to‘g‘ri kelardi.

3.2 API'ga bog‘liqlikni kamaytirish uchun Mock ma’lumotlarini sozlash

Storybook'ni qo‘llashda men eng muhim deb hisoblagan jihat API'ga bog‘liqlikni kamaytirish edi.

Ko‘plab haqiqiy ekranlar serverdan olinadigan ma’lumotlar asosida quriladi. Shu sababli Storybook'da komponentlarni shunchaki render qilish turli holatlarni yetarli darajada qayta yaratishni qiyinlashtirdi.

Dastlab kerakli ma’lumotlarni har bir Story faylining o‘zida to‘g‘ridan-to‘g‘ri yozib chiqishni ko‘rib chiqishimiz mumkin edi.

export const Default = {
  args: {
    data: {
      // Story마다 필요한 Mock 데이터 작성
    },
  },
};

Biroq ekranlar soni oshib, holatlar xilma-xil bo‘lib borgani sari bir xil yoki o‘xshash Mock ma’lumotlarining bir nechta Story'lar bo‘ylab takrorlanish ehtimoli ham ortdi.

Shu sababli Mock ma’lumotlarini vazifasiga ko‘ra ajratadigan yondashuvni qo‘lladim.

src
 └── mocks
      ├── fixtures
      └── handlers

fixtures ichida ekranlar foydalanadigan namunaviy ma’lumotlarni tartibga soldim, handlers ichida esa haqiqiy API so‘rovlarini ushlab qolish va kerakli ma’lumotlarni qaytarish uchun tizimni sozladim.

Bu bitta ekran uchun bir nechta holatni nisbatan aniq ajratish imkonini berdi.

Masalan, uni quyidagicha sozlash mumkin edi.

화면
 ├── 기본 상태
 ├── 빈 상태
 ├── 특정 조건 상태
 └── 에러 상태

Storybook'da har bir holatni mustaqil Story sifatida yaratdim, shunda uni darhol ko‘rib chiqish mumkin bo‘ldi.

Natijada, haqiqiy backend tayyor bo‘lmaganida ham UI ustida ishlashni davom ettira oldim, shuningdek, muayyan holatni tekshirmoqchi bo‘lganimda har safar haqiqiy muhitda ma’lumot yaratish zaruratini kamaytirdim.

4. Amaliy amalga oshirish jarayonida duch kelgan muammolar

Storybook'ni qo‘llash nashr etish va development o‘rtasidagi barcha muammolarni hal qilmadi.

Aksincha, Storybook’ni haqiqiy loyihaga qo‘llash ilgari deyarli sezilmagan muammolarni yanada yaqqol ko‘rsatdi.

4.1 Komponent nomlarini o‘zgartirish sababli yuzaga kelgan Story xatolari

Loyiha rivojlanishi davomida komponentlarning rollarini aniq farqlash uchun nomlashni tartibga solish ustida ishladik.

Mavjud komponent nomlariga ularning rollarini ajratuvchi suffikslar qo‘shilgach, bir nechta fayl nomlari va ularning import yo‘llari o‘zgardi.

Masalan, quyidagiga o‘xshash o‘zgarishlar yuz berishi mumkin.

JobDetail
↓
JobDetailWkr

Bu jarayonda avval yozib bo‘lingan Story fayllaridagi import yo‘llari ham ta’sirlandi.

// 변경 전
import { JobDetail } from './JobDetail';
 
// 변경 후
import { JobDetail } from './JobDetailWkr';

Bitta komponent nomini o‘zgartirishning o‘zi katta vazifa bo‘lmasligi mumkin. Biroq Story fayllari ushbu komponentga murojaat qilsa, o‘zgarishlar ko‘lami kutilganidan kengroq bo‘lishi mumkin.

Agar nashr qilish va ishlab chiqish repozitoriylari avvalgidek alohida qolganida, bu o‘zgarishni ish natijalarini qaytadan olib kelgunimcha aniqlamagan bo‘lardim. Biroq bir xil repozitoriy ichidagi branchlarda ishlaganim sababli, ishlab chiqish branchidagi o‘zgarishlar birlashtirish vaqtida darhol konflikt sifatida yuzaga chiqdi va ularni shu zahoti muvofiqlashtirishga to‘g‘ri keldi.

Bu tajriba orqali Storybook haqiqiy loyiha kodidan ajratilgan alohida deliverable emas, balki loyiha tuzilmasidagi o‘zgarishlar ta’sir qiladigan kod ekanini angladim.

Shuningdek, fayl tuzilmasi yoki nomlash kabi bir nechta kishiga ta’sir qiladigan o‘zgarishlar imkon qadar oldindan ulashilishi kerakligini his qildim.

Story fayllarini qo‘llab-quvvatlaydiganlar uchun hatto ozgina oldindan berilgan xabarning o‘zi ham keraksiz o‘zgartirish ishlarini kamaytirishi mumkin.

4.2 Storybook’da hamma narsani tekshirib bo‘lmasdi

Storybook’ni qo‘llash davomida aniq anglagan narsalarimdan biri shuki, u haqiqiy ilovani to‘liq almashtiradigan vosita emas.

U komponent darajasida UI holatlarini tekshirish uchun juda samarali bo‘lsa-da, bir nechta ekranlarni bog‘laydigan oqimlar va haqiqiy muhitga bog‘liq funksiyalar alohida tekshiruvni talab qildi.

Masalan, bunga quyidagi sohalar kiradi.

• Ekranlar o‘rtasida navigatsiya
• Bir nechta ilova o‘rtasida almashish
• Haqiqiy API javoblarini UI’ga ulash
• Faqat haqiqiy ishga tushirish muhitida yuzaga keladigan muammolar
• Tashqi muhitlar bilan xabarlarni qayta ishlash

Bu jihatlarni Storybook’ning mustaqil muhitida tekshirish qiyin edi yoki alohida Mock implementatsiyalarini talab qildi.

Dastlab, imkon qadar ko‘proq ekranlarni Storybook’da foydalanish mumkin holga keltirish eng yaxshi yo‘l deb o‘yladim. Biroq uni amalda qo‘llaganimdan so‘ng, hamma narsani Storybook’ga ko‘chirishning o‘zi maqsadga aylanmasligi kerak degan xulosaga keldim.

Oxir-oqibat, ularning rollarini farqlash samaraliroq bo‘lib chiqdi.

Storybook
→ 컴포넌트 및 화면의 상태 확인
→ UI 리뷰
→ 다양한 데이터 상태 재현
→ 퍼블리싱 결과 공유
 
실제 개발 환경
→ 화면 간 이동 확인
→ 실제 API 연동 확인
→ 전체 사용자 흐름 확인
→ 실제 실행 환경 검증

Storybook va haqiqiy ilovani raqobatchilar sifatida ko‘rishdan ko‘ra, ulardan turli maqsadlarga ega tekshiruv muhitlari sifatida foydalanish ma’qulroq edi.

5. Joriy etishdan oldingi va keyingi taqqoslash

Kategoriya	Avvalgi yondashuv	Storybook joriy etilgandan keyin
Bajarish birligi	Butun ishlab chiqish muhitini ishga tushirish talab qilinardi	Faqat kerakli komponent yoki ekranni ishga tushirish
Ma’lumotlarni tayyorlash	Haqiqiy API va tizimga kirish holatiga bog‘liq edi	Kerakli holatni Mock ma’lumotlari bilan sozlash
Holatni qayta yaratish	Muayyan holatni qo‘lda yaratish kerak edi	Har bir Story uchun holatni darhol tekshirish
UI’ni tekshirish	Kerakli ekranga navigatsiya qilish talab qilinardi	Tegishli Story orqali bevosita kirish
Qayta tekshirish usuli	Ssenariyni har safar takrorlash kerak edi	Saqlangan Story yordamida uni darhol qayta yaratish
Mos sohalar	Umumiy oqim va haqiqiy integratsiyalarni tekshirish	UI holatlari va komponentlarni tekshirish

Storybook joriy etilgandan keyingi eng katta o‘zgarish shunchaki ekranlarni ko‘rish osonlashgani emas edi.

Avval muayyan ekran holatini tekshirish uchun dastlab muhitni tayyorlash va o‘sha holatni yaratish kerak bo‘lardi.

Biroq Storybook yordamida kerakli holatning o‘zini bitta Story sifatida yaratish mumkin bo‘ldi.

Boshqacha aytganda, ekranni tekshirishga tayyorgarlik jarayoni qisqardi va holat bir marta aniqlangach, undan keyin uni izchil ravishda qayta yaratish mumkin bo‘ldi.

6. Ushbu tajribadan olingan saboqlar

6.1 Storybook’ning eng katta kuchi UI’ning o‘zini emas, balki holatlarni qayta yaratishida edi

Dastlab Storybook’ni komponentlarni izolyatsiya qilingan holda tekshirish vositasi deb o‘ylagandim.

Biroq uni haqiqiy loyihada qo‘llaganim sari, uning eng katta kuchi muayyan holatlarni qayta-qayta yaratish imkoniyati ekanini tushundim.

Oddiy holatlardan tashqari, real muhitda yaratish qiyin bo‘lgan bo‘sh ekranlar yoki xatolik holatlari kabi vaziyatlarni ham belgilashim mumkin edi.

Story yaratilgandan keyin bir xil holatni saqlab qolgani sababli, undan UI’ni o‘zgartirish va ko‘rib chiqish jarayonlarida qayta-qayta foydalanish mumkin edi.

6.2 Rivojlantirish muhiti tayyor bo‘lmaganda ham ishlashni davom ettira oldim

Kutilganidan ko‘ra ko‘proq hollarda branch hali birlashtirilmagan yoki, yanada jiddiy vaziyatlarda, hatto rivojlantirish muhiti orqali tizimga kira olmay, ekranga kira olmagan paytlarim bo‘ldi.

Ilgari bunday vaziyatlarda rivojlantirish jamoasidan ma’lumotlar yoki akkaunt holati haqida ma’lumot so‘rashim yoki muhit normal holatga qaytgunga qadar ishimni kechiktirishim kerak bo‘lardi.

Biroq Storybook’dan Mock ma’lumotlar bilan birga foydalanishni boshlaganimdan so‘ng, bunday vaziyatlarda ham kerakli ekran holatlarini bevosita mahalliy muhitimda yaratish va tekshirishim mumkin bo‘ldi. Kerakli ma’lumotlarni so‘ramasdan yoki muhit tiklanishini kutmasdan UI ustida ishlashni davom ettira oldim.

Ushbu tajribadan anglaganim shuki, Storybook’ning qiymati ekranlarni chiroyli ko‘rsatishdan ko‘ra, ishimni loyihaning boshqa qismlari tayyorligiga imkon qadar kamroq bog‘liq holda olib borishimga yordam berishidadir.

6.3 Maqsad Storybook’da har bir ekranni yaratish emas edi

Storybook’ni qo‘llash davomida eng muhim masala vositadan qanchalik keng foydalanganim emas, balki undan qayerda eng samarali foydalanish mumkinligi bo‘ldi.

Storybook UI holatlari ko‘p bo‘lgan va ularni haqiqiy ma’lumotlarsiz yetarlicha tekshirish mumkin bo‘lgan ekranlar uchun juda samarali edi.

Boshqa tomondan, bir nechta ekranlar o‘rtasidagi oqim yoki haqiqiy muhit bilan integratsiya muhim bo‘lgan funksiyalarni mavjud rivojlantirish muhitida tekshirish ma’qulroq edi.

Shu sababli har bir ekranni bir xil usulda boshqarish o‘rniga, parallel rivojlantirish jarayonida tekshirish xarajati eng yuqori bo‘lgan ekranlarni avval Storybook’ga ajratish samaraliroq bo‘ladi, degan xulosaga keldim.

7. Xulosa

Ushbu tajriba orqali Storybook shunchaki UI komponentlarini ko‘rsatish vositasi emasligini angladim. U rivojlantirish muhiti hali tayyor bo‘lmagan paytda ham menga topshirilgan UI ishlarini mustaqil ravishda tekshirish imkonini beruvchi verifikatsiya muhiti sifatida ham xizmat qilishi mumkin.

Ayniqsa, API yoki tizimga kirish kabi rivojlantirish tomonidagi resurslar tayyor bo‘lmagan vaziyatlarda undan Mock ma’lumotlar bilan birga foydalanish samarali bo‘ldi, chunki rivojlantirish jamoasiga so‘rov yubormasdan yoki kutmasdan, muayyan holatlarni qayta-qayta yaratish orqali ishlashni davom ettira oldim.

Albatta, Storybook har bir muammoni o‘zi mustaqil hal qila olmaydi. Haqiqiy API integratsiyasi, ekranlar o‘rtasidagi oqimlar va bajarilish muhitiga bog‘liq funksiyalar hali ham haqiqiy rivojlantirish muhitida tekshirilishi kerak.

Biroq hamma narsani bitta muhitda hal qilishga urinish o‘rniga, vazifalarni ajratish samaraliroq bo‘ldi: UI holatlarini Storybook’da tekshirish, haqiqiy oqimlar va integratsiyalarni esa haqiqiy ilovada verifikatsiya qilish.

Oxir-oqibat, ushbu tajribadan olgan eng katta sabog‘im shuki, muayyan vosita sifatidagi Storybook’ning o‘zidan ko‘ra, ishim loyihaning boshqa qismlari tayyorligidan qanchalik mustaqil ravishda davom etishi mumkinligi muhimroq savoldir.

Kelajakda yangi loyihalar ustida ishlaganimda, har bir ekranni boshidan Storybook’da yaratish o‘rniga, rivojlantirish muhiti yoki ma’lumotlarga kuchli bog‘liqligi sababli UI’ni tekshirish qimmatga tushadigan sohalarga ustuvor ahamiyat berishni rejalashtiryapman. Shu tarzda to‘plangan Stories shunchaki sinov ekranlari emas, balki UI’ni tekshirish va u haqida fikr almashish uchun umumiy standart bo‘lib xizmat qilishi mumkin, deb hisoblayman.

tabiat