Перегляди проти компонентів у Ember.js


143

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

З веб-сайту Ембер про перегляди:

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

З веб-сайту Ембер про компоненти:

Компонент - це спеціальний тег HTML, поведінку якого ви реалізуєте за допомогою JavaScript та зовнішній вигляд якого описуєте за допомогою шаблонів рульових панелей. Вони дозволяють створювати елементи багаторазового використання, які можуть спростити шаблони вашої програми.

Отже, яка головна відмінність між видом і компонентом? І що може бути загальним прикладом, коли я вважаю за краще використовувати погляд на компонент і навпаки?

Відповіді:


170

Ember.View

Ember.View в даний час обмежується тегами, які створюються для вас W3C. Але якщо ви хочете визначити власні HTML-теги для додатків, а потім реалізувати їх поведінку за допомогою JavaScript? Насправді це не можна зробити за допомогою Ember.View .

Ембер.компонент

Саме це дозволяє вам робити компоненти. Насправді це така гарна ідея, що W3C зараз працює над специфікацією Custom Elements .

Реалізація компонентів Ембер намагається максимально наблизитись до специфікації веб-компонентів. Як тільки користувальницькі елементи будуть широко доступними у браузерах, ви зможете легко перенести компоненти Ember до стандарту W3C, і вони зможуть користуватися іншими структурами, які також прийняли новий стандарт.

Для нас це так важливо, що ми тісно співпрацюємо з органами зі стандартів, щоб забезпечити, щоб наша реалізація компонентів відповідала дорожній карті веб-платформи.

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

Отже, яка головна відмінність між видом і компонентом?

Отже, основна відмінність, крім того, що компоненти дозволяють вам створити власні теги і в якийсь момент в майбутньому, коли користувацькі елементи доступні, також мігруватимуть / використовувати ті компоненти в інших структурах, які підтримуватимуть користувацькі елементи, насправді полягає в тому, що в якийсь момент компонент вугілля зробить вигляд дещо застарілим залежно від конкретного випадку реалізації.

І що може бути загальним прикладом, коли я вважаю за краще використовувати погляд на компонент і навпаки?

Дотримуючись вищесказаного, це чітко залежить від ваших випадків використання. Але, як правило, якщо вам потрібен доступ до оточуючого контролера і т.д., використовуйте a Ember.View , але якщо ви хочете виділити подання і передати лише ту інформацію, яка йому потрібна для роботи, зробивши його контекстно-агностичним та багато іншого для багаторазового використання, використовуйте Ember.Component .

Сподіваюся, це допомагає.

Оновлення

Опублікувавши « Дорогу до Ембер 2.0», у більшості випадків вам пропонується використовувати компоненти замість перегляду.


1
Моє єдине занепокоєння щодо компонентів - це коли вони стають складними. Я ще не знаю, як відокремити логічну частину від частини візуалізації. Я регулярно переглядаю, у вас є це розділення, і ви могли б ввести логіку в контролер, але з компонентом, як правило, я кажу, що у вас буде дуже складний і, можливо, величезний безлад в ньому. Чи знаєте ви, чи можна визначити виділений контролер для компонентів? Або, можливо, компоненти просто не призначені для управління складними графічними елементами.
sly7_7

3
@ sly7_7, так, я розумію. Але я б подумав про компонент як про чорну скриньку, поводячись лише на основі даних, які він отримує. І так, залежно від того, що це робиться, це може швидко заплутатися. Виділений контролер мав би абсолютний сенс, і таким чином він міг би працювати, якби компоненти могли стати логікою, що вводиться в нього, але, наскільки я знаю, компоненти не є частиною контейнера вугілля, я думаю, але це може змінитися в майбутньому на вирішити саме щось подібне. Гарний момент все одно!
інтуїтивно зрозумілий

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

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

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

17

Відповідь проста: використовуйте компоненти

Згідно з навчальним відео, яке було записане в серпні 2013 року, Єгуда Катс і Том Дейл (члени основної команди Ембер) сказали присутнім не використовувати перегляди, якщо ви не розробник рамки. Вони вдосконалили руль та ввели компоненти, тому перегляди більше не потрібні. Перегляди використовуються всередині для живлення таких речей, як {{#if}} та {{outlet}}.

Компоненти також тісно імітують стандарт веб-компонентів, який буде вбудований у браузер, тому існує безліч побічних переваг, щоб стати зручною побудовою Ембер Компоненти.

Оновлення 2014-11-27

Зараз ще важливіше використовувати компоненти замість представлень, оскільки Ember 2.0 використовуватиме маршрутизовані компоненти при введенні маршруту замість контролера / перегляду. Щоб у майбутньому підтвердити свою програму, краще триматися подалі від поглядів.

Джерела:


5
"Якщо вам здається, що вам потрібно використовувати подання, замість цього використовуйте компонент." є жахливою порадою, і зраджує нерозумінням ізоляції, яка стосується компонентів.
jmcd

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

2
Я знайшов джерело: відео-навчання Gaslight, відео 10.3. Компоненти Q&A @ 26m. Том каже: '' Оскільки ці приклади були написані, ... ми додали компоненти [які] не існували, коли ці приклади були написані. Взагалі, я б сказав, що перегляди - це не те, чого ми очікували б, що більшість розробників пише, вони є більш внутрішнім об’єктом бухгалтерського обліку в цей момент '
jmcd

2
@jmcd, У цьому відео @ 26:15 Том каже, що «в основному не використовую перегляди». Крім того, якщо ви скачете на 30 м у тому ж відео, Єгуда Кац каже: "Перегляд - це в основному внутрішня деталь реалізації ... ви можете використовувати View, але тоді ви розробник рамки. Натомість вам слід використовувати одну з речей що ми створили для вас, який використовує View, і той, який найближчий до View, але має кращу семантику, - це компонент. Все, для чого ви могли раніше використовувати View, компонент добре. "
Джонні Ошика

5

Як зараз, - v2.xтеперішній стабільний випуск - погляди повністю застаріли. Кажуть, що видалення видаляються з API Ember 2.0 .

Отже, використання {{view}}ключового слова в Ember 2.0 викличе твердження:

Не вдалося стверджувати: Використання {{view}}або будь-який шлях, заснований на ньому, було видалено в Ember 2.0

Якщо вам потрібно використовувати представлення даних у Ember 2.0, ви можете використовувати аддон ember-legacy-views addon, який буде сумісний з Ember до версії 2.4 .

Отже, підводячи підсумок - компоненти є теперішнім (видалення видаляються) та майбутнє - вони також замінять контролери. Див. Компоненти маршрутизації RFC .

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.