Breeze js - how to create an entity from a JSON string and import it into the breeze cache

Question

I am working on a mobile single page site that uses breeze js, angular js, web API, entity framework, etc.

To optimize the site, I included the breeze metadata in a bundled JavaScript that contains all the other JavaScript the site needs. Ideally, all I would like the browser to request is index.html, which should contain everything the app needs to run including bundled and minified inline styles and JavaScript.

However, just as the breeze metadata is very important for the site to function and is therefore embedded in the bundled JavaScript, there is also a required complex entity (with some deep navigation properties to some other entities) that must also be present for the site to be fully functional. I would like to embed this entity and all the entities it references in the bundled JavaScript as well. How can I do this?

I can always create a JSON string that represents this entity and all the entities it references. Then embed that JSON string in the bundled JavaScript along with the rest. However, how can I easily import this complex entity into the breeze entity system using the entity JSON string I have embedded in JavaScript? Or is there a better solution to preload the breeze entity system with a complex entity without having to make a request for that entity from the server?

I would also like to avoid writing server code to spit out JavaScript that creates the entity on the client.

Answer 1

Simplest approach would be to use the "initializer" argument to the EntityManager.createEntity call.

See http://www.breezejs.com/documentation/creating-entities and http://www.breezejs.com/sites/all/apidocs/classes/EntityManager.html#method_createEntity

This call looks this.

myEntityManager.createEntity("Employee", { lastName: Smith", firstName: "John" });

So in your case you could try:

var initialValues = JSON.parse(json);
myEntityManager.createEntity("Employee", initialValues);

Depending on your use case you may want to also set the 'entityState' of this newly created entity as well.

Answer 2

Here's a technique I often use to create entity data for automated tests:

Preparation

• prime an EntityManager with the entities (and entity graphs) that you want available at launch.

• export as a string with var exported = manager.exportEntities();. The exported string has the metadata embedded in it so you won't have to bring that down separately. Two-for-one!

• capture the contents of exported to a JavaScript file that you load as script in index.html. My "capture" process is usually just to display in the console and scrape it.

Usage

Now when you need it:

• load that JavaScript metadata+data file.

• create a new EntityManager (remember to target the same dataservice endpoint).

• import the entities you captured in your script: manager.importEntities(launchData);.

And you are good to go.

Read up on the EntityManager exportEntities and importEntities methods.

Example

One place you can see a variation on this technique is in the test directory of the "Zza-Node-Mongo".

I personally do not combine the data with the metadata so I export using the "no metadata" option. I put the metadata in one script and the data-to-load-on-launch (lookups usually) in a separate script and load both in index.html.

Caution

You say

to optimize the site, I included the breeze metadata in a bundled JavaScript that contains all the other JavaScript the site needs. Ideally, all I would like the browser to request is index.html, which should contain everything the app needs to run including bundled and minified inline styles and JavaScript.

Beware of premature optimization

I rather doubt that you will measurably improve the launch time of the app by embedding metadata and launch date in script files. Maybe some of the time if the browser caches these scripts. But that comes with its own risks and isn't a reliable strategy.

The data you want has to come over the wire to the client one way or another. It isn't self-evident that loading a script file - even a minimized script file - is any faster than pulling the metadata and launch data (both gzipped) down from the server via a web api AJAX call.

The techniques I described do speed up testing because I have to recreate metadata and the launch data before each test. I can measure the performance gain from avoiding repeated trips to the server. I gain nothing for the first trip ... which is the equivalent of your application launch.

Be mentally prepared to discover that your hard earned optimization efforts did not improve launch times ... and might even make them worse for some users.