Use

The constructor-store behavior is used to:

• provide a store of instances and lists in use by the client
• prevent multiple instances from being generated for the same id or multiple lists for the same listSet.

The store provides access to an instance by its id or a list by its listSet. This is used by other behaviors to lookup instances that should have changes applied. Two examples, when there is a new instance that should be added to a list (real-time) or when newer data is available for a cached instance that is used in the page (fall-through-cache).

Below you can see how constructor-store's behavior be used to prevent multiple instances from being generated. This example allows you to create multiple instances of a todoEditor that loads and edits a todo instance:

You can see in this example that you can edit one todo and the other todos update. This is because each todoEditor is acting on same instance in memory. When it updates the todo's name here:

var updateData = function(newName) {
  todo.name = newName; // update name on todo instance
  ...
};

The other widgets update because they are bound to the same instance:

todo.on("name", updateElement); // when todo name changes update input element
todosConnection.addInstanceReference(todo); // previous line is a new usage of todo, so increase reference count

Each todoEditor receives the same instance because it was added to the connnection.instanceStore by addInstanceReference. During all instance retrievals, a connection using the constructor/store behavior checks the instanceStore for an instance with a matching id and return that if it exists. This example always requests id: 5, so all the todoEditors use the same instance held in the instanceStore.

This widget cleans itself up when it is removed by removing the listener on the todo instance and reducing the instance reference count:

todo.off("name", updateElement); // stop listening to todo name change
todosConnection.deleteInstanceReference(todo); // previous line removed a usage of todo, so reduce reference count

This is done to prevent a memory leak produced by keeping instances in the instanceStore when they are no longer needed by the application.

Note: a hazard of sharing the same instance is that if new instance data is loaded from the server during on-going editing of the instance, the new server data will replace the data that is edited but not yet saved. This is because whenever data is loaded from the server, it is passed to updatedInstance which updates the shared instance properties with the new server data.