Инструменты веб-интерфейса - это то, что меня интересует уже пару лет, в основном из-за того, насколько болезненно сейчас является веб-разработка.

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

Как бы я ни был уверен в создании чего-то, что работает, попытка придумать что-то практичное оказалось гораздо более сложной задачей, чем я ожидал. В течение 4 лет у меня было много неудачных идей, но я весело провел время и многому научился.

V1: создание визуального редактора, который мог бы редактировать что угодно

Мой первый подход к инструментам пользовательского интерфейса в 2016 году был амбициозным. Идея заключалась в том, чтобы позволить пользователям открывать свои существующие приложения в редакторе пользовательского интерфейса и позволить им сразу же начать вносить изменения.

Редактор был создан для запуска любого вида веб-приложений и мог выполнять обратную запись в исходный код, следуя картам исходных текстов (React, Less, SCSS, Angular, вы называете это). Вот еще одна демонстрация того, как редактор вносит изменения в действующий веб-сайт:

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

Предполагая, что a=b и b=2, пользователь увидит 3 в построителе пользовательского интерфейса. Поскольку это вычисляемая информация , она должна быть недоступна для редактирования, поскольку построитель пользовательского интерфейса не знает, редактировать ли a или b. Это элементарный пример, но оказывается, что большая часть кода приложения вычисляется таким образом, что его очень сложно отследить и отредактировать. Мое решение заключалось в том, чтобы ограничить построитель пользовательского интерфейса только теми частями приложения, которые он мог легко редактировать, но пользовательский интерфейс сбивал с толку, поскольку не было четкой границы между редактируемым и нередактируемым кодом.

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

В конце концов, проект оказался слишком большим, и на его управление у меня ушло все время. Лучшим подходом было бы начать с малого с четкими границами, а затем итерировать оттуда.

V2: Создание редактора презентационных компонентов

Чтобы встать на правильный путь, я начал с вопроса: как мне создать конструктор пользовательского интерфейса, используя самого себя? Я подумал, что если редактор можно использовать для сборки самого себя, то он сможет справиться практически с любым сложным случаем.

Логика была исключена из области видимости с самого начала, так как я не мог представить себе ни одного сценария, в котором я бы визуально построил редактор и всю его логику. Рукописный код - лучший носитель в этом случае. С другой стороны, внешний вид редактора можно построить визуально, и границы вокруг этого довольно четкие. Компоненты, слоты (возможность вставлять дочерние элементы в различные части компонента), варианты и динамические атрибуты - это на самом деле единственное, что необходимо для построения пользовательского интерфейса, поэтому я сосредоточился только на этих функциях, а также на API, который позволил бы представить презентационные приложения. компоненты, которые нужно связать с кодом.

Изначально я хотел создать что-то, что позволило бы пользователям свободно рисовать элементы холста без ограничений. Идея заключалась в том, чтобы пользовательский интерфейс был похож на Figma, а затем позволял пользователям комментировать элементы с информацией о макете после того, как они закончили, аналогично тому, как работает Pagedraw.

Я подумал, что если бы пользователи могли свободно перетаскивать элементы по холсту, подобному этому, следующей эволюцией было бы разрешение прямого импорта дизайнов Figma.

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

Свободное перетаскивание элементов по холсту часто приводит к созданию HTML и CSS, которые мне пришлось бы полностью реорганизовать, чтобы добавить информацию о макете. Это был беспорядок. Чтобы исправить это, я подумал о создании элементов управления пользовательского интерфейса поверх механизма пользовательского макета, который абстрагировал HTML и CSS, но это не казалось безопасным решением, учитывая, насколько сложным может быть CSS (честно говоря, вы можете многое сделать с ограниченный набор функций CSS, поэтому редактору не нужно делать все, но механизм настраиваемой компоновки все еще был слишком большим шагом). Мне нужно было работать над инструментами, которые, как я был уверен, могли бы справиться с любым случаем.

Я чувствовал, что для редактора было бы лучше направлять пользователя правильно писать HTML и CSS с самого начала, без абстракций . Это требовало взаимодействия с пользователем, которое было бы более дополнение к HTML и CSS. Вот мой первый взгляд на это:

Так было лучше. Затем я соединил некоторые файлы дизайна с исходным кодом редактора. На этом этапе я почти перестал писать код JSX и перешел к редактору пользовательского интерфейса.

Создавались элементы управления пользовательским интерфейсом. Вот ранний снимок экрана панели стилей:

Вот и редактор, наконец, превратился во что-то удобное:

В этот момент пользовательский опыт начинал казаться безупречным. Вот демонстрация создаваемого переключателя:

Перенесемся немного вперед, реализованы такие функции, как разделенные представления, глобальные переменные CSS и миксины:

К концу этого проекта редактор получил возможность запускать проекты с нуля, запускать команды CLI и запускать пользовательские интерфейсы в реальном времени.

На этом этапе я собирал отзывы о приложении. После нескольких десятков встреч 1: 1 с разработчиками и дизайнерами я получил в основном вялые отзывы. Некоторые люди были взволнованы, большинство - нет. Я понял, что построил нечто среднее между тем, чего хотели дизайнер и разработчик, не удовлетворив при этом полностью ни одну группу, включая меня самого. Дизайнерам не нравились ограничения CSS, а разработчики не хотели переключать среду, чтобы визуально редактировать HTML и CSS - просто большую часть времени проще писать вручную.

У меня было достаточно отзывов, чтобы потерять интерес. Не помогло и наличие ряда серьезных проблем:

  1. Файлы пользовательского интерфейса были в формате JSON, и вам нужно было использовать редактор для внесения изменений. Это создало всевозможные проблемы для таких вещей, как совместная работа, отладка и обслуживание. Было бы лучше использовать формат файла, который можно было бы читать и редактировать вручную.
  2. В некоторых случаях мешала панель стилей. Например, если бы я хотел добавить цвет фона, мне нужно было бы просмотреть все параметры, прежде чем я смогу это сделать. Как разработчик, я уже знаю свойство CSS большую часть времени (у меня также есть intellisense, который может мне помочь), поэтому его обычно легче вводить.
  3. Иногда мне требовалось странное поведение CSS, которое в то время могло быть представлено только в тексте: calc, псевдоэлементы (:before, :after) и другие незначительные функции CSS. Я мог бы добавить больше элементов управления пользовательского интерфейса для таких функций, но это был большой труд, на который у меня не было сил.

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

  1. Самым большим преимуществом редактора было то, что он был живым, и изменения сразу же появлялись.
  2. Панель стилей была полезна для тонкой настройки таких вещей, как цвета, типографика и тени.
  3. Изолированное создание презентационных компонентов было очень продуктивным, так как мне оставалось думать только о HTML и CSS. Граница между презентационными компонентами и логикой также была чистой и интуитивно понятной.
  4. Помимо нескольких проблем, связанных с моделью данных, в целом она неплохо масштабировалась. Черт возьми, мне удалось создать пользовательский интерфейс редактора прямо в редакторе!

С этим я решил начать все сначала.

V3: Создание визуальных инструментов, ориентированных на код

Первый редактор, который я создал, был разработан для обработки всего кода, и это не сработало, поскольку визуальные инструменты не всегда могут редактировать код приложения. Второй редактор, который я построил, мне не нравился отчасти потому, что JSON - плохое место для хранения сложных HTML и CSS. Это привело меня где-то посередине: крошечный язык, разработанный для визуального развития.

Я начал создавать язык шаблонов, который ограничивался презентационными компонентами. Он был достаточно выразительным, чтобы создавать большинство пользовательских интерфейсов, но достаточно ограниченным, чтобы позволить создать слой инструментов пользовательского интерфейса. Еще одна причина, по которой язык шаблонов был сосредоточен только на простом поведении, заключалась в том, что я не хотел запутывать логику. Логика входит в код приложения, код пользовательского интерфейса - на языке шаблонов (только HTML, CSS и примитивные компоненты).

Вот прототип, который я придумал:

Я назвал проект Paperclip, чтобы отразить его минимальность, легкость и совместимость с несколькими языками и фреймворками.

Одна из проблем, с которыми я столкнулся с предыдущим визуальным редактором, заключалась в том, что производительность начала снижаться для больших файлов, поэтому я решил создать самое быстрое, что я мог придумать: движок предварительного просмотра, встроенный в Rust. Файлы дизайна также были ограничены HTML и CSS, чтобы они оставались легкими и не оказывали давления на движок Rust. Вот что я сделал после многих месяцев полировки:

Я добавил инструменты измерения, монтажные области, палитры цветов и обновил синтаксис. Это было здорово, и казалось, что это шаг в правильном направлении.

Я представил Paperclip на своей работе (Hum Capital) чуть больше года назад и был невероятно рад тому, насколько он полезен для всех в команде. Еще предстоит пройти долгий путь, чтобы сделать Paperclip более доступным для дизайнеров и всех, кто хочет создавать пользовательские интерфейсы, и я продолжу работать со своей командой, чтобы помочь продвинуть Paperclip в этом направлении. Теперь, когда он немного повзрослел, я действительно счастлив поделиться им. В следующий раз я расскажу об этом подробнее!