New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow preloading of data looked up during fastboot rendering. #23

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants
@rwjblue
Contributor

rwjblue commented Apr 23, 2015

Using the provided store will seed the store in the booted application with the data that was fetched during the Fastboot rendering process.


In your app you need to use ember-cli-fastboot/store as your stores base class. Often this just means importing and reexporting in your app/store.js file:

// app/store.js
import Store from 'ember-cli-fastboot/store';

export default Store;
Show outdated Hide outdated app/initializers/fastboot.js
var element, data;
if (store.serializeCache) {
console.log('serializing');

This comment has been minimized.

@stefanpenner

stefanpenner Apr 23, 2015

Contributor

^

This comment has been minimized.

@rwjblue

rwjblue Apr 23, 2015

Contributor

Whoops, good catch. Fixed.

@rwjblue

rwjblue Apr 23, 2015

Contributor

Whoops, good catch. Fixed.

Show outdated Hide outdated addon/store.js
serializeCache: function() {
let results = {};
for (let typeId in this.typeMaps) {

This comment has been minimized.

@stefanpenner

stefanpenner Apr 23, 2015

Contributor

Ember.keys

@stefanpenner

stefanpenner Apr 23, 2015

Contributor

Ember.keys

This comment has been minimized.

@rwjblue

rwjblue Apr 23, 2015

Contributor

👍

@rwjblue

rwjblue Apr 23, 2015

Contributor

👍

Show outdated Hide outdated addon/store.js
},
serializeCache: function() {
let results = {};

This comment has been minimized.

@stefanpenner

stefanpenner Apr 23, 2015

Contributor

maybe a null prototype Object?

@stefanpenner

stefanpenner Apr 23, 2015

Contributor

maybe a null prototype Object?

This comment has been minimized.

@rwjblue

rwjblue Apr 23, 2015

Contributor

👍 - Updated

@rwjblue

rwjblue Apr 23, 2015

Contributor

👍 - Updated

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Apr 23, 2015

Contributor

Updated per Stef's review.

Contributor

rwjblue commented Apr 23, 2015

Updated per Stef's review.

@tchak

This comment has been minimized.

Show comment
Hide comment
@tchak

tchak Apr 23, 2015

What happens if an app use multiple stores?
I feel like I see a lot of addons use store:main and it makes me sad. I am not sure what the solution is. Some kind of "discoverability" api on container?

tchak commented Apr 23, 2015

What happens if an app use multiple stores?
I feel like I see a lot of addons use store:main and it makes me sad. I am not sure what the solution is. Some kind of "discoverability" api on container?

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Apr 23, 2015

Contributor

Ember data itself assumes a single store and uses store:main, which is why I used it here. I'd be happy to implement multi store caching if multiple stores are indeed a "supported" and required thing here, but we will have to figure out a way to discover the store location (as you mentioned).

This pull request addresses the significant majority of cases where only a single store is present.

Contributor

rwjblue commented Apr 23, 2015

Ember data itself assumes a single store and uses store:main, which is why I used it here. I'd be happy to implement multi store caching if multiple stores are indeed a "supported" and required thing here, but we will have to figure out a way to discover the store location (as you mentioned).

This pull request addresses the significant majority of cases where only a single store is present.

@tchak

This comment has been minimized.

Show comment
Hide comment
@tchak

tchak Apr 24, 2015

Ember data do support multiple stores and some people (my self included) use them in production apps. I am happy with this PR as first step. Maybe we can just use named metas. At least on loading we could avoid hardcoded store name. In the part that serialize store hardcoding store:main seems fine for now.

tchak commented Apr 24, 2015

Ember data do support multiple stores and some people (my self included) use them in production apps. I am happy with this PR as first step. Maybe we can just use named metas. At least on loading we could avoid hardcoded store name. In the part that serialize store hardcoding store:main seems fine for now.

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Apr 24, 2015

Contributor

Ember data do support multiple stores and some people (my self included) use them in production apps. I am happy with this PR as first step. Maybe we can just use named metas. At least on loading we could avoid hardcoded store name. In the part that serialize store hardcoding store:main seems fine for now.

how about we just key it 'store:main' and allow multiple store keys, as long as they are resolvable the above code could look them up and insert the payload.

Contributor

stefanpenner commented Apr 24, 2015

Ember data do support multiple stores and some people (my self included) use them in production apps. I am happy with this PR as first step. Maybe we can just use named metas. At least on loading we could avoid hardcoded store name. In the part that serialize store hardcoding store:main seems fine for now.

how about we just key it 'store:main' and allow multiple store keys, as long as they are resolvable the above code could look them up and insert the payload.

@tchak

This comment has been minimized.

Show comment
Hide comment
@tchak

tchak Apr 24, 2015

@stefanpenner this is what I was trying to say :) Sorry it was not very clear. 👍

tchak commented Apr 24, 2015

@stefanpenner this is what I was trying to say :) Sorry it was not very clear. 👍

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Apr 24, 2015

Contributor

Yep, I understood. Working on the changes now..

Contributor

rwjblue commented Apr 24, 2015

Yep, I understood. Working on the changes now..

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Apr 24, 2015

Contributor

Updated, now no longer tied to any hard coded store names (or limited to usage of a single store).

Contributor

rwjblue commented Apr 24, 2015

Updated, now no longer tied to any hard coded store names (or limited to usage of a single store).

@stefanpenner

This comment has been minimized.

Show comment
Hide comment
@stefanpenner

stefanpenner Apr 24, 2015

Contributor

Updated, now no longer tied to any hard coded store names (or limited to usage of a single store).
Merge pull request

nice!

Contributor

stefanpenner commented Apr 24, 2015

Updated, now no longer tied to any hard coded store names (or limited to usage of a single store).
Merge pull request

nice!

return;
}
const rawDump = Ember.$('meta[name="preload-data"]').attr('content');

This comment has been minimized.

@igorT

igorT May 11, 2015

Shouldn't this be just $?

@igorT

igorT May 11, 2015

Shouldn't this be just $?

This comment has been minimized.

@rwjblue

rwjblue May 11, 2015

Contributor

Yes, good catch.

@rwjblue

rwjblue May 11, 2015

Contributor

Yes, good catch.

export default DS.Store.extend({
init() {
this._super(...arguments);
knownStores.push(this._debugContainerKey);

This comment has been minimized.

@igorT

igorT May 11, 2015

If this is run on the server, wouldn't you expect to init a particular store many times even though you import it once? Probably need to make sure the same key is not pushed multiple times

@igorT

igorT May 11, 2015

If this is run on the server, wouldn't you expect to init a particular store many times even though you import it once? Probably need to make sure the same key is not pushed multiple times

This comment has been minimized.

@rwjblue

rwjblue May 11, 2015

Contributor

A given store:<name> should only be looked up once (it is a singleton in the container). Each request gets a new container instance. So each store (by name) should only be instantiated once.

@rwjblue

rwjblue May 11, 2015

Contributor

A given store:<name> should only be looked up once (it is a singleton in the container). Each request gets a new container instance. So each store (by name) should only be instantiated once.

This comment has been minimized.

@igorT

igorT May 11, 2015

But you are closing over an array that is static? Doesn't the knownStores array leak between requests?

@igorT

igorT May 11, 2015

But you are closing over an array that is static? Doesn't the knownStores array leak between requests?

This comment has been minimized.

@rwjblue

rwjblue May 11, 2015

Contributor

And this is why I love working with smart people. Good catch, will fix.

@rwjblue

rwjblue May 11, 2015

Contributor

And this is why I love working with smart people. Good catch, will fix.

Allow preloading of data looked up during fastboot rendering.
Using the provided store will seed the store in the booted application
with the data that was fetched during the Fastboot rendering process.

---

In your app you need to use `ember-cli-fastboot/store` as your stores
base class. Often this just means importing and reexporting in your
`app/store.js` file:

```javascript
// app/store.js
import Store from 'ember-cli-fastboot/store';

export default Store;
```

@rwjblue rwjblue closed this Apr 28, 2016

@rwjblue rwjblue deleted the rwjblue:preloaded-data branch Apr 28, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment