1. Fon va muammolar holati
A loyihada foydalanuvchi faoliyat ma'lumotlarini yillik ravishda vizualizatsiya qilish uchun 365 kunlik issiqlik xaritasi UI ni amalga oshirish talabi mavjud edi.
Dastlab, faqat "isitma xaritasi" degan umumiy tushuncha haqida o'ylab, loyihaga allaqachon kiritilgan ApexCharts-dan foydalanish eng samarali tanlov deb hisobladim.
Allaqachon faoliyat yuritayotgan grafiklar kutubxonasidan foydalangan holda yangi bog'liqliklarni qo'shmaslik va dastlabki rivojlanish tezligi jihatidan ham qulay bo'lishini o'yladim.
Lekin haqiqiy amalga oshirish jarayoni davomida, issiq xaritalarda aniq turlar va maqsadlar farqi mavjudligini sezdim. Dastlab, ma'lumotlarni ranglar orqali ifodalash, hamma bir xil issiq xarita deb hisobladim, ammo aslida ma'lumot modeli va render qilish usuli bir-biridan farq qiladigan tuzilmalarga ega edi.
Issiq xaritalar odatda uchta asosiy turga bo'linadi.
Birinchisi statistika va tahlil maqsadlari uchun keng qo‘llaniladigan grid asosidagi issiqlik xaritasi.
Bu usulda X va Y o‘qlarining aniq kategoriyalari mavjud bo‘lib, ma'lum bir koordinataning qiymatini ranglar bilan ifodalaydi.
Masalan, hafta kunlariga qarab vaqtni ishlatish, mahsulotlar bo'yicha sotuvlar taqqoslash, bo'limlar bo'yicha natijalarni taqqoslash kabi shakllar namoyish etiladi.
Ikkinchisi esa sanalar oqimi asosida ma'lumotlarni ifodalovchi vaqtli kalendar issiq xaritasi hisoblanadi.
GitHub Contribution Graph ga o'xshash shakl birlamchi misoldir va sana asosidagi oqim o'ziga xos ma'lumot modelini tashkil etadi. Faqatgina koordinatalarni ko'rsatish bilan cheklanib qolmasdan, “vaziyat” tushunchasi markazda joylashgan.
Uchinchi xarita yoki joylashuvga asoslangan ma'lumotlarda qo'llaniladigan zichlik isitma xaritasi.
Bu ma'lum bir koordinatda ma'lumotlar qanchalik zich joylashganligini vizual ravishda ifodalash usuli bo'lib, odatda GIS yo'nalishidagi xizmatlarda keng qo'llaniladi.
Muammo ApexChartsning an'anaviy grid issiq xarita dvigateliga ega ekanidan iborat edi.
Ya'ni, koordinatalarga asoslangan ma'lumotlarni vizualizatsiya uchun optimallashtirilgan edi, lekin sana oqimiga asoslangan vaqt seriyali kalendari issiq xaritasi uchun mos kelmaydigan tuzilma edi.
O'sha paytdagi amalga oshirilishi lozim bo'lgan narsa 365 kun ma'lumotlarini hafta asosida joylashtirish kerak bo'lgan kalendar issiq xaritasi shakli edi.
Lekin ApexCharts o'z navbatida sanani tanimaydi va faqat oddiy koordinata ma'lumotlari sifatida ishlaydi, shuning uchun sana ma'lumotlarini grafik tushunishi mumkin bo'lgan shaklga bevosita o'tkazish zarur bo'ldi.
Natijada 1 yillik ma'lumotlarni 7 qatorda 52 ustunli tuzilishda koordinatalarga o'zgartirish uchun alohida oldindan ishlov berish lozim edi.
Masalan, ma'lum bir sananing qaysi hafta ekanini, qanday kun ekanini va qaysi koordinatalarga joylashtirilishi kerakligini hammasini to'g'ridan-to'g'ri hisoblashim kerak edi. Ijro etish mumkin edi.
Lekin muammo shundaki, kutubxonaning loyihalash maqsadi va haqiqiy foydalanish usuli mos kelmas edi. Aslida statistik maqsadlar uchun loyiha qilingan grid diagramma dvigateliga taqvim tushunchasini majburan bog'lash natijasida keraksiz ma'lumotlarni qayta ishlash logikasi doimiy ravishda qo'shildi.
Xususan, sanaqlar ma'lumotlarini koordinatalarga aylantirish jarayonida istisno berish kodi ko'paydi va oy chegarasi yoki kabisa yili hisobga olish kabi qo'shimcha mantiq ham zarur bo'ldi.
Bu jarayonda oddiy interfeysni amalga oshirishdan tashqari, xizmat ko'rsatish xarajatlari ortib borishi boshlandi. Bir funktsiyani qo'shish bilan birga, grafik ma'lumotlar struktura va sana hisoblash mantiqi bir vaqtning o'zida ta'sir ko'rsatdi va natijada kodning murakkabligi tezda oshdi.
Shuningdek, loyiha oxiriga kelgan sari “hozirgi amalga oshirish usuli haqiqatan ham uzoq muddatda saqlanadigan tuzilma bormi?” degan fikr ko'proq o'zlarini tashvishlantira boshladi. Faqat amalga oshirish mumkinligi nuqtai nazaridan texnologiya tanlash, keyinchalik ishga tushirish bosqichida katta xarajatlar paydo bo'lishi mumkinligini his etdim.
2. Vaqt ketma-ketligi kalendari issiq xaritasi amalga oshirish jarayonida yuzaga kelgan tuzilma cheklovlari
Keyin korporativ UI qo'llanma standartlarini yaratish jarayonida MUI Charts ni qo'llagan holda bir xil vaqtlar ketma-ketligini harita shaklida qayta amalga oshirish imkoniyatimiz bo'ldi.
Dastlab MUI ekotizimi bilan integratsiyaning yaxshi bo'lishi sababli ko'p umidlarim bor edi.
Xususan, mavjud dizayn tizimlari bilan birlashish nuqtai nazaridan, bu ApexCharts’dan yaxshiroq bo'lishi mumkin deb o'yladim.
Ammo haqiqiy amalga oshirish jarayonida avvalgi kabi tuzilmaviy muammolar yana yuzaga keldi.
Eng katta misol tooltipni amalga oshirish edi. Dizayn qo'llanmasida issiq xarita hujayrasiga sichqoncha bilan bosilganda nafaqat sana va qiymat, balki hafta kuni ma'lumotlari ham ko'rsatilishi kerak edi.
Lekin MUI Charts ham asosiy jihatdan gridga asoslangan ma'lumotlar modelidan foydalanganligi sababli, grafik ichida ma'lumotlar oddiy koordinata qiymatlari sifatida qabul qilinardi.
Ya'ni, tooltipda “2025-yil 15-mart şənbə” kabi ma'lumotlarni ko'rsatish uchun, joriy koordinata qiymati aslida qaysi sana bilan bog'liqligini qayta hisoblash kerak edi. Bu jarayon o'ylagandan ancha murakkab bo'ldi.
Diagramma tasvirlash uchun allaqachon sana ma'lumotlarini koordinata asosida aylantirib qo'yilganligi sababli, tooltipda yana koordinatani sanaga tiklash uchun qarama-qarshi yo'nalish hisob-kitobi zarur edi.
Natijada quyidagi muammo yuzaga keldi.
Birinchidan, grafikni tasvirlash uchun ma'lumotlar va haqiqiy biznes ma'lumotlari modeli ajralib qola boshladi.
Ikkinchisi, oddiy UI ko'rsatish uchun teskari ma'lumotlarni xaritalash logikasi qo'shildi.
Uchinchisi, dizayn tartibi ozgina o'zgarganda sana hisoblash tuzilmasining butunligi ta'sirlanadi.
Ayniqsa, oy boshlanish joyi yoki hafta hisoblash mezonlari o'zgarsa, mavjud hisoblash mantiqi butunlay tarqab ketish ehtimoli mavjud edi.
Bu oddiy ekran amalga oshirish muammosi emas, balki operatsion barqarorlikka bevosita ta'sir qiluvchi muammo edi.
Shuningdek, diagramma kutubxonasining versiyasi yangilanganda, mavjud o‘tkazish mantiqining to‘g‘ri ishlashini kafolatlash mumkin emasdi. Kutubxona ichidagi rendering tuzilmasi o‘zgarganda, maxsus mantiq tezda buzilishi mumkin edi.
Shunday qilib, kutubxonaning asl loyihalash maqsadidan ortiqcha sozlash, oxir-oqibat texnologik qarzga olib kelishi mumkin deb hisoblaganman.
Xususan, xizmat ko‘rsatish nuqtai nazaridan “hozir qo‘llab-quvvatlash mumkinmi”dan ko‘ra “bir yildan keyin ham saqlanib qolish mumkinmi” ko‘proq muhim deb hisobladik. Dastlabki ishlab chiqish tezligini hisobga olib, avvalgi stekni saqlash tanlovi uzoq muddatda texnik xizmat ko‘rsatish xarajatlarining oshishiga olib kelishi mumkin.
3. Maxsus vaqt seriyalari hitmap kutubxonasi ko‘rib chiqish va tanlash jarayoni
Mavjud gridga asoslangan charta kutubxonalarining strukturaviy cheklovlarini aniqlaganimizdan so'ng, sanalar ma'lumotlariga asoslangan maxsus vaqt seriyasi isitgichlari kutubxonalarini alohida ko'rib chiqayotganimizni boshladik.
Eng muhim ko'rib chiqilgan mezon quyidagilardir.
Birinchidan, sanalar ma'lumotlarini kutubxona ichida asosiy tushunilgan tuzilma ekanligini aniqlash kerak edi.
Ikkinchidan, shpiklarda sana va hafta kunlari ma'lumotlarini tabiiy ravishda ishlay olishi kerak edi.
Uchinchisi, javob beruvchi tartibni ishonchli qo'llab-quvvatlashi yoki yo'qligi edi.
To'rtinchisi, ichki umumiy dizayn tizimi bilan qanchalik tabiiy ravishda birlashishi edi.
Bir nechta nomzodlarni taqqoslaganimizdan so'ng, react-activity-calendar eng mos tanlov deb hisobladik.
Ushbu kutubxona GitHub Contribution uslubidagi vaqt oralig'ida kalendar issiqlik xaritasiga ixtisoslashgan tuzilishga ega edi.
Ya'ni, sana o'zida ma'lumotlar modelining markazida joylashgani uchun alohida koordinatlarni o'zgartirish logikasi deyarli zarur emas edi.
Ayniqsa, faqat sana ma'lumotini taqdim etsangiz, ichki dvigatel avtomatik ravishda hafta bo'yicha paketlarni va hujayra joylashuvini hisoblaydi, bu juda katta afzallikdir.
Avvalgi usulga o'xshab, "qaysi hafta"t, "qanday kun" va "qaysi koordinatda joylashishi" ni bevosita hisoblash kerak bo'lmagan.
Shuningdek, ko'rsatmalarni tuzish yanada oddiy edi. Biz allaqachon ichki ravishda sana asosidagi ma'lumotlar tuzilmasini saqlaganimiz sababli, sana va kun ma'lumotlarini qo'shimcha qayta hisoblashsiz darhol ishlatishimiz mumkin edi.
Natijada mavjud bo'lgan chetlashuv hisoblash mantiqining ko'pini olib tashlashimiz mumkin bo'ldi.
Bu oddiy kod uzunligi kamayganidan tashqari, ma'lumotlar tuzilmasi o'z-o'zidan ancha intuitiv ravishda yaxshilanganligini anglatardi.
4. Javob beruvchi ishlov berish va dizayn tizimi ulanishi
react-activity-calendar'ni tanlashning yana bir asosiy sababi javob beruvchi ishlov berish usuli edi. Odatda, grafik kutubxonalari ota konteyner o'lchamiga mos ravishda kenglik va balandlikni to'g'ridan-to'g'ri hisoblab berishlari kerak bo'ladi.
Xususan, hujayra asosida UI da, brauzer o'lchamining o'zgarishiga qarab, hujayra o'lchamlari va masofalarni alohida qayta hisoblash zarurati ko'p hollarda yuzaga keladi.
Ammo react-activity-calendar bu hisoblamalarni ichki dvigatel avtomatik ravishda bajaradi. Brauzer o'lchami o'zgarganda, hujayra o'lchamlari va masofalarni avtomatik joylashtiradi va tartibni saqlaydi. Ushbu tuzilma tufayli ResizeObserver asosidagi alohida hisoblash mantiqini amalga oshirish zarurati yo'q edi.
Natijada, reaktiv ishlov berish kodi o'z-o'zidan sezilarli darajada soddalashtirildi.
Bundan tashqari, uslubni ishlov berish usuli ham juda mamnun qoldi. Avvalgi grafik kutubxonalari koʻpincha CSS klasslarini majburan o'zgartirish usulini talab qildi.
Ammo bu usul kutubxona ichki klass tuzilishiga kuchli bog'liq bo'lib, versiya o'zgartirilganda osonlik bilan buzilishi muammosi mavjud edi.
Boshqa tomondan, react-activity-calendar esa theme ob'ektiga asoslangan e'lon qilingan stil tuzilishini taqdim etgan edi.
Ya'ni, rang tokenlarini ob'ekt shaklida to'g'ridan-to'g'ri kiritish orqali korporativ umumiy UI tizimi bo'lgan vizend-ui bilan qiziqarli tarzda bog'lanish imkoniyatiga ega bo'ldik.
Ayniqsa, dizayn tokenlariga asoslangan tuzilmalarga ega loyihalarda bunday e'lon qiluvchi mavzular usuli texnik xizmat ko'rsatish nuqtai nazaridan juda katta afzalliklarga ega bo'ldi.
5. Tartib
Bu hitmap kutubxonasini o'tkazish jarayoni oddiy UI komponentlarini almashtirishdan ko'ra ko'proq ma'no anglatdi. Dastlab, mavjud loyihada allaqachon qo'shilgan kutubxonalarni imkon qadar qayta ishlatish samarali deb o'yladim.
Ammo, haqiqatan, amalga oshirish jarayonida kutubxonaning loyihalash maqsadi va ma'lumotlar modelining mohiyati mos kelmasa, taxmin qilinganidan ancha katta texnik xizmat ko'rsatish xarajatlari yuzaga kelishi mumkinligini his qilganman.
Xususan, vaqt seriyalari kalendari issiqlik xaritasi oddiy koordinatlar asosidagi diagrammalardan mutlaqo boshqacha ma'lumotlar tuzilishiga ega edi. Sana o'zining asosiy ma'lumotlar modeli bo'lganligi sababli, uni oddiy koordinatlar asosida majburan o'zgartirish usuli uzoq muddatda texnik qarzning oshishiga olib kelishi mumkin edi.
Nihoyat, muhim narsa “hozirgi kunda amalga oshirish mumkinmi” emas, balki “ishlash muhiti qanchalik barqaror saqlanishi mumkin” deb o'ylayman.
react-activity-calendar ga o'tgandan so'ng, keraksiz oldindan qayta ishlash va teskari hisoblash mantiqining aksariyatini olib tashlash mumkin bo'ldi, shuningdek, ma'lumotlarning ishonchliligi va kodning o'qilishi har ikkalasi ham sezilarli darajada yaxshilandi.
Shuningdek, reaksiya olish va dizayn tizimlari bilan bog'lanish jihatidan ancha barqaror tuzilmani ta'minlash imkoniyati bo'ldi.
Bu tajriba orqali texnologiya tanlashda oddiy funktsiyalarning mavjudligi o'rniga, ma'lumotlar modelining xarakteri va kutubxonalar dizayn falsafasi qanday o'zaro mos kelishini hisobga olish zarurligini yana bir bor his qildim.
[есki манба]
• MUI X Issi мажмуа документatsiyasi
https://mui.com/x/react-charts/heatmap/
• ApexCharts React Isitma xaritalari namunalari
https://apexcharts.com/react-chart-demos/heatmap-charts/
ККамджинг