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

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


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


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


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


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


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


    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 аккаунта и приглашаю всех заинтересованных следить за процессом, там я буде постить свои мысли о проблеме и текущее состояние работы, а если сойдутся звёзды, то и на результат — свободный редактор для всех, чтобы "сдвинуть это веб".


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


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


    Всем мир!

    Похожие публикации

    Средняя зарплата в IT

    111 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 7 185 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое