Как "подружить" дизайнера и инженера? Как дать им работать с одними и теме же данным, без ущерба продуктивности? Как хранить дизайн в системе контроля версий. Если вас интересуют эти вопросы, в такой же степени как и меня, то добро пожаловать под кат!
Данная статья — это прямое продолжение "Хватит это верстать, ударим автоматизацией по макетам" и является результатом моих исследований интересующей меня проблемы.
В первой части, я вкратце описал проблематику как самой вёрстки, так и её автоматизации. Также поделился своими результатами исследования этой темы. Остановился же я на вопросе контролируемости автоматизируемой вёрстки.
В данной статье я раскрою более подробно это понятие и поделюсь результатами своих исследований.
Хочеться с чем-то поиграться? Вот проверка концепции.
Контролируемость
А о какой контролируемости вообще идёт речь?
Я выделил два основных положения:
- Возможность влиять на процесс генерации 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 аккаунта и приглашаю всех заинтересованных следить за процессом, там я буде постить свои мысли о проблеме и текущее состояние работы, а если сойдутся звёзды, то и на результат — свободный редактор для всех, чтобы "сдвинуть это веб".
А вдруг у кого-то возникло желание помочь, это было бы супер. Помощь нужна, в первую очередь, с визуальным редактором, часть важная, но не целевая. Или подсказать удобный для работы и кастомизации модуль. И конечно, привлечение внимания к моей работе и проблематике будут не менее полезна.
Разумеется, буду очень рад видеть конструктивную критику и дискуссию.
Всем мир!