А вот это очень неплохая статья, если игнорировать все попытки автора словами никого не обидеть. Но такие времена нынче.
Мы в прошлом году у себя реализовали дизайн-систему на композе, продолжаем её использовать и дорабатывать, и у меня во многом теперь откликается.
Дизайн-система – это токены (цвета, шрифты…) и компоненты (кнопки, текстовые поля…). В этом смысле в любом проекте так или иначе есть дизайн-система, даже если она несистемная 🙃.
Так вот, Material – это уже дизайн-система, хотя про неё так думать почему-то не принято. И мы как сообщество не очень понимаем для кого она. Объективно говоря, миру вообще максимально плевать на какие-то дизайн гайдлайны от Google, особенно учитывая то, что от Apple есть другие. Любому бизнесу важнее собственная идентичность и идея загнать всех под одни правила от обеих платформ обречена на провал.
То есть, в реальность Material – это просто такой opinionated дефолт для пет-проектов на андроиде. И если мы хотим расти, причём расти параллельно с иосом, то продолжать использовать Material – это постоянно идти на какие-то компромиссы.
Проблема в том, что не использовать его в андроиде практически невозможно. Мы не можем просто подложить свои кастомные токены взамен токенов Material, т.к. компоненты Material хотят токены Material. Нам придётся натягивать тему от дизайнеров на Material, начиная с токенов, а почти наверняка однозначное соответствие между ними отсутствует.
Гугл предлагает несколько вариантов как затюнить дизайн под себя. Единственный, где Material вообще исключён из уравнения подразумевает, что мы или обернём каждый Material компонент или напишем свои.
- Правильно с нуля написать свои и потом это поддерживать – невероятно дорого, поэтому эту идею вообще отбрасываем.
- Обернуть – не панацея, в условной кнопке мы не можем переопределить шрифт по-умолчанию или минимальные размеры, т.е. оно таки не кастомизируется как вам нужно, там это всё захардкожено.
- Вариант посередине подразумевает, что мы скопипастим к себе просто весь нужный код из Material. Но там такая лапша тянется из-за кучи абстракций и приватности, что это с точки зрения сложности поддержки приближается к первому варианту. В общем все варианты плохи. 😓
А мечтаем мы о том, чтобы у нас существовал какой-то слой компонентов, которые реализовывали бы функциональность, не мешая её с внешним видом. То есть, мы хотим, чтобы условная кнопка вообще не зависела от токенов, а давала возможность задать ВСЁ параметрами. И чтобы в коде этих компонентов не было никакого opinionated хардкода. Ну кайф же?
Вот и поверх этого, если гуглу так хочется, мы уже не против иметь Material компоненты, которые просто заполняли бы параметры компонентов из соответствующих Material токенов. А если хотим своё, то мы бы сами себе сделали типы для токенов и в своих обёртках просто прокинули бы их.