elyor.dev – Telegram
elyor.dev
292 subscribers
97 photos
3 videos
84 links
- Shaxsiy fikrlar hammasi ham to'g'ri bo'lmasligi mumkin

© Elyor Shodiyorov
Download Telegram
Channel created
Bismillah!
🤝8
#intro

O'sha kun keldi, blog yuritishga qaror qildim. Bu yerda frontend bo'yicha, umuman IT bo'yicha bilganlarimni, o'rganyotganlarimni yozib borishga harakat qilaman. Shaxsiy fikrlarni hammasi ham to'g'ri bo'lmasligi mumkin, ishonib qolishlik shart emas.

Mobx top, Redux tufta ekanligi to'g'ri lekin!

Yaqinlar bilan ulashib qo'ysanggiz xursand bo'laman!

@elyor_dev
🔥15👍5💩4🤮21
Бугун zustand ни реаль проект учун ишлатиб кўрдим. Ўша гап, туфта экан(

@elyor_dev
10
#zustand #effector #battle


Бугун zustand билан effector ни "боевой проект" да солиштириб кўрдим. Проект тўлиқ эффекторда ёзилганди, сахифалар ҳам кўп, яъни ўртача катталикдаги проект деса ҳам бўлади. Стейтлар effector'да ёзилган. Ўшани zustand га алиштирдим. Натижада bundle size 12KB га қисқарди 😵‍💫.

12KB менимча катта натижа эмас. Кутилган натижани олмадик😁.

Zustand'нинг feature'лари ҳам effector'га нисбатан камроқ экан. Лекин redux'дан қулайроқ.

Ҳа айтганча сторлар билан ишлашда ҳам ҳеч бўлмаса функция фабрика ишлатиш керак экан. Мени вазиятимдаги каби state manager'ни ўзгартириш таски келса тезда ўзгартириб чиқиш имкони бўлади.

P. S. Бизда айнан функция фабрика ишлатилган, шунга ўша функция ўзигина қайта ёздим ҳолос. Ташқарига стор ва action'лар берилади, яъни компонент ичида у стор effector'га тегишлими ёки zustand'га буни аҳамияти қолмайди. Қолган баъзи жойларни,масалан useStore каби импортларни webstorm билан replace all қилиб қўя қолдим.

P. S. S. Ишхонада effector ишлатамиз, ҳар ҳолда ҳозирча, келажакда zustand'га ўтиш эхтимоли бор. Team lead'лар хоҳиши(

@elyor_dev
mobx-flux yoki zustand

Бугун насиб бўлса, zustand source code'ларининг бир қисмини "обзор" қилиб пост ёзмоқчиман. Яъни у ўзи нима устига қурилган ва қанақа ишлайди.

Бундай постдан мақсад, яқинда redux-toolkit синтаксиси билан бир ҳил mobx-flux пакетни ёзган эдим. Zustand'нинг ҳам source code'лари mobx-flux'га жуда ўхшаш экан.

Балким солиштирма пост ҳам бўлар, кейинчалик.

Ҳозир эса ухлаш керак)

#mobx_flux #zustand

@elyor_dev
👍2
Кириллча ёки lotincha? Қайси бири qulay?
Anonymous Poll
5%
Кирилл
75%
Lotin
19%
Farqi йўқ
Zustand

Va'da berganimdek zustand'ning aynan core qismini qisqa "обзор"i haqida post. (React uchun binding qismi boshqa safarga qoldi)

Zustand'dagi asosiy funksiya bu rasmdagi createStoreImpl funksiyasi.

Xo'sh uni ichida ishlatilayotgan variable va functionlarni rasmda raqamlab chiqdim. (destroyni qoldirdim, u deprecated bo'lgani uchun)

Birma-bir ko'rib chiqamiz

1. state - bizga kerakli data va actionlar aynan shu variableda joylashadi.
Oxiridan bitta qator yuqoridagi
state = createState(setState, getState, api)
ushbu code biz store create qilayotganimizda uzatib yuboradigan callback'ni chaqirib natijasini state'ga yozib qo'ymoqda, ya'ni initial state va actionlarni.

2. listeners - bu biz tartib bo'yicha 5-da turgan subscribe funksiyasiga uzatib yuboradigan callbacklarimizni saqlovchi variable. (Set haqida bilmasanggiz).
3. setState - bu funksiya state'ni update qilishlik uchun, funksiya bir necha turli xil formatdagi parameterlar qabul qila olgani uchun ichida tekshiruvlar soni ko'proq, lekin baribir asosiy ishi stateni yangilash. Stateni yangilashdan oldin Object.is() bilan tekshiruv ham bor, agar state qiymatlari o'zgarmagan bo'lsa stateni yangilab ortiqcha hisob-kitob qilmaslik uchun.

