Представления против компонентов в Ember.js


143

Я изучаю ember.js и пытаюсь понять разницу между представлением и компонентом. Я вижу и то, и другое как способ изготовления компонентов многократного использования.

С сайта Ember о просмотрах:

Представления в Ember.js обычно создаются только по следующим причинам:
-Если вам нужна сложная обработка пользовательских событий
-Когда вы хотите создать повторно используемый компонент

С сайта Ember о компонентах:

Компонент - это пользовательский тег HTML, поведение которого вы реализуете с помощью JavaScript, а внешний вид - с помощью шаблонов Handlebars. Они позволяют создавать повторно используемые элементы управления, которые могут упростить шаблоны вашего приложения.

Так в чем же главное отличие представления от компонента? И каков будет общий пример, где я предпочел бы использовать представление над компонентом и наоборот?

Ответы:


170

Ember.View

Ember.View в настоящее время ограничивается тегами, которые создаются для вас W3C. Но если вы хотите определить свои собственные HTML-теги для приложений, а затем реализовать их поведение с помощью JavaScript? Вы не можете сделать это на самом деле с Ember.View .

Ember.Component

Это именно то, что компоненты позволяют вам делать. На самом деле, это хорошая идея, что W3C в настоящее время работает над спецификацией Custom Elements .

Реализация компонентов Ember пытается максимально приблизиться к спецификации Web Components. Как только пользовательские элементы станут широко доступны в браузерах, вы сможете легко перенести компоненты Ember в стандарт W3C и использовать их в других средах, которые также приняли новый стандарт.

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

Также важно отметить, что Ember.Component на самом деле является Ember.View (подкласс), но он полностью изолирован . Доступ к свойству в его шаблонах идет к объекту просмотра, а действия нацелены также на объект просмотра . Нет доступа к окружающему contextили внешнему пространству, controller передается вся контекстная информация , что не относится к Ember.View, который действительно имеет доступ к окружающему его контроллеру, например, внутри представления, которое вы могли бы сделать что-то подобное, this.get('controller')что даст вам контроллер в настоящее время связан с представлением.

Так в чем же основное отличие представления от компонента?

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

И каков будет общий пример, где я предпочел бы использовать представление над компонентом и наоборот?

Следуя вышесказанному, это четко зависит от ваших вариантов использования. Но, как правило, если в вашем представлении вам нужен доступ к окружающему его контроллеру и т. Д., Используйте Ember.View , но если вы хотите изолировать представление и передать только ту информацию, которая ему необходима для работы, что делает его независимым от контекста и гораздо более многоразового использования, используйте Ember.Component .

Надеюсь, поможет.

Обновить

После публикации Road to Ember 2.0 вам теперь предлагается использовать компоненты вместо представлений в большинстве случаев.


1
Моя единственная забота о компонентах - это когда они становятся сложными. Я пока не знаю, как отделить логическую часть от части рендеринга. По обычным представлениям, у вас есть это разделение, и вы можете поместить логику в контроллер, но с компонентом, я склонен сказать, что в итоге у вас будет очень сложный и, возможно, огромный беспорядок. Знаете ли вы, можно ли определить выделенный контроллер, как для компонентов? Или, возможно, компоненты просто не предназначены для управления сложными графическими элементами.
sly7_7

3
@ sly7_7, да, я понял твою точку зрения. Но я бы подумал о компоненте как о чёрном ящике, который ведет себя только на основе данных, которые он передает. И да, в зависимости от того, что он делает, это может очень быстро стать беспорядком. Выделенный контроллер имел бы абсолютный смысл, и способ, которым он мог бы работать, состоял бы в том, чтобы компоненты могли стать логикой, внедренной в него, но, насколько я знаю, компоненты не являются частью контейнера ember по своей конструкции, я думаю, но это может измениться в будущем на решить именно так, как это. Хороший вопрос в любом случае!
интуитивно-понятный

2
Могут ли какие-либо привязки выходить из компонента? IE, с блочной формой компонента, могут ли элементы содержимого в блоке связываться со свойствами компонента, или я должен использовать представление в этом случае?
Майкл Джонстон

2
ах, да, они могут. {{view.xxxx}}работает в компоненте так же, как в представлении.
Майкл Джонстон

Комментарии Тома Дейла к этой теме: ember.zone/the-confusion-around-ember-views-and-components/…
Акшай Рават,

17

Ответ прост: используйте компоненты

Согласно обучающему видео, которое было записано в августе 2013 года, Йехуда Кац и Том Дейл (члены Ember Core Team) сказали аудитории не использовать представления, если вы не являетесь разработчиком фреймворка. Они внесли много улучшений в Handlebars и представили компоненты, поэтому представления больше не нужны. Представления используются внутри для питания таких вещей, как {{#if}} и ​​{{outlet}}.

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

Обновление 2014-11-27

Теперь еще важнее использовать компоненты вместо представлений, поскольку Ember 2.0 будет использовать Routable Components при вводе маршрута вместо контроллера / представления. Для того, чтобы ваше приложение было в будущем, лучше держаться подальше от Views.

Источники:


5
«Если вам кажется, что вам нужно использовать представление, используйте вместо него компонент». Это ужасный совет, и он выдает непонимание той изоляции, которая связана с компонентами.
jmcd

@jmcd, хотя этот комментарий исходил от самих разработчиков фреймворка, я его убрал.
Джонни Ошика

2
Я нашел источник: видео обучение Gaslight, видео 10.3 Компоненты Q & A @ 26m mark. Том говорит: «Поскольку эти примеры были написаны, мы добавили Компоненты, которых не было на момент написания этих примеров. В общем, я бы сказал, что Views - это не то, что мы ожидаем от большинства разработчиков, а скорее внутренний объект бухгалтерского учета »
jmcd

2
@jmcd, в этом видео @ 26:15 Том говорит, что "в основном не использует виды". Кроме того, если вы прыгаете на 30 м в том же видео, Иегуда Кац говорит: «По сути, View - это внутренняя деталь реализации ... вы можете использовать View, но тогда вы разработчик фреймворка. Вместо этого вы должны использовать одну из вещей». то, что мы создали для вас, использует View, и тот, который ближе всего к View, но имеет лучшую семантику, - это Component. Все, что вы могли использовать для View раньше, Component - это хорошо. "
Джонни Ошика

5

В v2.xнынешнем стабильном выпуске представления полностью устарели. Говорят, что представления удаляются из API Ember 2.0 .

Итак, использование {{view}}ключевого слова в Ember 2.0 вызовет утверждение:

Утверждение не удалось: использование {{view}}или любой путь на его основе был удален в Ember 2.0

Если вам нужно использовать представления в Ember 2.0, вы можете использовать дополнение ember-legacy-views , которое будет совместимо с Ember до версии 2.4 .

Итак, подведем итог - компоненты - это настоящее (удаляются представления) и будущее - они также заменят контроллеры. См. Маршрутизируемые компоненты RFC .

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.