Как "подружить" дизайнера и инженера? Как дать им работать с одними и теме же данным, без ущерба продуктивности? Как хранить дизайн в системе контроля версий. Если вас интересуют эти вопросы, в такой же степени как и меня, то добро пожаловать под кат!


Данная статья — это прямое продолжение "Хватит это верстать, ударим автоматизацией по макетам" и является результатом моих исследований интересующей меня проблемы.


В первой части, я вкратце описал проблематику как самой вёрстки, так и её автоматизации. Также поделился своими результатами исследования этой темы. Остановился же я на вопросе контролируемости автоматизируемой вёрстки.


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


Контролируемость


А о какой контролируемости вообще идёт речь?
Я выделил два основных положения:


  1. Возможность влиять на процесс генерации HTML кода.
  2. Прямое редактированию результата, которое будет учтено при последующей генерации.

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


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


Проблематика


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


Таким образом построение интерфейса и приложений на данном подходе является весьма затруднительным. Не говоря уже о качестве генерируемого кода. Этого вполне достаточно для решаемых задач подобных сервисов, как генераторы лендингов или прототипирования. Но для приложений, максимум на что они пригодны — быть быстрым стартом для чего-то более сложного.



Решение


Главная идея — если макеты делаются для создания HTML документа, то весь макет можно описать в HTML и CSS.


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



Но если макет описан в HTML документе, то что мешает разработчику открыть код и дописать логику, оживить макет там, где это невозможно сделать с использование визуального редактора? Ответ — ничего, да с оговорками, но это возможно.
Таким образом у нас появляется 2х сторонняя связь между инструментом дизайна и исходным кодом.


Возможно, кто-то скажет, что это звучит как утопия, Unity 3D, скажу я в ответ.


Unity, как и любой другой игровой движок уже давно реализовали подобную концепцию в своих инструментах.


Моё мнение, единственное препятствие внедрения подобного подхода в веб индустрии и производных — высокие требования к HTML разметке, этот вопрос я более подробно рассмотрел в предыдущей статье.


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



Хорошо, я хочу иметь что-то типа Unreal Engine, но для WEB. С чего вообще начать?
У меня есть на руках:


  1. Простой Drag&Drop визуальный редактор;
  2. Концепт модуля генерации разметки;
  3. Какой-то HTML код, что я хочу редактировать.

Первым вопросом стало, как это всё объединить вместе.


Движок


Любой движок состоит из модулей, значит с этого и стоит начать.


Ух, тут прям в голову начинают лезть мысли о модуле мокирования api, тестирования, управлением хранилищем, создания анимации, оптимизации, работы с зависимостями, документирования…



Но стоит поумерить пыл и вернуться к текущей проблематике.


Модуль отображения


Возможно вопрос и очевидный, но вообще, что мы и где рисуем?


У нас есть HTML код, который мы должны чем-то прочитать и отобразить. Логичным выбором тут будет самый популярный рендер — WebKit Blink, его мы используем как модуль отображения(рендеринга).


Модуль чтения-записи


А вот с модулем чтения всё не так очевидно. Пока речь идёт о единой точки входа (весь код лежит в index.html), никаких проблем нет. Но реальное приложение может иметь сколь угодно сложную архитектуру и храниться в любом формате.
Пока видится 3 варианта как с этим справиться:


  1. Работа с финальным кодом, с промежуточным рендерингом;
  2. Максимальное покрытие всех стеков популярных технологий;
  3. Строгое стандартизирование.

Чистого варианта тут нет, каждый имеет свои минусы.


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


Первый же вариант кажется очень перспективным, но с рядом сложных моментов, решение которых может оказаться дольше, чем 2.


Из очевидных проблем:


  1. Сопоставлени промежуточного с оригинальным;
  2. Приведение промежуточного кода, к формату оригинального.

Проблемы интересные и требуют исследований.


Модуль создания разметки


По всей видимости, самая простая часть.


Модуль визуального взаимодействия


