Ember.View в настоящее время ограничивается тегами, которые создаются для вас W3C. Но если вы хотите определить свои собственные HTML-теги для приложений, а затем реализовать их поведение с помощью JavaScript? Вы не можете сделать это на самом деле с Ember.View .
Это именно то, что компоненты позволяют вам делать. На самом деле, это хорошая идея, что 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 вам теперь предлагается использовать компоненты вместо представлений в большинстве случаев.
{{view.xxxx}}работает в компоненте так же, как в представлении.Ответ прост: используйте компоненты
Согласно обучающему видео, которое было записано в августе 2013 года, Йехуда Кац и Том Дейл (члены Ember Core Team) сказали аудитории не использовать представления, если вы не являетесь разработчиком фреймворка. Они внесли много улучшений в Handlebars и представили компоненты, поэтому представления больше не нужны. Представления используются внутри для питания таких вещей, как {{#if}} и {{outlet}}.
Компоненты также имитируют стандарт веб-компонентов, который будет встроен в браузер, поэтому есть много дополнительных преимуществ для удобного создания Ember Components.
Обновление 2014-11-27
Теперь еще важнее использовать компоненты вместо представлений, поскольку Ember 2.0 будет использовать Routable Components при вводе маршрута вместо контроллера / представления. Для того, чтобы ваше приложение было в будущем, лучше держаться подальше от Views.
Источники:
источник
В
v2.xнынешнем стабильном выпуске представления полностью устарели. Говорят, что представления удаляются из API Ember 2.0 .Итак, использование
{{view}}ключевого слова в Ember 2.0 вызовет утверждение:Если вам нужно использовать представления в Ember 2.0, вы можете использовать дополнение ember-legacy-views , которое будет совместимо с Ember до версии 2.4 .
Итак, подведем итог - компоненты - это настоящее (удаляются представления) и будущее - они также заменят контроллеры. См. Маршрутизируемые компоненты RFC .
источник