Ember.View jest obecnie ograniczony znacznikami, które są tworzone przez W3C do. Ale gdybyś chciał zdefiniować własne tagi HTML specyficzne dla aplikacji, a następnie zaimplementować ich zachowanie za pomocą JavaScript? W rzeczywistości nie możesz tego zrobić za pomocą Ember.View .
Dokładnie to umożliwiają komponenty. Właściwie to taki dobry pomysł, że W3C pracuje obecnie nad specyfikacją elementów niestandardowych .
Implementacja komponentów w Ember stara się być jak najbliżej specyfikacji Web Components. Gdy elementy niestandardowe staną się powszechnie dostępne w przeglądarkach, powinieneś mieć możliwość łatwej migracji komponentów Ember do standardu W3C i umożliwienia ich używania również przez inne frameworki, które przyjęły nowy standard.
Jest to dla nas tak ważne, że ściśle współpracujemy z organami normalizacyjnymi, aby upewnić się, że wdrażanie komponentów jest zgodne z mapą drogową platformy internetowej.
Należy również zauważyć, że Ember.Component jest w rzeczywistości Ember.View (podklasą), ale jest całkowicie odizolowany . Dostęp do właściwości w jego szablonach prowadzi do obiektu widoku, a działania są również kierowane na obiekt widoku . Nie ma dostępu do otaczających contextlub zewnętrznych controller informacji kontekstowych , które są przekazywane , co nie ma miejsca w przypadku Ember.View, który rzeczywiście ma dostęp do otaczającego go kontrolera, na przykład wewnątrz widoku można zrobić coś takiego, this.get('controller')co dałoby kontroler aktualnie powiązany z widokiem.
Jaka jest więc główna różnica między widokiem a komponentem?
Tak więc główna różnica, poza tym, że komponenty pozwalają tworzyć własne tagi, aw pewnym momencie w przyszłości, gdy będą dostępne elementy niestandardowe, będą również migrować / używać tych komponentów w innych strukturach, które będą obsługiwać elementy niestandardowe, w rzeczywistości jest to, że w pewnym momencie komponent ember sprawi, że widok będzie nieco przestarzały, w zależności od konkretnego przypadku wdrożenia.
A jaki byłby typowy przykład, w którym wolałbym użyć widoku komponentu i odwrotnie?
Postępując zgodnie z powyższym, zależy to wyraźnie od przypadków użycia. Ale z reguły, jeśli potrzebujesz w swoim widoku dostępu do otaczającego go kontrolera itp., Użyj Ember.View , ale jeśli chcesz odizolować widok i przekazać tylko informacje, które muszą działać, czyniąc go niezależnym od kontekstu i wiele więcej wielokrotnego użytku, użyj komponentu Ember.Component .
Mam nadzieję, że to pomoże.
Aktualizacja
Wraz z publikacją Road to Ember 2.0 w większości przypadków zachęcamy do używania komponentów zamiast widoków.
{{view.xxxx}}działa w komponencie tak samo jak w widoku.Odpowiedź jest prosta: użyj komponentów
Zgodnie z filmem szkoleniowym nagranym w sierpniu 2013 r., Yehuda Kats i Tom Dale (członkowie zespołu Ember Core Team) powiedzieli publiczności, aby nie korzystali z widoków, chyba że jesteś programistą frameworka. Wprowadzili wiele ulepszeń kierownic i wprowadzili komponenty, więc widoki nie są już potrzebne. Widoki są używane wewnętrznie do zasilania takich elementów, jak {{#if}} i {{outlet}}.
Komponenty również ściśle naśladują standard Web Component, który zostanie wbudowany w przeglądarkę, więc wygoda tworzenia komponentów Ember ma wiele dodatkowych zalet.
Aktualizacja 2014-11-27
Jeszcze ważniejsze jest teraz używanie komponentów zamiast widoków, ponieważ Ember 2.0 będzie używał komponentów routowalnych, gdy zostanie wprowadzona trasa, zamiast kontrolera / widoku. Aby zabezpieczyć swoją aplikację w przyszłości, najlepiej trzymać się z daleka od Widoków.
Źródła:
źródło
Na obecnym
v2.xetapie - jako obecna stabilna wersja - widoki zostały całkowicie wycofane. Mówi się, że widoki są usuwane z interfejsu API Ember 2.0 .Tak więc użycie
{{view}}słowa kluczowego w Ember 2.0 wywoła asercję:Jeśli musisz używać widoków w Ember 2.0, możesz użyć dodatku ember-legacy-views , który będzie kompatybilny z Ember do wersji 2.4 .
Podsumowując - komponenty to teraźniejszość (usuwane widoki) i przyszłość - zastąpią też kontrolery. Zobacz dokument RFC dotyczący składników routowalnych .
źródło