А с чем мы вообще можем взаимодействовать?


Вот так выглядит дерево на одном из лендингов, описывающее 2 блока, лежащие рядом.



Глядя на него, вспоминается Adobe Illustrator в котором, чтобы добраться до нужного элемента, нужно кликнуть на одно и то же место 2 * N раз. Если там это оправдано, то в редакторе интерфейса это совсем неуместно.


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


Этот факт хорошо иллюстрирует следующую концепцию — не весь HTML код значим одинаково.


Из этого сформулируем правило. HTML код делится на:


  1. Значимый и;
  2. Незначимый.

Пользователь взаимодействует со значимыми элементами.


Причём значимым может быть как код, описывающий внешний вид, так и структуру дерева — группировки, позиционирование и тп.


Сам же редактор должен соответствовать всем ожиданиям дизайнера.


Связь


А что мы вообще имеем и что с чем связываем?
У нас есть:


  1. Код, как источник правды;
  2. DOM дерево;
  3. Визуальное отображение.

При изменении кода, меняется DOM, что приводит к перерисовки отображения.



При изменении визуального отображения мы можем:


  1. Изменить DOM, сохранить производный результат в код.
  2. Изменить код, что приведёт к изменению DOM.


Каждый из вариантов приведет к перерисовки отображения.


Состояние


Но каков жизненный цикл DOM? Помимо редактора, его может менять и логика.


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



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


Всё вышеописанное звучит так, что в пору дождаться сильного ИИ, а пока оставить данное занятие… Или вводить ограничения.
Снова обратимся к сравнению с игровыми движками. Там всегда есть как минимум 2 режима:


  1. Редактор;
  2. Предпросмотр.

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


Что же касается остальных, то я бы разделил их на 2 типа состояний:


  1. Ручные, те что может понять редактор и дать над ними контроль;
  2. Автоматические, непонятные редакторому, управляемые программно.

Отличным примером ручных будет Pagedraw с его редактором состояний и переходом между ними.


Но всё таки данная темя является одной из самых сложных, и требует гораздо более глубокие и тщательные исследования.


Резюме


Из вышеописанного складывается следующий концеп:


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


Редактирование же состояний является отдельной задачей и может быть осуществлено как визуально, так и через код. Компоненты же формирую библиотеку. Это всё будет накладывать определенные правила и ограничения.


Проверка концепции


Для проверки концепции необходимо реализовать режим редактирования, в котором изменения в визуальном редакторе сразу влияют на код, а изменения в коде также сразу видны и в визуальном редакторе.


Код же выступает источником правды и хранит данные репрезентации, мета информацию, и структуру (контейнер-потомок).


Последующие же открытие кода восстанавливает состояние визуального редактора.


Вооружившись данным знанием, реализуем это в коде.


Ограничения


  1. Значимыми элементами считаются те, у кого есть класс или идентификатор;
  2. К элементам не применяются сторонние эффекты;
  3. Идентификатор является уникальным, повторное использование приведёт к неожиданным последствиям;
  4. Большинство крайних случаем не рассмотрены;
  5. Ошибки ожидаемы;
  6. Компоненты и состояни не реализованы;
  7. Код в HTML формате.
  8. Передвижение контейнера с потомками возможно при "захвате" пустого места


Вывод


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


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


Что дальше?


У меня есть ещё месяц свободного времени, так что достаточно игры в "кубики", пришло время реализовать чистовую модель редактора. Для начала, в качестве целевого стека, буду использовать React, а точнее JSX + styled-components, как наиболее используемый и изученный.


Данный процесс может занять довольно длительное время, понимая это, я смахнул пыль со своего twitter аккаунта и приглашаю всех заинтересованных следить за процессом, там я буде постить свои мысли о проблеме и текущее состояние работы, а если сойдутся звёзды, то и на результат — свободный редактор для всех, чтобы "сдвинуть это веб".


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


Разумеется, буду очень рад видеть конструктивную критику и дискуссию.


Всем мир!