Note: Object.is({}, {}) // false

Xullas agar set qilinganda uzatilgan state bilan bizdagi state teng (shallow equal) bo'lmasa, stateni yangilaymiz, va state yangilangani haqida hamma subscriberlarni xabardor qilishlik uchun listeners'dagi har bir funksiyani chaqirib chiqamiz.

4. getState - state'ni qaytaruvchi funksiya, store.getState() qilsak, barcha actionlar, va ayni hozirgi paytda actual bo'lgan data'ni olamiz.

5. subscribe - store o'zgarishiga "подписка" qilish uchun
Misol uchun sahifada todolar sonini ko'rsatishimiz kerak:

todoListStore.subscribe((state, prevState) => {
todoListCounterDiv.innerHTML = state.todos.length
})

subscribe funksiyasi unsubscribe qilishlik uchun funksiya ham qaytaradi, masalan todolar sahifasidan boshqa sahifaga o'tish oldidan:

const unsubscribeTodoList = todoListStore.subscribe((state, prevState) => {
todoListCounterDiv.innerHTML = state.todos.length
})

unsubscribeTodoList()
window.location.pathname = '/other-page'

#zustand #source_code

@elyor_dev
👍3🔥3
Ertalab, toza miyaga o'qish uchun statya.

Hozir esa uxlash kerak)



Внутреннее представление и оптимизации строк в JavaScript-движке V8: «отмываем» строки, «обгоняем» C++ https://habr.com/p/745008/


#v8 #work_with_strings

@elyor_dev
👍8
Feature Sliced Design haqida eshitganmisiz? Eshitmagan bo'lsanggiz bir qarab chiqishni maslahat beraman. Ertaga uzunroq post yozishga harakat qilaman nasib bo'lsa.

https://feature-sliced.design/

#fsd

@elyor_dev
🔥7👍2
Feature Sliced Design

Feature-Sliced Design (FSD) - aynan frontend uchun arxitektura metodoligayasi. Kod qanday tashkil qilish haqida bir necha qoidalar to'plami. Asosiy e'tibori tushunarli, masshtabli, zarur bo'lganda oson kengaytiriladigan loyihalar yozishga qaratilgan.

FSD uchta qismdan iborat desak ham bo'ladi, bular - layers, slices, segments.

Layers (qatlamlar) - hamma projectlar uchun standart qism , har bir qatlamda yotgan modullar faqat shu qatlamdan pastda bo'lgan qatlam modullari bilan o'zaro ishlay oladi, ya'ni yuqoriroqda joylashgan qatlam faqat o'zidan pastroqda joylashgan qatlamni o'ziga import qilib ishlashi mumkin. Hozircha qatlamlar soni 7 ta (har bir qatlam pastdan yuqoriga joylashtirilgan).

Davomi pastda ->
👍1
1. shared - qayta ishlatiladigan, biznesga to'g'ridan to'g'ri aloqasi yo'q modullar joylashtiriladi, bularga UI kit, har projectga kerak bo'ladigan helper (yordamchi) funksiyalar, har xil configlar (env, api) va shu tipdagi utilitalarni kiritish mumkin, bu qatlamda joylashgan modullar bir projectdan boshqa projectga o'zgarishsiz ko'chirib o'tilsa bo'ladi.

2. entities - asosiy biznes obyektlar, masalan user, post, todo, comment. Bu qatlamda aynan biron biznes obyekt uchun kerak bo'lgan modullar yotadi, masalan user kartochkasi, hamma userlar listini saqlovchi store va hokazolar.

3. features - bu qatlamda foydalanuvchi va biznes o'zaro aloqa qiladigan, foydalanuvchi uchun biron biznes-qiymat keltiradigan senariylar yoziladi, masalan registratsiya formasi, todo create qilish formasi, komment jo'natish va hokazolar.

4. widgets - entities va features qatlamlarida joylashgan modulelarni alohida mustaqil bloklarga biriktiruvchi qatlam, masalan usersList va usersFilter

Davomi pastda ->
5. pages - sahifalar, o'zida entities, features, widgetslarni jamlaydi, M-n: todolar sahifasi o'ziga noscript, todo-filters, todo-list ni jamlaydi.

6. processes - (eskirgan qatlam) bir nechta sahifani o'zida jamlab ishlatishi mumkin bo'lgan senariylar to'planmasi, m-n: authorization (Qadamma qadam bir necha sahifa ochilib qilinadigan hollarda)

