Введение в NikaFramework (NKF). Часть 2

Продолжение первой части.

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

Что делает система сборки проекта?
Одну простую вещь — берет все файлы, упаковывает их определенным способом и на выходе у нас один, единственный файл — index.xhtmlz.
Это позволяет разработчику создавать сколь угодное количество файлов, напр., делить классы на несколько подклассов, писать стили в нескольких файлах, создавать XHTML заготовки для любого случая жизни.

К тому же, позже мы можем доступиться до тех же ресурсов (XHTML, SVG, JSON) при помощи унаследованных методов без прибеганию к AJAX, так как все эти ресурсы уже находятся в index.xhtmlz.

Если рисунки используются в XHTML либо в стилях (CSS/Sass), то система сборки проекта преобразует их в data:URL, при использовании base64.

index.xhtmlz:

DOM:

В будущем планируется внести поддержку «annotations», при использовании которых ресурс не должен преобразовываться в data:URL, что может быть полезно для очень больших файлов, напр., видео.

У системы сборки проекта — два режима. development и production. В development (по умолчанию) все ресурсы упаковываются, но JS не сжимается и не обфускируется.
В production режиме — идет дополнительное сжатие. В конце работы (в любом из режимов) —
файл сжимается в zip формат, что дает экономию по трафику.

Система сборки проекта написана на NodeJS и в среднем занимает 1 сек в development режиме для среднего проекта (350 файлов).

Преимущество использования все время компиляции (сборки проекта) — это то, что у вас всегда код, который отвечает боевым условиям, то есть production режиме.
Так как часто бывает, при использовании отдельно подключаемый script/link тегов все работает нормально, а позже когда все упаковывается в один файл, начинают вылезать косяки.

5. Семантика генерируемого DOM
Как часто вам приходилось инспектировать элемент (Firebug, Web Developer), а потом искать по всему коду его имплементацию? NKF решает эту проблему тем, что он знает к какому типу компонента относиться каждый компонент, и сам генерирует DOM понятный для быстрого нахождения компонента.

data-nkf-component-type — тип компонента
data-nkf-component-name — название компонента

6. Локализация на лету
Это возможность без перезагрузки менять локаль на другую. Сделано это при помощи data-* аттрибута data-lang-*.

Напр.

<label data-lang-textcontent="{{Search}}" data-lang-title="{{Search!}}"/>

будет в конечном итоге вот так, для англ.

<label data-lang-textcontent="{{Search}}" data-lang-title="{{Search!}}" title="Search!">Search</label>

или вот так для рус.

<label data-lang-textcontent="{{Search}}" data-lang-title="{{Search!}}" title="Поиск!">Поиск</label>

Файлы локализации создаются в директории /data/lang в виде обычных JSON файлов.

Напр.

ru.json:

{
	"translate":{
		"Search": "Поиск",
		"Products": "Продукция"
		....
	}
}

Так же возможная частичная локализация сгенерированной части DOM и даже CSS (content).

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

В следующей части я покажу как создавать приложения используя данный фреймворк.

P.S. Конструктивная критика и идеи по улучшению приветствуются.

Автор: siegerstein

Источник