Pull to refresh

Comments 12

В своих проектах использую styled-components. Параллельно создается UI-kit по "атомарному" дизайну. Потребовалась подобная же система, чтобы отступы были консистентны, а цвета только из палитры.
Эта самописная оркестрация очень сильно похожа на упомянутую вами. Но я не готов был ее выкладывать в сообщество по следующим причинам (уже почти год в двух командах разработки используется):


  1. Еще больший порог входа. Нужна хорошая интерактивная (!) документация.
  2. Каждый раз даже я сам забываю ключевые слова. Да, если ты описался, в консоль выпадет ошибка со списком похожих значений, но все же.
  3. Трудно покрыть весь спектр нужд, и на пограничных ситуациях, создается конфликт: либо переизобретать css-свойства в "свои", либо оставлять как есть. В одном случае, нам все равно нужен чистый css, а в другом, получаем переизобретенный css, что еще сильнее увеличивает порог входа.

Отсюда спрошу:


  1. Как в этом проекте с обработкой ошибок? Что будет, если я напишу pz вместо px? Насколько система дружественна по сравнению с подсказками в реакте?
  2. Как у них с просизводительностью? Вырезают ли они проверки на продакшене?

Кстати, есть "баг" из документации (который, порой, рубит на корню все эти сокращалки для удобства):


// font-size of `theme.fontSizes[3]`
<Text fontSize={3} />

// font-size `32px`
<Text fontSize={32} />

А что, если я хочу fontSize={8}, и у меня 9 элементов внутри массива theme.fontSizes? Магия не должна ломаться.

Как в этом проекте с обработкой ошибок? Что будет, если я напишу pz вместо px?

Значения применяются как есть. В css будет значение с pz перечеркнутое в инспекторе.

Насколько система дружественна по сравнению с подсказками в реакте?

Подсказок никаких нет, ошибок тоже.

Как у них с просизводительностью? Вырезают ли они проверки на продакшене?

Честно говоря мы сами не замеряли производительность, я думаю это уже больше относится к styled-components нежели к styled system, но у них в гите есть страничка с бенчмарками

А что, если я хочу fontSize={8}, и у меня 9 элементов внутри массива theme.fontSizes? Магия не должна ломаться.

Не совсем понятно что имелось в виду, «магия» работает так — все что больше 9-го элемента в массиве fontSizes будет интерпретироваться как есть.

const fontSizes = [ 12, 14, 16, 20, 24, 32, 48, 64, 72 ]

fontSize={8} вернет 72
fontSize={9} вернет 9

Еще есть проблема в использовании констант или элементов в массиве.
Например, theme.fontSize[3] — это большой размер шрифта или маленький? Сколько всего элементов в массиве, какой шаг? А точно ли они от маленького в большому, или как h1 к h6: от большого к малому? А затем, дизайнер, хорошо подумав, считает, что нужен новый размер шрифта, который между №3 и №4. Что делать? Рефакторить весь проект или добавлять в конец?


Очень много вопросов, на которые не хотелось бы отвечать и запоминать эту информацию.


Поэтому в своем решении я отказался от этого. Сначала взял за основу подход к жирноте шрифта в css и к цветам в Material Design: где шкала от 100 до 900. Довольно логично. И CSS-спецификация, и популярная дизайн-система. Порог входа снижается.


Но затем, подумал и проконсультировался с коллегами (им тоже ведь, код этот писать) ввел систему из человеческих слов, получилось: tiny, small, normal, medium, big, large, huge. Потом добавился micro, а medium в нашей системе запрещен (null), система выкидывает ошибки с подсказками.


Но тут опять проблема в промежуточных значениях.


Может быть брать за основу css-спецификацию по размерам шрифта: xx-small, x-small, medium, large, x-large, xx-large? Вроде следование спецификации. А на желания дизайнера ввести 8-ой размер шрифта, аргументированно сказать нет, пусть выбирает жирность, цвет, отступы.


И такое количество вопросов возникает на каждом шагу.

Мы сами находимся в постоянном поиске, т.к серебрянной пули нет и у всех свои требования к используемым инструментам и фреймворкам.

У нас обычно размеры шрифтов обговариваются на этапе отрисовки дизайна, мы уже получаем их как константы.

Мы тоже пытались делать шкалу значений и человеческие названия, но все это так и не дало нам понятной и четкой дизайн системы.
Интересно, почему же в подобных статьях ни слова о тестируемости данных решений?
Уточните, пожалуйста, о каких тестах идет речь? Если речь идет о внутреннем устройстве styled system, то у них есть свои тесты.
Я про тестирование своих компонентов.

Мы разрабатываем компоненты в сторибуке, получается как визуальное тестирование. Snapshot не используем

Крайне рекомендую этот тред (и сабтреды) к прочтению twitter.com/andrey_sitnik/status/1098115325281869825

Мои выводы:
— АПИ styled-components (в плане объединения объявления стилей и компонента) архитектурно очень качественно и удобно
— Библиотека подустарела и есть более интересные аналоги
— Зато она стабильна и имеет большую экостистему
— Есть еще куча мелочей, которые стоит учитывать, особенно чем больше приложение.
Да, интересный тред, спасибо. Я считаю, что все как всегда зависит от требований к проекту и решаемых задач. Тут каждый выбирает уже то, что подходит конкретно ему в конкретном проекте. Но за ссылку спасибо, будем иметь в виду, особенно заинтриговал astroturf. Посмотрю в свободное время
Достаточно интересное решение, большое спасибо за статью, нужно будет попробовать.
Спасибо за отзыв, сами пока пробуем, пока только в одном проекте используем styled system, но вроде нравится. Время покажет.
Sign up to leave a comment.

Articles