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

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

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

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

Самый простой способ увидеть, как это работает - скачать нашу демо-версию с github. После загрузки перейдите в каталог frontend.src и запустите

npm install
gulp ui

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

Откройте код в редакторе и просмотрите пример страницы _dev / _templates / src / pages / examplePage, вы увидите 3 файла и каталог данных.

  • _examplePage.scss: файл scss для этой страницы.
  • examplePage.hbs: файл ручек для этой страницы
  • examplePage.schema: файл схемы json, который определяет допустимые данные для этого блока.

В каталоге данных есть единственный файл, содержащий данные, которые используются для создания примера, который мы видели в браузере. Для каждого файла данных создается один пример HTML-файла.

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

"gridItems": [
        {
            "$ref" : "/parExampleBlock"
        },
        {
            "$ref" : "/parExampleBlock_2"
        },
        {
            "$ref" : "/parExampleBlock_3"
        }
    ]

Данные хранятся для блока в его каталоге данных, если вы перейдете в каталог блока _dev / _templates / src / blocks / exampleBlock, вы увидите 3 файла в каталоге данных, это файлы, которые указаны в файле json страницы примера.

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

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

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

Макеты

Они определены в каталоге _dev / _templates / layouts и определены как минимум два; каждый для страниц и примеров блоков. У нас есть отдельный макет блока, чтобы мы могли исключить верхний или нижний колонтитул из примеров блоков и отображать их полностью изолированно. Каждый файл макета имеет свой собственный файл данных json, определяющий, что будет отображаться. К сожалению, в настоящее время ссылки на файлы json не включены в файлах формата json с данными макета, поэтому этот файл должен содержать все данные, включая любые используемые блоки.

Вы можете добавить свои собственные макеты, добавив новый файл данных hbs и json. Чтобы обозначить позицию в коде, куда вставлено содержимое страницы, используйте

{{{ contents }}}

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

Чтобы использовать этот новый макет на любой странице, добавьте файл данных json с именем макета, как показано ниже.

examplePage_2.layout2.json

Это создаст новое состояние примера с именем 2.layout2, которое использует файл layout2. Таким образом, мы можем использовать разные состояния для отображения поведения страницы с использованием разных макетов.

Отображение полных данных на странице

Поскольку страница json создается с использованием ссылок на файлы json, в редакторе кода нет возможности просмотреть полностью составленный файл json, который используется для визуализации страницы. Внизу страницы макета находится ссылка на специальный партиал handlebars, который записывает этот полный json-файл внизу страницы.

{{> parRawJson}}

Схема

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

Стиль

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

Помощники

Мы используем несколько помощников по рулям, чтобы упростить разработку решений. Поскольку мы также рендерим эти hbs-файлы в производственном решении, важно, чтобы обе версии Helper выдавали одинаковый результат. Ниже приведены помощники по умолчанию, которые мы используем в каждом проекте.

Модификаторы

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

{{{ modPartial ‘parExampleBlock’ this ‘block-left’ }}}

Хелпер modPartial принимает 3 параметра; имя блока, свойство данных и класс модификатора для внедрения. Класс добавляется к объекту данных в рамках измененного блока, поэтому вы можете использовать приведенный ниже

<div class=”block-example {{modifier}}”>
</div>

Он внедрит класс модификатора «block-left» для модификатора свойства.

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

IfCond

Это распространяется на помощник if в панелях обработчиков для включения операторов

{{#ifCond type ‘===’ “example”}}
  {{> parExampleBlock this}}
{{/ifCond}}

Это взято с этой страницы stackoverflow

Http://stackoverflow.com/questions/8853396/logical-operator-in-a-handlebars-js-if-conditional

Определение блока

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

Переход к производству

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

gulp dist

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

В нашем процессе непрерывной доставки мы запускаем dist на сборке сервера, чтобы позволить разработчикам интерфейса обновить промежуточный сайт без предварительного завершения дистрибутива локально. Пока формат файлов данных json не изменился, новое обновление изменит пользовательский интерфейс сайта без какого-либо вмешательства.

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