fastboot ready

[davidpett]

added the guards to allow ember-paper to be fastboot ready

[thejohnnybot]

+1

[eriktrom]

I made a similar PR this morning - #353 - guess i should have read the current PR's first. 👅

Just a note/thought/opinion - when we do go down this road my preference would be NOT to use something like the typeof FastBoot b/c the in this case the variable FastBoot is defined within the vm context on the node server and unless there is consensus among the core team as to what that variable should be, and where it should be defined, it seems more sane to place the util inside the ember(and thus DOM only) code that way people are not confused by where the random FastBoot variable came from.

As an example, I have this TODO in my fastboot code. So far this is the only library I have installed that uses this variable, and it's the only project by that author that uses it as well:

FastBoot: true, // for /runspired/ember-run-raf/blob/master/addon/utils/is-fastboot.js (TODO: Make PR to change)

Just a thought.

(also overriding the Ember.Component init() function by re-opening it and injecting it in place of a normal Ember.Component only when running in node is probably the most robust way to (currently) handle this. The init method inside components is the only hook called by fastboot code. That said, Mixins are also mixed into components in this codebase so that part would need another round of thought to solve. I'm just throwing out some ideas at this stage. Brain teasers for the future if you will.)

so 2 thoughts, anywho....

[davidpett]

@eriktrom correct, at the time of this PR, this was the way to check for FastBoot. Since then, there is a property on the fastboot service isFastBoot which does use the global car check, but at least it is not in this addon

[eriktrom]

thanks @davidpett - i'll have to catch up on the latest from the commit line - thanks for the heads up :)

[dustinfarris]

Can this be closed?

[dustinfarris]

I think this can be closed thanks to #430

/cc @miguelcobain