Как бы мне ни нравился CSS за его творческий потенциал, мне кажется невозможным не чувствовать боли, когда дело доходит до его масштабирования. В carwow в настоящее время более 40 инженеров ежедневно работают над нашим онлайн-приложением, и все мы в конечном итоге пишем CSS. Как бы мы ни старались держать вещи в порядке и использовать нашу систему дизайна, мы неизбежно сталкиваемся с типичными проблемами, связанными с поддержанием большой базы кода CSS: несогласованность, избыточность, чрезмерные сложности и частые регрессы нашего пользовательского интерфейса. .

Я слежу за многими разговорами о том, как решать эти проблемы, и, похоже, существуют разные школы мысли. Один состоит в обеспечении более строгого использования CSS с помощью линтеров и соглашений об именах (объектно-ориентированный CSS, SMACSS, BEM и т. Д.). Другой - это переосмысление того, как мы управляем стилями, и отказ от прямого написания CSS. Это можно сделать либо с помощью функционального инструментария, такого как Atomic CSS или Tachyons, либо с помощью управления стилями в JavaScript (см. JSS, CSS-модули или стилизованные компоненты).

Обычно меня озадачивает идея управления CSS в JavaScript. Мы уже перегружаем пользователей большим количеством JavaScript - будь то для обильной интерактивности или для маркетинговых трекеров. Обрабатывая как HTML, так и CSS в JavaScript, я прихожу к выводу, что действительно ли мы решаем проблемы или просто объединяем более тяжелые, медленные и более навязчивые веб-сайты. Как справедливо выразился Гарри Роберт:

Между тем, я недавно наткнулся на эту ветку об итогах создания нового прогрессивного веб-приложения Twitter и генерации CSS по запросу с помощью JS-фреймворка.

Следующий абзац особенно привлек мое внимание, так как я мог полностью относиться к описанным вопросам.

Вскоре после этого я также посмотрел выступление Мэтью Гриффита на elm-conf 2018 о его наборе инструментов для дизайна Elm UI.

Я проработал с Эльмом больше года, и этот разговор многое мне сказал. Мне очень нравится Elm за его предсказуемость, цикл обратной связи при работе с компилятором и уверенность в отсутствии ошибок времени выполнения. Более того, Elm изначально создавался как графическая библиотека, и кажется, что он естественным образом подходит для DOM. Также имеет смысл использовать его для объявления макета и внешнего вида создаваемых нами приложений.

Я смотрел этот разговор с волнением и скептицизмом. С одной стороны, мне очень нравится подход переосмысления стилей для веб-сайтов, а не использование функций Elm, которые как таковые реплицируют свойства CSS. Похоже, что мы много думали о том, чтобы сделать создание макета более простым и интуитивно понятным с помощью Elm UI. Один из недостатков CSS - его очень трудно читать. Просмотр списка свойств в селекторе никогда не дает полного представления о том, как элемент будет выглядеть в браузере. С пользовательским интерфейсом Elm макет и стили кажутся намного проще для чтения и, соответственно, быстрее для изучения.

Другой элемент, который мне действительно понравился в разговоре, - это взаимосвязь между пользовательским интерфейсом Elm и системами дизайна. Я активно работаю над созданием и поддержанием руководства по стилю и с энтузиазмом отношусь к созданию библиотеки пользовательского интерфейса, которая была бы гибкой, модульной и работала как для разработчиков, так и для дизайнеров. Опять же, проблемы с масштабированием CSS мешают достижению этой цели. Мне нравится возможность собирать части пользовательского интерфейса, как набор блоков LEGO. Инкапсуляция стилей в компонентах и ​​возможность простого объявления макетов были бы ключом к достижению этого состояния.

Между тем, я скептически относился к возможностям, предлагаемым Elm UI. Добавляя уровень абстракции поверх CSS, нет ли риска ограничить его возможности? Примеры, представленные в докладе, а также некоторые демонстрации, которые я видел в Интернете, довольно упрощены, и мне интересно, сможем ли мы достичь сложных дизайнов с помощью Elm UI. Можем ли мы накладывать элементы? Анимировать и преобразовывать элементы с помощью изящных переходов? Использовать единицы просмотра или вычисления размеров? Эти вопросы кажутся мне важными, чтобы иметь возможность использовать Elm UI в производственной среде, при этом оставаясь довольной командой дизайнеров.

Затем я решил противостоять своему скептицизму и опробовать библиотеку с несколькими вариантами использования и лично убедиться в этом. Одной из моих попыток было воссоздать модальный компонент нашего руководства по стилю с помощью пользовательского интерфейса Elm. Некоторые из спецификаций, которые я хотел воспроизвести здесь, - это наложение, охватывающее всю область просмотра и блокирующее прокрутку пользователя, а также общий модальный экран с гибкой высотой до 65vh. В теле модального окна при необходимости должна отображаться внутренняя полоса прокрутки. Наконец, компонент открывается и закрывается с быстрым изменением прозрачности наложения и размера модального окна, чтобы передать эффект всплывающего окна.

Создавая основы модального окна, я быстро натолкнулся на несколько проблем с переполнением, которые я интерпретировал как напоминание о том, что в глубине души я все еще пишу CSS. Я надеялся, что пользовательский интерфейс Elm предотвратит это, но я полагаю, что существуют пределы надежности атомарного инструментария CSS.

В целом, мне понравился опыт изучения пользовательского интерфейса Elm, а некоторые способы объявления макета и стилей намного элегантнее, чем в CSS.

Например, установка элемента в качестве наложения перед остальной частью страницы выполняется с помощью:

Element.layout [ inFront modalOverlay ]
    pageContent

Мы также извлекаем выгоду из синтаксиса Elm, который может быть удобен, например, для установки значений отступа или ширины границы:

paddingEach { edges | top = 24, left = 32 }

Вместо того, чтобы устанавливать все 4 ребра и следовать произвольному порядку:

padding: 24px 0 0 32px

Довольно быстро мне удалось собрать весь компонент:

Однако я не смог выполнить следующие требования:

  • Я не мог установить максимальную высоту в единицах просмотра. Вместо этого мне пришлось установить его в пикселях.
  • Я не мог найти способ установить переходы при открытии и закрытии модального окна. Я предполагаю, что переходы и анимация - это функции, которые Elm UI сможет обрабатывать в будущих версиях.
  • В нашем руководстве по стилю есть набор размеров шрифта, которые адаптируются к 3 размерам экрана. Похоже, я не смог сделать это здесь, и, как правило, он не применяет медиа-запросы через интерфейс Elm.
  • Есть некоторые мелкие проблемы, которые я тоже не мог решить. Например, Element.textColumn по умолчанию имеет минимальную ширину 500px, что для меня не имеет особого смысла, и его нелегко переопределить. У меня также были проблемы с вертикальным выравниванием текстовых элементов в строке, что обычно просто с помощью Flexbox. Хотя, эти проблемы могут быть просто из-за моего отсутствия опыта работы с инструментарием.

В конце концов, мне очень понравилось опробовать Elm UI. Это хорошо продуманная, простая в освоении и интересная в использовании библиотека. Я думаю, что на данный момент он слишком ограничен, чтобы иметь возможность использовать его в производстве и выполнять обычные требования к дизайну. Есть и другие проблемы, которые необходимо устранить, например, насколько хорошо он обрабатывает особенности браузера и поддерживает устаревшие браузеры.

Я надеюсь, что эти ограничения связаны только с новизной Elm UI, и что вскоре он продолжит развиваться и предлагать более широкие возможности.

PS: Кроме того, что с flex-grow: 100000?