ember-cli-fastboot
ember-cli-fastboot copied to clipboard
ember-fastboot
Better shoebox API
This adds a new higher-level API for the shoebox.
model() {
let fastboot = this.get('fastboot');
return RSVP.hash({
// In this example, we generate a random number once on the server,
// and then the client app will receive the same number.
random: fastboot.withShoebox('my-random-number', () => Math.random())
});
}
withShoebox acts as a memoization service. On the server, the given callback will run and generate a value, which will be saved in the shoebox and then returned. On the client, the callback will not run if the value is already present in the shoebox.
withShoebox returns a promise, because the callback is allowed to return a promise.
So this immediately solves some problems I'm running into. What else (besides tests) needs to be done to get this in?
It seems like the problem withShoebox is trying to solve is preventing the callback from running twice on initial pageload (once on the server, once when the client loads). However the API seems to prevent the callback from ever running on the client if the shoebox holds data matching the requested key. This seems undesirable.
I see a common use case where you only want the client to access the shoebox data one time (on initial payload) and then use the callback every subsequent time the data is requested.
Maybe it would make sense to add an argument flag or a separate API that would implement this idea of "single use" shoebox data?
@steveszc it's my understanding that shoebox.retrieve drops the value from the shoebox after you have retrieved it, which should mean what you're suggesting isn't an issue.
@BenKingBBC That hasn't been my experience using shoebox.retrieve in my app, and I don't see anything happening in the method's source code that suggests that it removes values from the shoebox after they're retrieved.
It does look like it caches the value after it is retrieved from the DOM, but subsequent calls to shoebox.retrieve for a given key would just get the cached value instead of going back to the DOM shoebox.
I'm happy to open a separate issue if there is consensus that "single-use" use case for shoebox values should be handled by shoebox.retrieve instead of a higher-level API.
@ef4 We discussed as a team, and like and approve the API, would you have bandwidth to write tests so that we can land this?
this would be really awesome!
is there anything else blocking this except tests? or latest rc2 release also affects it?
This is a good one to work on and get it in. I ll pick this one up if @ef4 is not working actively on it.
