Представления против компонентов в 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.