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

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

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

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

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

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

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

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

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

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

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

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

Решение

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

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

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

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

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

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

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

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

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

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

Движок

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Связь

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

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

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

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

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

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

Состояние

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

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

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

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

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

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

Ограничения

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

Вывод

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

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

Что дальше?

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

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

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

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

Всем мир!

Хватить это верстать дважды или 2-х сторонняя связь между дизайном и кодом