Ниже представлен вольный перевод статьи What«s coming in ember in 2014. Рассматриваются текущие вопросы и задачи, которые стоят перед командой разработчиков Ember и которые планируется решать в 2014 году.

Средства для сборки и поддержка модульности

Когда Ember только создавался еще не было популярных форматов модулей для JavaScript. Однако в последнее время модульность стала довольно популярной темой и всё сильнее набирают популярность такие средства как CommonJS (для сервреной стороны) и AMD (для клиентской части). Оба подхода достаточно хороши, но это принципиально различные и как следствие трудно совместимые подходы.

К счастью TC39 — коммитет по стандартизации JavaScript осознал необходимость унифицированной системы модулей. Предложенная ими система ES6 использовала лучшие стороны CommonJS и AMD и внедрила непосредственно в язык. При этом сосуществуют оба подхода позволяя использовать сильные стороны каждого.

Сообщество Ember всегда было на гребне волны новых технологий. Например мменно в Ember начали широко использоваться promises. Здесь разработчики тоже не подкачали и несколько месяцев было потрачено на реализацию в Ember поддержки ES6. В результате возникли следующие проекты.

• ES6 Module Transpiler — утилита для преобразования модулей из синтаксиса ES6 в набор AMD и CommonJS

• Ember App Kit — набор CLI средств для построения Ember приложений

Таким образом первый квартал 2014 года будет посвящён разработке новых CLI средств разработки. Приложения Ember будут полностью использовать ES6 и побуждать к этому разработчиков.

Новые свойства инспекторов

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

Это позволит делать такие вещи как:

• просматривать список установленных bower пакетов
• видеть результаты выполнения тестов
• проводить аудит кода
• конфигурировать приложение используя визуальные средства

Структура файлов проекта

Структура созданного Ember приложения выглядит примерно так:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

app/
  controllers/
  models/
  fonts/
  …
config/
  shim.json
vendor/
  underscore.js    // bower installed
  markdown.js
lib/
  ember-histogram/ // incubator for packages
    skylight/
    bower.json
modules/           // non-MVC stuff
  underscore.js

Pods

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

1
2
3
4
5
6
7
8
9
10
11
12

app/
  controllers/
    post.js
    posts.js
    index.js
  models/
    post.js
    user.js
  templates/
    post.handlebars
    posts.handlebars
    index.handlebars

Предполагается использовать в Ember несколько иную структуру — группировать файлы в некие pods согласно их функционалу, т. е. например группировать контроллеры и соответствующие шаблоны вместе в одной папке.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

app/
  config/
    application.js
  serializers/
  models/
    post.js
    user.js
  mixins/
pods/
  post/
    controller.js
    template.handlebars
  posts/
    controller.js
    template.handlebars
  index/
    controller.js
    template.handlebars
components/
  google-map/
    component.handlebars
    component.js
    component.css

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

Уменьшение размера кода

Нет сомнений код Ember довольно сильно раздут. Одним из улучшений запланированных на 2014 год будет уменьшение размера кода. Разработчики планирую ужать код до размера порядка 50kБ. Цифра еще не окончательная и возможно будет еще скорректирована.

Компоненты

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

Ещё одним ограничением является то, что в старых браузерах отсутствуют некоторые возможности используемые в Web Components и требуются обходные пути для разрешения этих проблем. В частности есть определённые проблемы с IE8.

Пространство имён (namespacing)

В данный момент компоненты Ember используют глобальное пространство имён. Соответственно если два компонента имеют одинаковое имя то при их одновременном использовании возникнет конфликт.

Но вскоре эта проблема будет решена. Пример синтаксиса для использования компонента area-graph из пакета d3

1

\{\{area-graph@d3 xValue=responseTimes}}

1

\{\{import "area-graph" from "d3"}}

Можно так-же подключить все компоненты из пакета

1

\{\{import "d3"}}

Будем надеяться эты фича появится в этом году. Хотя к счастью пока не так уж много компонент для Ember и ситуация с конфликтом имён выглядит маловероятной.

TEMPLATE VERSIONING/COMPILATION

Handlebars компилирует шаблоны в промежуточное AST. Формат AST может изменяться между версиями Handlebars. Кроме того к версии 2.0 Handlebars может расширить синтаксис или даже его существенно изменить.

В связи с этим встает вопрос должны ли компоненты, распространяемые через bower поставляться с предварительно скомпилированными шаблонами, или лучше компилировать их „на лету“ средствами Ember?

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

Scoped CSS

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

HTMLBars

Одно из самых интересных нововведений. HTMLBars это новый, активно развивающийся проект по интеграции Handlebars с DOM. Это позволит реализовать биндинг более элегантным способом чем это сделано в Ember сейчас. Несколько примеров:

В данный момент биндинг реализован следующим образом

1

<img \{\{bind-attr src=imageUrl}}>

Используя HTMLBars получим следующую конструкцию

1

<img src="\{\{imageUrl}}">

Но более приятный синтаксис это еще не самое главное — гораздо интереснее то как будет выглядеть DOM после рендеринга. Наконец-то Ember больше не будет втыкать в DOM лишние элементы. Я уверен, что многих разработчиков раздражали вставки кода типа

1
2
3

<script id="metamorph-17-start" type="text/placeholder"></script>
...
<script id="metamorph-17-end" type="text/placeholder"></script>

которые хоть и были необходимы для биндинга, но без сомнений засоряли DOM и в ряду случаев сильно осложняли жизнь (например при генерации таблиц)

Разработчики планируют внедрить HTMLBars уже в этом году.

Избавление от jQuery

В связи с тем, что в Ember запланирован переход на HTMLBars, взаимодействие Ember с DOM становится минимальным. Соответственно исчезает зависимость от jQuery, хотя jQuery может быть использована опционально если уже используется глобально или подключена через AMD.

Анимация

Будут проводиться работы по внедрению в Ember анимационных эффектов. Но в данный момент не опубликовано какого-то API для анимации т. к. команда не хочет публиковать сырой продукт.

Поддержка IE8

Ember будет поддерживать версии Internet Explorer вплоть до 8 версии включительно. Связано это с желанием охватить кроме всего прочего корпоративный сектор.