Looking Ahead with Stores

By on May 16, 2014 1:25 pm

Part of the foundation of the Dojo architecture is the data store layer. Dojo applications are built on a uniform interface for accessing different data sources, to make it possible for different presentation components to be used with different data models. We are continuing to work towards evolving and refining our data layer at SitePen. Lately we have been working on a new project called dstore, that represents our vision for the future of the Dojo data layer. The dstore project will include a number of improvements and new capabilities, including an improved querying API, better notifications, more stores, and a data modelling system for individual objects.

Data Modelling

The dstore project will inherit many of the key components from Dojo object stores, including most of the interface, an in-memory store, a RESTful server-connected store, querying, and caching functionality. Perhaps the biggest addition will be the new data modelling structure for managing individual objects. The data modelling will provide validation, monitoring, coercion, computed properties, and metadata in a convenient, encapsulated uniform interface. This will form the foundation for components and data bindings that can easily react to data changes and different structures.

Queries and Notifications

We have also been working on improving how querying works, providing an iterative API for defining a collection. Our new approach will mean that you can apply a filter, and get a collection of results that can be passed to another component, which could apply sorting or paging. We hope this will facilitate cleaner separation of concerns and layering of views and models.

The new querying API will also benefit our new notification system. Notifications will be available through a standard event API (an on() method), for greater consistency. And, by being able to separate out different steps in the query process, components like dgrid will be able to easily listen to events at a broader collection level rather than try to aggregate events from individual pages.

There has also been a focus on improving the manageability of the stores. We have been moving to a more consistent usage of mixins for composing store functionality (much like dgrid). Features like caching, alternate format parsing, and validation will be available as mixins that can easily be applied to construct new store configurations. We are also developing dstore with intern as our testing framework for improved test coverage and testing management.

Local Database Stores

Finally, we have been creating a new set of local database stores that provide access to IndexedDB and WebSQL through the uniform object store interface. These stores will be invaluable for creating offline-capable applications and bridging the large API divide between the different database APIs available on Safari (WebSQL only) and Firefox and IE (IndexedDB only, Chrome supports both). We have been focused on creating these stores with scalability and performance as top priorities, fully leveraging the indexing capabilities of the different database engines. These will actually be initially released in dojox, so that they will be available as an implementation of the current object store interface. We are planning on including these in dstore in a later release.


We are excited to see dstore coming together to provide a robust, comprehensive data layer for building Dojo applications. More stores and improved querying will enable a more consistent approach to collections of data, and the data modelling capabilities with powerful object-level schemas and validation will give Dojo developers a complete foundation for data-driven applications.


  • Should we expect this in the 1.x or 2.x series?

  • aarkhipov1991

    How about some code examples? =)

  • It works with 1.x, but is the intended API for 2.x.

  • We have a bunch of examples in the works, but we’re trying to finalize the 1.0 package first.