This assert.asyncThrows custom assertion allows us to write tests against failing async code, usually as a result of a server error (4xx/5xx response).
test('If the index route errors, I see a message', async function(assert) {
server.create('post');
server.get('/posts/:id', { errors: ['The site is down'] }, 500); // force Mirage to error
await assert.asyncThrows(() => {
return visit('/posts/1');
}, 'GET /posts/1 returned a 500');
Latest News: http://site.api.espn.com/apis/site/v2/sports/football/college-football/news
Latest Scores: http://site.api.espn.com/apis/site/v2/sports/football/college-football/scoreboard
UPDATE: You don't need shims anymore! We can just use this now, and eventually it'll even be in Ember core.
app.import() works with node_modules now! As of Ember 2.15. Previously it only worked with bower_components and vendor.
Docs for app.import are here:
https://ember-cli.com/managing-dependencies#standard-non-amd-asset
You can use async/await in your Ember testing suite, today! This blog post explains the situation pretty thoroughly. Also check out this blog post.
It's great in tests, but not quite useful for app code yet.
There are three ways we can get it to work. If you try async/await without any of these changes, you will get the error regeneratorRuntime is not defined.
| Method | Size ※ | app code | test code |
|---|---|---|---|
| includePolyfill: true | 30kb | yes | yes |
| ember-maybe-import-regenerator | 2kb | yes | yes |
| /* the page should not change width as content is loaded */ | |
| body { | |
| overflow-y: scroll; | |
| } | |
| /* block scrolling without losing the scroll bar and shifting the page */ | |
| /* add this class when a modal is open */ | |
| body.block-scroll { | |
| overflow: hidden; | |
| overflow-y: scroll !important; |
| // The home page needs to load a lot of data for a feed of events. | |
| // This would block initial rendering of the application, so what | |
| // we do is make a pathless child route called feed that loads the | |
| // data. | |
| // Since our home route doesn't load data anymore it renders | |
| // immediately. It has an {{outlet}}, and while 'home.feed' is | |
| // fetching data 'home.loading' will be rendered into the | |
| // outlet. Once feed's model hook fulfills the feed template | |
| // is rendered to the outlet. |
When using yarn, it will create a yarn.lock lockfile which holds data on your used dependencies. This file also includes hard-typed versions, so should you update your dependencies, the yarn.lock file is basically outdated and needs to be regenerated. While yarn does this automatically, Greenkeeper pull requests that update dependencies as of right now do not do this regeneration, which means you would have to do it manually.
This gist shows you a way how to automatise this step using a Travis CI script.
yarn.lock file in your repository for Travis CI to automatically install yarn (yarn will be added to their default images soon)
Here's how to (hopefully) improve the initial load performance of your ember-cli project.
gulpfile.js to any ember-cli projectyarn add critical gulp --devbuild script in package.json to ember build -prod; gulp criticalyarn buildNow, gulp will run the critical task once after each build. The critical task checks what CSS your app needs to render the initial route and puts it inline in your dist/index.html.
| // instance-initializers/app-view.js | |
| // With an instance initializer, we can register a component for Ember to use at the top level. | |
| // Not ideal, but it works in the meantime until routable components drop. | |
| import Ember from 'ember'; | |
| const AppView = Ember.Component.extend({ | |
| classNames: ['my-app'], | |
| }); |
