Documentation for addon authors

[tomdale]

We need a guide for addon authors that helps explain what they need to do to make their addon compatible with FastBoot.

• Detecting FastBoot mode inside the Ember app (typeof FastBoot?)
• Detecting FastBoot in addon (process.env.EMBER_CLI_FASTBOOT)
• Dynamically including dependencies (e.g. how ember-network swaps in different fetch polyfills)
• Environment-specific initializers (app/initializers/browser/foo.js and app/initializers/fastboot/foo.js)

[kylenathan]

Couple of quick notes from forking and fastboot-ifying a really simple jquery plugin wrapper addon:

• Needed to detect Fastboot at build time so addon could conditionally import the plugin libs from bower.
• Had to remove some default values that used jquery selectors for html that was assumed in the template appendArrows: Ember.$('.arrows')

[hhff]

I'm doing some research into Fastboot-upgrading my addon Ember Infinity.

Seeing as Fastboot currently just serves static HTML, and didInsertElement doesn't fire, is a Fastboot-able addon simply one that doesn't error, and serves a HTML representation of itself?

Ie: For Ember Infinity (infinite scroll), would it be considered "Fastboot-able" if the initial page of results is rendered, and the "infinity-loader" component is rendered below the list?

[tomdale]

@hhff I think that's exactly right. Addons should not prevent authors from using FastBoot, and should provide a reasonable experience.

I think identifying the ideal behavior for addons/apps in FastBoot is going to be highly contextual. For example, imagine an app has a component that renders a D3 graph, which happens in didInsertElement().

Today, that graph would just not be rendered in FastBoot. The app would render except there would be a spot missing where the graph should be. Obviously, it would be ideal if we could render that on the server. Once we ship FastBoot 1.0, my hope is we'll start identifying cases like this and start chipping away at them.

That could mean letting users opt-in to using a synthetic DOM implementation in Node-land. I suspect this may be inevitable although I really hope we can avoid it. It could also mean having good documentation. In the D3 case, for example, there is almost certainly a way to write a graph such that the initial render is done in Handlebars and only updates/animations are done in D3. It should be totally possible to use D3's path generation etc. in Node if it's packaged correctly.

For now, I'm hoping we can focus on just "don't prevent apps from booting". 😛 It's a low bar but hopefully that means it should be an easy target for people to hit. Once that's done, we can get to the fun part and start thinking about what a good user experience is with server-side rendering.

[hhff]

Got it! Thanks @tomdale !

[davidpett]

This has been written and there is an open PR in the fastboot-website repo: ember-fastboot/fastboot-website#39