Ember Fastboot loading route

1

I am working on setting up Fastboot for my project. I have it pretty much all working as expected with minor changes to the app. I noticed that I was seeing my page render from Fastboot, and then when the JS booted up I was seeing the loading route activated and then the page rendered again.

I know the way to get around this is using the shoebox, so the model promise resolves immediately. Then the app won’t go into the loading route. So I implemented the shoebox and have my store data transferred to the web app. That works great, and I have confirmed the data is there.

But then I ran into another problem. Im using store.query instead of store.findAll because Im paging the results via the server.

To give an example, lets say I go to the /users page.

  1. Users html is returned from fastboot (with the shoebox having the first 10 users)
  2. App boots up, and goes to the /user route
  3. App makes the store.query api call, since querying disregards the data in the store (even though the first 10 records are indeed in the store)
  4. Loading route is now activated and page clears out
  5. Model is resolved and data is displayed again.

Has anyone ran into this before? Any solutions on how to get around/solve this?

1 Like
3

I ended up going a slightly different way. I was looking at using an addon called ember-data-fastboot which serializes and restores your whole store for you. That works great in some respects, but I had two issues with it.

  1. If your using store.query for server side paging, ember will completely bypass the store and make a call to the server
  2. You lose the routes state

To expend on #2 a bit, you need to know exactly what that routes model method loads, otherwise the fastboot version can render different lists from the SPA version. For example,

  1. You go to /users
  2. In the application route, the authenticated user data is loaded in a /me call
  3. Page is rendered in fastboot with 10 users
  4. Spa app loads up, and page is rendered with 10 users but not necessarily the same ones.

I saw this occur because we load data for an authenticated user under the /me endpoint. When I was serializing the entire store, we now had 11 users added to the shoebox.

If we just try and load the first 10 from the shoebox we might or might not get the same ones. And you can’t just load all the users in the shoebox because then you will have an extra one.

I ended up creating an addon to handle the issues I was having. Found here, the basic process is as follows (which the addon does for you by just including it)

  • Fastboot
    1. Serialize the route data in the fastboot shoebox via a route specific name
  • App
    1. Check and see if there is shoebox specific data for the route.
    2. If there exists data, return it instead of the model. (In this way, we skip any loading routes) Then delete the shoebox data.
    3. If data does not exist, ignore and continue on with the normal route loading.