Un Ember.View está actualmente limitado a las etiquetas que W3C ha creado para usted. ¿Pero si desea definir sus propias etiquetas HTML específicas de la aplicación y luego implementar su comportamiento usando JavaScript? No puedes hacer esto realmente con una Ember.View .
Eso es exactamente lo que los componentes te permiten hacer. De hecho, es una buena idea que el W3C esté trabajando actualmente en la especificación de Elementos personalizados .
La implementación de componentes de Ember intenta estar lo más cerca posible de la especificación de Componentes Web. Una vez que los elementos personalizados estén ampliamente disponibles en los navegadores, debería poder migrar fácilmente sus componentes Ember al estándar W3C y hacer que otros marcos también puedan utilizarlos y que hayan adoptado el nuevo estándar.
Esto es tan importante para nosotros que estamos trabajando estrechamente con los organismos de normalización para garantizar que nuestra implementación de componentes coincida con la hoja de ruta de la plataforma web.
También es importante tener en cuenta que un Ember.Component es en realidad un Ember.View (una subclase) pero que está completamente aislado . El acceso a la propiedad en sus plantillas va al objeto de vista y las acciones están dirigidas también al objeto de vista . No hay acceso al entorno context
o al exterior, controller
se pasa toda la información contextual , que no es el caso con un Ember.View que de hecho tiene acceso a su controlador circundante, por ejemplo, dentro de una vista, podría hacer algo como lo this.get('controller')
que le daría el controlador actualmente asociado con la vista.
Entonces, ¿cuál es la principal diferencia entre una vista y un componente?
Entonces, la principal diferencia además de que los componentes le permiten crear sus propias etiquetas y, en algún momento en el futuro, cuando los Elementos personalizados estén disponibles, también migrar / usar esos componentes en otros marcos que admitirán elementos personalizados, es que en algún momento un componente de ascuas hará que una vista sea algo obsoleta dependiendo del caso de implementación específico.
¿Y cuál sería un ejemplo común en el que preferiría usar una vista sobre un componente y viceversa?
Seguir lo anterior depende claramente de sus casos de uso. Pero como regla general, si necesita en su vista acceso a su controlador circundante, etc., use Ember.View , pero si desea aislar la vista y pasar solo la información que necesita para funcionar, haciendo que sea independiente del contexto. y mucho más reutilizable, use un componente Ember .
Espero eso ayude.
Actualizar
Con la publicación de Road to Ember 2.0 , ahora se recomienda utilizar Componentes en lugar de Vistas en la mayoría de los casos.