Ember resources and troubleshooting

• Ember.JS Guides
  • Tutorial: Super Rentals
• Ember.JS API Documentation
• Ember.JS Discord Server — a forum/chat server where you can meet the Ember community, ask for help, and help others!

This is nowhere near an extensive list, but it is a list of things that came up around the time of writing (latest update, May 2020).

For framework-specific things, there is the ember-inspector add-on, which allows inspection of:

• Routes & Controllers
• Components
• Services
• Promises
• Data (i.e., from a remote API — from ember-data, by default)
• Deprecation Information
• Render Performance

For general JavaScript debugging, check out our guides on JavaScript Debugging as well as interacting with the browser's other debugging tools. In any default Ember project, there will be two main JavaScript files, vendor.js and {app-name}.js. Both of these files are generated with sourcemaps, so when you open the vendor.js or {app-name}.js to search for relevant code, when a debugger is placed, the sourcemap will be loaded and the breakpoint will be placed in the pre-transpiled code for easier correlation to your project code.

For more information on sourcemaps, why they're needed, and what the ember-cli does with them, see the Advanced Use: Asset Compilation guide. Note that sourcemaps are enabled by default.

Not at all. While ember-data solves the most common problems that any app dealing with data will run in to, it is possible to roll your own front-end data client. A common alternative is to any fully-featured front-end data client is The Fetch API.

Using the design patterns provided by the framework, a Route using fetch() would look something like this:

import Route from "@ember/routing/route";

export default class MyRoute extends Route {
  async model() {
    let response = await fetch("some/url/to/json/data");
    let json = await response.json();

    return {
      data: json,
    };
  }
}

See more information on specifying the Route's model here.

This is the most common question Ember folks hear from people who have previous experience with React. While it is technically possible to use JSX, or any other form of DOM creation, there has yet to be anything as robust as Ember's templating system. The intentional minimalism forces certain decisions, and allows for more consistent code, while keeping the template more structural rather than having them filled with bespoke logic.

See also: ReactiveConf 2017: Secrets of the Glimmer VM

mut was not covered in this tutorial and is really baggage from a transitional time when Ember was moving from two-way bound data to the more common and easier-to-reason-about one-way bound data flow. It could be thought of as a build-time transform that wraps its argument with a setter function.

More concretely, using mut allows for template-only settings functions to be declared:

<Checkbox
  @value={{this.someData}}
  @onToggle={{fn (mut this.someData) (not this.someData)}}
/>

Whereas, without mut, a component class would be needed:

import Component from "@glimmer/component";
import { tracked } from "@glimmer/tracking";
import { action } from "@ember/object";

export default class Example extends Component {
  @tracked someData = false;

  @action
  setData(newValue) {
    this.someData = newValue;
  }
}

Which would then be called in the template like so:

<Checkbox @data="{{this.someData}}" @onChange="{{this.setData}}" />

Due to the conciseness of using mut, it may be desirable to reach for it. However, mut has unnatural semantics and has caused much confusion over the term of its existence.

There have been a couple of new ideas put together into the form of addons that use the public APIs, ember-set-helper and ember-box. Both of these try to solve the problems of mut by introducing more obvious / "less magic" concepts, avoiding build-time transforms and implicit Glimmer VM behavior.

With ember-set-helper:

<Checkbox @value={{this.someData}} @onToggle={{set this "someData" (not
this.someData)}} />

With ember-box:

{{#let (box this.someData) as |someData|}}
  <Checkbox
    @value={{unwrap someData}}
    @onToggle={{update someData (not this.someData)}}
  />
{{/let}}

Note that none of these solutions are particularly common among members of the community, and as a whole, people are still trying to figure out an ergonomic and simple API for setting data in a template-only context, without backing JS.

Controllers are Singletons, which may help manage the rendering context of the active route. On the surface, they function much the same as the backing JavaScript of a Component. Controllers are (as of January 2020), the only way to manage URL Query Params.

Ideally, controllers should be fairly light in their responsibilities, delegating to Components and Services where possible.

A Route represents part of the URL when a user navigates from place to place in the app. A Route has only a couple responsibilities:

• Load the minimally required data to render the route (or view-sub-tree).
• Gate access to the route and redirect if needed.
• Handle loading and error states from the minimally required data.

A Route only has 3 lifecycle hooks, all of which are optional:

• beforeModel — gate access to the route.
• model — where data is loaded.
• afterModel — verify access.

Last, a Route has the ability to handle common events resulting from configuring the model:

• loading — what to do when the model hook is loading.
• error — what to do when an error is thrown from model.

Both loading and error can render default templates as well as customized templates defined elsewhere in the application, unifying loading/error states.

More information on everything a Route can do is found in the API documentation.

• Previous
• Overview: Client-side JavaScript frameworks
• Next