Presentational vs. Container Components

Here, you’ll learn the differences between presentational and container components.

Presentational components

Presentational components are dumb in the good sense when talking about flexibility and reusability. They assume very little about the context they are used in. Therefore, we can easily use them in different contexts and even in different applications. They define “private” properties, they are configured via passed-in arguments, and they can only change their surroundings via actions in Ember. A widget to rate items by clicking on stars or a fancy drop-down menu are good examples for presentational components.

Container components

Container components are smart. They assume more about the context they are invoked in and can act as autonomous agents, changing the state of the application directly. For example, this includes firing an ajax request to create a new band on the backend. On one hand, this reduces their reusability, but on the other hand, they fit better in our application since they can be highly context specific. Using container components we write less and more readable code, with fewer levels of abstraction. A good example of when to reach for container components is a user form. We could pass in all the validators and save the user via an action that the user form calls, but it’s way easier to just pass in the user object and have the form know about the user’s properties and validations and save the user itself.

On the utility of explicit dependency definitions

By not allowing function calls to render their output in templates and explicitly defining what the property depends on, we get a serious advantage.

To see this, let’s assume Ember did allow function calls in templates, and we had {{#each stars() as |star|}} in the template. This part of the template would need to be rerendered whenever calling stars() because it would produce a different result than what is currently rendered. How do we know whether it would be different? We can’t know that, so we would have to resort to always calling stars() and rendering the result in the DOM. If stars() is slow, we incur a performance hit, perhaps unnecessarily if the result is unchanged.

Contrast that with using properties, or helpers, and relying on Ember’s tracking mechanism to detect changes and trigger re-renders. There is no guessing involved, and we get performant updates without having to think about what changes when and which pieces need re-rendering.

Get hands-on with 1200+ tech skills courses.