add Fastboot compatibility

[noopkat]

👋 hello!

An avid user of ember-islands here - thanks for your hard work on this add-on!

This is a rather plain solution for ensuring compatibility with Fastboot going forward.
There's not really a backwards compatible alternative that I can think of, for apps that have no awareness of fastboot due to it not being installed.

Anyway let me know what you think 😄

[mitchlloyd]

Thanks for opening this issue. I was wondering if anyone would find a use for this library in conjunction with Fastboot. Whenever I've used Ember Islands, the page is already rendered server-side with an existing web server so using Fastboot never really made sense for me.

Can you tell me more about your use case? It seems that you're wanting to just disable rendering in when using Fastboot. I'd like to find out if it would be better to actually try to render something instead.

[noopkat]

Sure! I definitely should have described the use case.

I'm using Ember Islands within a well established Rails app. The main use case is retaining the header and footer in rails, and one large container to hold an Ember Island. There are also other use cases where only one smaller feature in a div on the page is an Ember Island. So it seems that we might have similar use cases 😄

For a specific example, I'd love to have a large set of search results render via Fastboot for an initial HTML page load, and then while the user is browsing, the Ember app is downloading and hydrating the static search results content with an Island version once booted. It will alleviate the large delay between "oh look, the header and footer are here" and "here's the content I actually care about as a user".

I hope this makes sense, I can explain further if needed.

I have been able to get Fastboot + Islands playing quite nicely in the Rails app after a day of fiddling around. This code change was what got me moving forward.

Can you think of a way where Islands would become redundant within this use case? I'm all for removing dependencies and needless complexity 😁

[mitchlloyd]

You're way ahead of me on this Fastboot stuff so hopefully I can catch up. The part I don't understand is how you're using your Rails app and your Ember app with Fastboot together to serve a page.

I'm imagining something like:

<header>I'm the header from Rails</header>
<div data-component="some-ember-component-with-search-results"></div>
</footer>I'm the footer from Rails</footer>

It seems like if you're able to get the HTML from your server, and then the HTML from your Fastboot Ember app and somehow combine them (I don't know how), then you would want the island component to render server-side as well.

Anyway, assuming I can understand the overall approach here, I have to decide whether to just no-op Ember Islands when Fastboot is running or actually try to render something.

As far as no-oping goes, I think I've committed a Fastboot sin here by using a function that looks at the DOM in the init hook. Perhaps moving that call to didInsertElement (which Fastboot never calls) would fix the issue and be more idiomatic. The original idea here was that you would always load Ember after the static DOM was rendered so this was ok.

On the other hand, I'm a little afraid of no-oping the rendering and then later finding out that it would be better to render something. For now Ember Islands just crashes in Fastboot (that sucks) but if I choose to no-op it and later want to render, that will be a backwards incompatible change.

Can you tell me more about the approaching rendering HTML with your Rails server, and then with Fastboot?

[noopkat]

So here's the current setup I have, let me know if this makes sense as pictures are much easier for me to communicate with!

Currently there is a rails helper for inserting an island, and one for inserting a fastboot rendered component/route. Both are called in the same place, but there'd be a way to DRY that up somewhat.

I am curious about what you mean by "then you would want the island component to render server-side as well"?

I totally get what you mean by not wanting to break compatibility with a change introduction after a short period of time.

Thanks!

[mitchlloyd]

Thanks for that great diagram! That first step with the Rails helper is what I was curious about. Now it's starting to make sense. So the way you have things set up now, you want to make sure that your {{ember-islands}} component does nothing in this Fastboot phase, but does work later when rendering in the browser.

Since you're on the vanguard here, I'm wondering if you could continue to use a workaround while you work on this approach. That would also buy me some time to keep pondering and see if anyone else can chime in with Fastboot use cases.

Seems like your fix is working. Another approach that would allow you to avoid using a fork might be creating a component to avoid rendering the ember-islands component when using Fastboot.

usage:

{{#browser-only}}
  {{ember-islands}}
{{/browser-only}}

app/components/browser-only.js

import Ember from 'ember';
const { Component, inject } = Ember;

export default Component.extend({
  tagName: '',
  fastboot: inject.service()
});

app/templates/components/browser-only.hbs

{{#if fastboot.isFastboot}}
  {{yield}}
{{/if}}

Do you think that would work as a temporary workaround?

[noopkat]

I can definitely keep moving forward with that as a workaround 😄
Your suggested code examples were really helpful also, thank you. I definitely think you're right to "wait and see" for now; thinking about it before taking further steps.

As for our side, currently the latest beta of fastboot has a pretty productivity-killing bug in it while running in a development environment, so it's not exactly something we'll be implementing immediately into our stack. Optimistically it's something we'll still be aiming for though - this is mostly a first pass to see if it's worth spending the time on solidifying.

I really appreciate this discussion and your prompt responses. Thanks for humouring me so early on in the fastboot venture 👍

[mitchlloyd]

Sounds good. I opened #30, so that there is an open issue people can find for Fastboot compatibility.