Fasboot Compatibility

[mitchlloyd]

Right now ember-islands will throw an error when rendered with Fastboot. Per https://github.com/mitchlloyd/ember-islands/pull/28, there could be some interesting use cases with Fastboot and ember-islands, but I'm not sure what those are yet and what patterns would be most helpful. For starters, should this library render nothing when not in the browser or should it try to render something?

[cdeszaq]

I would love to see this supported. Let me lay out the use-case we're looking to solve, and what might make sense as an alternative solution to how #28 looked at it, and hopefully that will spark some ideas.

Background

We have a large server-rendered page-based web application. There's more and more demand for more interaction and lower latency and so we're looking to move to Ember. A big-bang changeover isn't an option, so using ember-islands looks like a perfect solution because it will let us build new things using Ember and convert old things to be Ember-driven.

We have strict requirements around SEO and user experience, however, so we also need to have the initial server response contain fully rendered HTML. If we had an all-Ember app, Fastboot is exactly the solution, but it will be a while before we get everything converted.

Use Case

So the problem we're hoping to solve w/ Ember Islands being able to place nicely with Fastboot is this: How can a non-Ember, server-side-rendered application move to Ember iteratively without losing out on the benefits of being server-side-rendered?

Hopefully Ember Islands + Fastboot is the solution to that problem!

Potential Solution

Pipe the existing server-rendered pages through Fastboot (I'm not sure if this makes sense). When an Ember Island is encountered, it would render as if it was being rendered in a browser, and the entire rendered page comes out the other side.

I don't know Fastboot well enough to know if that sort of thing would even be supported / supportable, but that's how my mind initially tackled it. At first glance, supporting that kind of use-case by Fastboot is a prerequisite, but once that's there, then having Ember Islands be OK running inside the Fastboot environment makes this a workable solution for my problem.

[mitchlloyd]

@cdeszaq Thanks for the great write up! I agree that this use case fits with the goal of Ember Islands.

Since #28 the library has changed a little. Ember Islands should no longer attempt to render in Fastboot. At the time of that issue, it would throw an error.

So what if we did want to render something in Fastboot? This seems straightforward to me:

1) Remove jQuery and figure out how to query existing DOM and render over it in Fastboot. This might take some work, but it's going to be possible. Either this can use the ember-fastboot/simple-dom APIs or the excellent (but private) -in-element Glimmer API. 2) Provide some mechanism (configuration, function to call, or some option on {{ember-islands}}) to start the reconciliation process if you want to render before didInsertElement.

However, this is the part that I'm also unsure about:

Pipe the existing server-rendered pages through Fastboot (I'm not sure if this makes sense)

I don't know if there is a way to provide Fastboot with a per-URL html page to render into. I haven't used Fastboot before but it looks like it needs a the index.html page provided in its configuration.

If this is possible and you've got the inclination I'd like to support this case. It would be helpful if you could create a "proof of concept" repository to show whether the "per-page HTML" setup would work.