rarwe.tar.gz

Ember

Ember-copy

ember2

embercss

rarwe

Ember-copy-5yvdqv

Ember-copy-5yvdqv-copy

Ember-Acceptest

Ember-Acceptest-copy

Ember-unitest

rarwe-copy

Ember-Acceptest-challenge

Ember-helper-challenge

In this course, you begin with an introduction to Ember.js, a JavaScript framework for building client-side applications.

After that, the course guides you through the steps of building a real application so that you can see how the concepts are applied in practice. You'll learn about the building blocks of Ember one by one, in a way that crushes the allegedly steep learning curve of the framework.

The application will get shinier (and/or more robust) with each chapter. By the end, we will have a decent app, and you'll have a great new skill you can add to your resume.

Developing Robust Ember.js Applications

## 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.

# 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.

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

Presentational vs. Container Components

Course Overview

Getting Started with Ember

Templates and Data Bindings

Routing

Nested Routes

Components

Controllers

Building a Catalog

Talking to a Backend

Advanced Routing

Testing

Query Params

Loading and Error Substates

Helpers

Conclusion

Appendix

Presentational vs. Container Components

Presentational components