7. app - bu qatlamda global stylelar, providerlar, yoki shunga o'xshash butun app uchun kerak bo'lgan sozlamar joylashadi.

O'z navbatida bu qatlamlar slice'larga bo'linadi, masalan
entities - (users, posts, comments, todos). Slice'lar o'zida logika tomondan o'zaro bog'liq bo'lgan modullarni o'zida birlashtiradi, va ular uchun muhim bo'lgan qoidalardan biri bu - bir slice o'zi bilan bir darajada joylashgan boshqa slice modullarini o'ziga import qila olmaydi, ya'ni enitities-users da joylashgan qatlam enitities-posts da joylashgan qatlamdagi modulelarni o'ziga import qila olmaydi. Bu qoida biznes obyektlarni boshqa modulelardan qaramligini kamaytiradi va o'zi mustaqil yashay olishini ta'minlaydi.

Va har bir slice ham segment'larga bo'linadi, segmentlar modulelarning texnik tarafdan ishlatilishiga qarab bo'linadi, segmentlar asosan ui (UserCard, UserList componentlar), model (storelar, userListStore), api (api so'rovlar - usersApi), lib (helper funksiyalar, hooklar) lardan iborat bo'ladi, lekin kerak bo'lsa yana qanaqadir segmentlar qo'shish mumkin.

FSD da modullarni ularning turiga qarab emas, balki ular ishlatilish joyiga qarab bo'lish muhim. Ko'pchilik proyektlarda ko'rganmiz, types, stores, api, components, styles nomli bo'lingan folderlarni, aynan bu modullarni turiga qarab bo'lish deyiladi, FSD da esa ishlatilish nuqtasiga qarab bo'linadi, bu o'z navbatida projectda kerakli modulelarni tezda topish, uni kengaytirish, va projectda umuman biznes obyektlar, modulelarning bir biri bilan qanday bog'langanini oldindan ko'rsatib turadi.

FSD docs'ga kirsanggiz u yerda frontenddagi har xil frameworklar bilan fsd'ni qanday ishlatish kerakligi haqida examplelar topasiz, link qoldiraman.

FSD docs'ga o'zbek tilini ham qo'shishibdi, menimcha hali to'liq emasku, lekin asosiy momentlarni o'qib olsa bo'ladi

FSD ni tezda tushunib olish uchun DDD (Domain Driven Design) haqida ham bir muncha o'qib ko'rishni tavsiya qilaman!

Qisqa tanishtiruv post bo'ldi, savollar bo'lsa kommentga marhamat!

Foydali linklar:

- FSD docs
- FSD official examples
- Official fsd eslint plugin

Aynan o'zim yozgan projectlardan misollar
- fsd-react-mobx

#feature_sliced_design #fsd

@elyor_dev
👍8👎1
elyor.dev
Кириллча ёки lotincha? Қайси бири qulay?
Postlarni lotin alifbosida yozishga qaror qildim. Ko'pchilikka shu ma'qul ekan, kommentda esa erkinroq yozaman, xafa bo'lmaysilar)

@elyor_dev
👍8👎1👌1
Mobx bo'yicha bir nechta seriyali post'lar chiqarmoqchiman nasib bo'lsa. Kimga qiziq bo'lsa boshlang'ich materiallarni quyidagi chatdan topib ko'rishlik mumkin, ozgina tushuncha olishlik uchun. O'zi mobx qiyin ham emas.

https://news.1rj.ru/str/mobxjs_uz

#mobx #qaqshatgich_zarba #redux_trash

@elyor_dev
👍7👎1💔1
Mobx va React Context

Assalomu aleykum, bugundan mobx bo'yicha seriyali postlarni boshladim. Bugun data React + Mobx applarda data sharing (stateni tashish) yo'llaridan biri bo'lgan Mobx + Context Api'ni ko'rib chiqamiz.

1. O'zimizga kerakli storelarni create qilamiz, Ular nechtaligi, qayerda joylashishi muhim emas.

2. RootStore class ichida bizda bor barcha storelarni register qilib chiqamiz, xuddi 2-rasmdagidek.

3. React context create qilamiz, project'da ts bo'lsa tiplarini ko'rsatgan holda, va shu context'ni ishlata olishlik uchun Provider va useStore hooklarni ham create qilib olamiz, unchalik murakkab emas nazarimda.

4. So'ng entry point fileda (main.tsx yoki index.tsx) Appni Providerga o'raymiz

5. useStore orqali kerakli storelarni olib ishlataveramiz. Faqat store ishlatilgan componentlarni observerga o'rash kerak

#mobx #context_api

@elyor_dev
👍3👎2