I read the guide’s section about components and I’m a bit confused. I’m not sure what would be the advantages or disadvantages to use them instead of views.
I’ve been using views and it seems they can do all of the same things, except (maybe) having content/taking a block. The only difference I see is how view have access to their context and events bubble to controller/routers. This coupling can be good and bad.
Is this the only difference?
Curious to hear this as well. One thing that puzzles me a bit is what is the right way to put view controller specific logic for reusable components. Right now, we have some of those in views and some of those in controllers.
It seems now the recommended way is to use components. But except for the differences you listed and the name, I do not see much difference.
There are two high level advantages of components that I am aware of.
1.) They are forward looking in that ember is trying to remain in line with the concept of “web components” and custom HTML that will eventually be a native browser feature.
2.) Explicit isolation of the scope of a component you have to be deliberate about what values are passed in and out of the component. This makes them easier to reason about and isolate logic. This also means components are highly portable and can be reused in many different contexts with different data.
There may be other reasons. Technically speaking components are a sub class of View.
Steve Kane did a presentation that really laid out the value of components and is worth watching.
Building Reusable UIs Chicago Ember.js
@eccegordo Thanks for the info and sharing the video. I’ll have a look.
I forgot about 1). That makes sense. About 2), I don’t see that necessarily as an advantage, but simply a difference.
As a side note. I see some similarity with my old days developing on Winforms and WPF. Views are more like UserControls and Components are more like Controls. We are all going in circles here.