Views vs Components in Ember.js

21,661

Solution 1

Ember.View

An Ember.View is currently limited to the tags that are created for you by the W3C. But if you wanted to define your own application-specific HTML tags and then implement their behavior using JavaScript? You can't do this actually with a Ember.View.

Ember.Component

That's exactly what components let you do. In fact, it's such a good idea that the W3C is currently working on the Custom Elements spec.

Ember's implementation of components tries to be as closely to the Web Components specification as possible. Once Custom Elements are widely available in browsers, you should be able to easily migrate your Ember components to the W3C standard and have them be usable by other frameworks as well that have adopted the new standard.

This is so important to us that we are working closely with the standards bodies to ensure our implementation of components matches the roadmap of the web platform.

Also important to note is that a Ember.Component is actually a Ember.View (a subclass) but that is completely isolated. Property access in its templates go to the view object and actions are targeted also at the view object. There is no access to the surrounding context or outer controller all contextual information is passed in, which is not the case with a Ember.View which indeed has access to it's surrounding controller, for example inside a view you could do something like this.get('controller') which would give you the controller currently associated with the view.

So what is the main difference between a view and a component?

So, the main difference besides that components let you create your own tags and in some point in the future when Custom Elements are available also migrate/use those components in other frameworks that will support custom elements, is indeed that at some point an ember component will make a view somewhat obsolete depending on the specific implementation case.

And what would be a common example where I would prefer to use a view over a component and vice versa?

Following the above this depends clearly on your use cases. But as a rule of thumb, if you need in your view access to it's surrounding controller etc. use a Ember.View, but if you want to isolated the view and pass in only the information that it needs to work making it context-agnostic and much more reusable, use a Ember.Component.

Hope it helps.

Update

With the publication of Road to Ember 2.0 you are now encouraged to use Components instead of Views in most of the cases.

Solution 2

The answer is simple: use components

According to a training video that was recorded on August 2013, Yehuda Kats and Tom Dale (Ember Core Team Members) told the audience to not use views unless you're a framework developer. They've made lots of enhancements to Handlebars and introduced Components, so views are no longer necessary. Views are used internally to power things like {{#if}} and {{outlet}}.

Components also closely mimic the Web Component standard that will be build into the browser, so there are lots of side benefits to becoming comfortable building Ember Components.

Update 2014-11-27

It's even more important now to use components instead of views, as Ember 2.0 will be using Routable Components when a route is entered, instead of a controller/view. In order to future proof your app, it's best to stay away from Views.

Sources:

Solution 3

As it stands now - v2.x being current stable release - views have been completely deprecated. It is said that views are being removed from Ember 2.0 API.

So, using {{view}} keyword in Ember 2.0 will trigger an assertion:

Assertion Failed: Using {{view}} or any path based on it has been removed in Ember 2.0

If you have to use views in Ember 2.0 you can use ember-legacy-views addon, which will be compatible with Ember until version 2.4.

So, to sum up - components are the present (views being removed) and the future - they will also replace controllers. See Routable Components RFC.

Share:
21,661
Bradley Trager
Author by

Bradley Trager

Updated on November 21, 2020

Comments

  • Bradley Trager
    Bradley Trager over 3 years

    I am learning ember.js, and I am trying to understand the difference between a view and a component. I see both as a way of making reusable components.

    From Ember's website on views:

    Views in Ember.js are typically only created for the following reasons:
    -When you need sophisticated handling of user events
    -When you want to create a re-usable component

    From Ember's website on components:

    A component is a custom HTML tag whose behavior you implement using JavaScript and whose appearance you describe using Handlebars templates. They allow you to create reusable controls that can simplify your application's templates.

    So what is the main difference between a view and a component? And what would be a common example where I would prefer to use a view over a component and vice versa?

  • sly7_7
    sly7_7 over 10 years
    My only concern about components is when they become complex. I don't know yet how to separate the logic part from the rendering part. I regular views, you have this separation, and could put the logic into the controller, but with component, I tend to say you'll end up having a very complex, and perhaps huge mess in it. Do you know if it's possible to define a dedicated controller-like for components ? Or perhaps components are just not intended to manage complex graphical elements.
  • intuitivepixel
    intuitivepixel over 10 years
    @sly7_7, yes I get your point. But I would think of a component as a black box, behaving only based on the data it gets passed in. And yes depending on what it does this could become a mess very quickly. A dedicated controller would make absolute sense, and a way it could work would be if components could become logic injected into it, but as far I know components are not part of ember's container by design I guess, but it may change in the future to solve exactly something like this. Good point anyway!
  • Michael Johnston
    Michael Johnston over 10 years
    can any bindings go out of a component? IE, with the block form of a component can content elements in the block bind to properties of the component, or must I use a view in this case?
  • Michael Johnston
    Michael Johnston over 10 years
    ah, yes they can. {{view.xxxx}} works in a component the same as in a view.
  • jmcd
    jmcd almost 10 years
    "If you feel you need to use a view, use a Component instead." is terrible advice, and betrays a lack of understanding of the isolation that components involve.
  • Johnny Oshika
    Johnny Oshika almost 10 years
    @jmcd, although that comment came from the framework developers themselves, I took it out.
  • jmcd
    jmcd almost 10 years
    I found the source: Gaslight video training, video 10.3 Components Q&A @ 26m mark. Tom says: ''Since those examples were written, ... we've added Components [which] didn't exist when those examples were written. In general I would say Views are not something we would expect most developers to be writing, they're more of an internal book-keeping object at this point'
  • Johnny Oshika
    Johnny Oshika almost 10 years
    @jmcd, In that video @ 26:15, Tom says "basically don't use Views". Also, if you jump to 30m in the same video, Yehuda Katz says: "View is basically an internal implementation detail...you could use a View, but then you're a framework developer. You should instead use one of the things that we've built for you that uses View, and the one that is closest to View but has better semantics is Component. Anything that you could have used a View for before, Component is fine."
  • Akshay Rawat
    Akshay Rawat about 9 years
  • Chaitanya Chandurkar
    Chaitanya Chandurkar almost 9 years
    If Ember.Component is a subclass of Ember.View can we use export default Ember.View.extend() in component's js? I was looking into Ember-Leaflet and found bower addon which has wrap up leaflet in Ember.View. So can I just use it in place of component?
  • hbobenicio
    hbobenicio over 7 years
    That is a really nice explanation. Thank you, you made it much more clear!