🔥

Тред (Дима Коваленко)


Окей, разбираймся с дизайн системами. И сначала поговорим про полностью самописные дизайн системы.

Понятное дело что это действительно самый эффективный способ сделать собственную дизайн систему. При чем хочу уточнить что дизайн система !== набор компонентов для дизайна. Это очень важно – сделать дизайн систему это работа дизайнеров.

По сути дизайн система это набор правил для построения вашего уникального дизайна. Эти правила обычно собираются в гайды и потом реализовываются для различных платформ. Самая популярная дизайн система – material design (material.io)

Кстати очень хочу заметить что то что делаем мы в @MaterialUI – это всего лишь реализация этой дизайн системы. Точно такими же (токо хуже 😉) реализациями материал дизайна являются Vuetify, Angular material, MDL и так далее

Отвлекся. Возвращаемся к правилам –> хорошим примером правила дизайн системы является: В материал дизайне все размеры/отступы кратны 8 пикселям. (8, 24, 32, или даже 4). Это все идет из правил золотого сечения, короче когда все размеры кратны – людям так больше нравится.

И вот в самописной дизайн системе гораздо проще создавать и заставлять итоговые продукты следовать этим правилам. Помимо всего прочего ваша кастомная имплементация системы будет решать только вашу проблему и поэтому будет делать это наиболее эффективно.

Теперь по проблемам. И основная проблема самописной имплементации дизайн системы (собственно как и всего самописного) – это ресурсы. Очевидно, что бизнесу необходимо выделить деньги и время на создание такой системы.

Но неочевидная вещь заключается в том что вы 100% недооцените необходимое время на создание. Просто потому что создание компонентов требует довольно много знаний не очень востребованных в обычной разработке фронтенда.

Например - тришейкинг. Вы должны понимать что такое esm/cjs модули, как билдить библиотеку компонентов, освоить какой-нибудь rollup. Но этого вам не хватит чтобы сделать esm. Дело в том, что тришейкинг в вебпаке работает только по файлам.

Помимо этого вам нужно будет сделать UMD билд, потому что кто-то захочет использовать дизайн систему через CDN, сделать cjs потому что кому-то понадобится SSR. Кстати о SSR – ваши компоненты должны уметь вытаскивать critical css, иначе перформанса на сервере вам не видать.

Дальше идет accessibility, которое должно внедряться на уровне именно компонентов. А это тянет за собой такие вещи как TrapFocus – штука которая не даст вам вытабаться из модалки, вам нужно будет уметь работать с регионами, live-announcements и еще кучей всего.

И еще кучи всего того, что уже есть в UI kit-ax. И понятное дело, что сразу всего этого не сделать. Помимо этого нужно сделать нормальную документацию, запилить нормальные дефинишены для ts, flow или чего вы там используете.

Основная проблема заключается в том что каждый новый проект будет приходить со своей хотелкой и вы должны будете его удовлетворить. А это на первых порах будет постоянно тратить ресурсы, тормозить запуск продуктов и вообще не хорошо :)