@webitel/ui

Appearance

Code Base Deprecation Info ​

Навігація ​

Вам треба зробити:

Таблиця ​

Фіча, задача, технологія✅ Так⚠️ Ситуативно❌ ДУЖЕ ситуативно🚧 Refactor?
Табличка🔗@webitel/ui-datalist@webitel/ui-sdk/*
Карточка🔗@webitel/ui-datalist@webitel/ui-sdk/*
API: clients, utils🔗@webitel/api-services/api@webitel/ui-sdk/api➕
API: gen, types, zod-schemas🔗@webitel/api-services/genwebitel-sdk➕
Vue Component Style🔗Composition APIOptions API (під mixins)➕
TypeScript/JavaScript🔗TypeScriptJavaScript➕
Access Control, Userinfo🔗v2v1

Проблематика ​

Через велику кодову базу, постійне розширення та модифікацію, у нас є доволі багато місць, де використовується застаріла кодова база.

Тому, основне питання таке:

Яку версію кодової бази обрати для виконання вашої конкретної задачі?

Чому? ​

Техборги: Щось не доробили, щось переписали але не порефакторили всюди, щось пропустили.

Станом на зараз маємо підхід "краще написати по-правильному ніж костилити, і мати зайвий техборг, ніж притримуватись старого стилю і писати костилі, доки не розвалиться повністю".

Наприклад ​

Маємо (станом на v25.06) кілька (напевне, 3) версій коду фільтрів або таблички, який виконує одну й ту ж функцію.

  • @webitel/ui-sdk/modules/TableStoreModule
  • @webitel/ui-sdk/store/new/modules/tableStoreModule
  • @webitel/ui-datalist/table

Або, схоже з фільтрами таблиці:

  • @webitel/ui-sdk/modules/QueryFilters
  • @webitel/ui-sdk/modules/Filters
  • @webitel/ui-datalist/filters

Або, апплікейшени: Crm написана повністю на composables, i на новіших сторах. А Admin – там ще аж mixins.

Узагальнені критерії вибору ​

Як написані "сусідні" фічі? ​

Дуже часто, коли вам треба додати щось, то рівно в тому ж апплікейшені лежить сусідній шматок функціоналу, якось вже написаний. В такому разі, найкраще взяти за основу саме його.

На скільки достатньо часу та наснаги ви маєте для рефакторингу? ​

Boy-scout rule: "Leave the code better than you found it".

При інших рівних факторах, беріть новіше. ​

А за можливості, переписуйте старіше на новіше також.

Обираємо технологію ​

Store ​

✅ Pinia ​

Краще Pinia.

⚠️ Vuex ​

Але якщо в апплікейшені Pinia ще не засетаплена і у вас немає часу на ризики, то візьміть Vuex.

Наприклад:

  1. Новий store для нової ізольованої фічі у Workspace – беріть собі спокійно Pinia.

  2. Новий розділ для Admin – беріть Vuex, бо там все на Vuex і у вас буде тупо copy-paste розділу.

Валідації ​

✅ Zod + Regle ​

Свіже.

Рекомендовано, там де можете. Вже інтегровано у @webitel/ui-datalist/card.

⚠️ Vuelidate ​

Там де вже є.

Від Vuelidate ми відмовляємось, мігруємо на Zod + Regle.

TypeScript ​

✅ Впроваджуємо 🙂

Vue components style ​

✅ Composition API ​

<script setup>

❌ Options API ​

Compat, або під існуючі mixins.

Обираємо кодову базу ​

API ​

✅ @webitel/api-services ​

Так.

❌ @webitel/ui-sdk/api та @webitel/ui-sdk/src/api ​

Ні. Весь контент з тих папок мігрований у @webitel/api-services.

Бачите – міняйте імпорт на @webitel/api-services.

Таблички ​

✅ @webitel/ui-datalist/table. ​

Так. Найновіша версія, Pinia.

Станом на v25.06 використовується тільки в crm i history апплікейшенах.

⚠️ Таблички з @webitel/ui-sdk/... (все інше) ​

Якщо на рівні апплікейшена є декілька сторів одночасно, то беремо найновіший. Або "найближчий" ієрархічно. Якщо всюди однаковий – беремо його.

Карточки ​

Сторінки запису таблички

Те саме, що і з табличками. – вони зазвичай йдуть разом.

Валідації ​

Зазвичай існують разом зі стором карточки.

Зокрема бо у більшості карточок у нас є таби.

🤔 Якщо є стор карточки ​

  • Стор старий => Vuelidate – пишуться в компоненті.

  • Стор новий => Zod + Regle – вони вже зашиті у стор.

🤔 Якщо стору карточки немає ​

  • Якщо є згенерована з API zod-схема => використовуємо її для валідації.

  • Якщо немає – то я хз, напишіть @dlohvinov.

Access Control, Userinfo ​

✅ @webitel/ui-sdk/modules/Userinfo/v2/... ​

По можливості краще v2.

WARNING

Увага на шлях: ../v2/..

⚠️ @webitel/ui-sdk/modules/Userinfo/... ​

Старіше. Має сенс використовувати має сенс тільки для copy-paste створення розділів або фіч.