Things to do in war room:
simple-dom to v1.0? 🎉fastbootfastboot v1.0.0 🎉fastboot version to v1.0.0 in fastboot-express-middlewarefastboot-express-middleware v1.0.0 🎉fastboot version to v1.0.0 in fastboot-app-serverfastboot-express-middleware to v1.0.0 in fastboot-app-serverfastboot-app-server v1.0.0 🎉
FastBoot 1.0 is close to being shipped. The rc builds have been relatively stable with no major issues.
We released v1.0.0-rc.4 today which contains a fix for fingerprinted assets to be loaded in Node. Also nested addons and in-repo that are FastBoot complaint now work correctly with ember-cli-fastboot (Thanks to @rwjblue).
fastboot trees: ember-fastboot/ember-cli-fastboot#422treeForFastBoot is called for nested addons: ember-fastboot/ember-cli-fastboot#423
The below guide only applies to addons. If your app is using process.env.EMBER_CLI_FASTBOOT, please create an in-repo addon and follow this guide.
When you make the changes to make sure your addons are backward compatible for upcoming FastBoot build changes, make sure to test all the usecases as follows:
ember-cli-fastboot not installed. Make sure the fastboot initializers or vendor files are not running in browser.
Fastboot 1.0 release is blocked on bad build performance and serving fastboot assets inconsistently. We want to fix this by changing the way fastboot builds its assets. Instead of creating seperate assets we want to create additive assets. This issue in ember-cli perfectly defines what we want to do.
This gist describes the work on how to unblock Fastboot 1.0 and how to run those PRs so that you can play with it.
| import Ember from 'ember'; | |
| export default Ember.Controller.extend({ | |
| appName: 'Ember Twiddle' | |
| }); |
When an Ember app boots up, it primarily waits for the DOM to be ready before it can boot your application. Though this is a safe check needed in order to have your custom event handlers attach correctly to the DOM, it may not be always necessary. In Ember all event handling is attached to the rootElement by default.
Waiting for the DOM ready may not be always necessary and would be a disadvantage in certain scenarios. For example, the app's index.html could also contain the API data needed by that route in a pre-fetched fashion. The index.html could be served in chunks (ie as the data is available we would be sending it to the client). When the client app boots in the browser, it can use this pre-fetched data to serve the route. When serving the base page in chunks (using Transfer-Encoding protocol), the browser fires the DOM ready only after the last chunk is sent down. This could cause the DOM ready to be delayed and the Ember app cannot do anything until then.
#Ember boot up hooks This document describes the high level use cases and various user hooks that are needed during the ember boot up phase.
We want to measure the time an ember application takes to boot up before it can serve any requests. There are various stages in the boot up phase (creating the application instance, running the initializers etc). We want to capture the time it took during the boot up to recongize any potential performance issues. For this, we need public hooks to add timing measure ments. Following are the time measurement use cases that we would like to capture: