Module Ext_data_Store


module Ext_data_Store: sig .. end
The Store class encapsulates a client side cache o ...

The Store class encapsulates a client side cache of Model objects. Stores load data via a Proxy, and also provide functions for sorting, filtering and querying the model instances contained within it.

Creating a Store is easy - we just tell it the Model and the Proxy to use for loading and saving its data:

 // Set up a model to use in our Store
 Ext.define('User', {
     extend: 'Ext.data.Model',
     fields: [
         {name: 'firstName', type: 'string'},
         {name: 'lastName',  type: 'string'},
         {name: 'age',       type: 'int'},
         {name: 'eyeColor',  type: 'string'}
     ]
 });

 var myStore = Ext.create('Ext.data.Store', {
     model: 'User',
     proxy: {
         type: 'ajax',
         url: '/users.json',
         reader: {
             type: 'json',
             root: 'users'
         }
     },
     autoLoad: true
 });

In the example above we configured an AJAX proxy to load data from the url '/users.json'. We told our Proxy to use a JsonReader to parse the response from the server into Model object - see the docs on JsonReader for details.

Inline data

Stores can also load data inline. Internally, Store converts each of the objects we pass in as data into Model instances:

 Ext.create('Ext.data.Store', {
     model: 'User',
     data : [
         {firstName: 'Ed',    lastName: 'Spencer'},
         {firstName: 'Tommy', lastName: 'Maintz'},
         {firstName: 'Aaron', lastName: 'Conran'},
         {firstName: 'Jamie', lastName: 'Avins'}
     ]
 });

Loading inline data using the method above is great if the data is in the correct format already (e.g. it doesn't need to be processed by a reader). If your inline data requires processing to decode the data structure, use a MemoryProxy instead (see the MemoryProxy docs for an example).

Additional data can also be loaded locally using add.

Dynamic Loading

Stores can be dynamically updated by calling the load method:

store.load({
    params: {
        group: 3,
        type: 'user'
    },
    callback: function(records, operation, success) {
        // do something after the load finishes
    },
    scope: this
});

Here a bunch of arbitrary parameters is passed along with the load request and a callback function is set up to do something after the loading is over.

Loading Nested Data

Applications often need to load sets of associated data - for example a CRM system might load a User and her Orders. Instead of issuing an AJAX request for the User and a series of additional AJAX requests for each Order, we can load a nested dataset and allow the Reader to automatically populate the associated models. Below is a brief example, see the Ext.data.reader.Reader intro docs for a full explanation:

 var store = Ext.create('Ext.data.Store', {
     autoLoad: true,
     model: "User",
     proxy: {
         type: 'ajax',
         url: 'users.json',
         reader: {
             type: 'json',
             root: 'users'
         }
     }
 });

Which would consume a response like this:

 {
     "users": [{
         "id": 1,
         "name": "Ed",
         "orders": [{
             "id": 10,
             "total": 10.76,
             "status": "invoiced"
        },{
             "id": 11,
             "total": 13.45,
             "status": "shipped"
        }]
     }]
 }

See the Ext.data.reader.Reader intro docs for a full explanation.

Filtering and Sorting

Stores can be sorted and filtered - in both cases either remotely or locally. The sorters and filters are held inside MixedCollection instances to make them easy to manage. Usually it is sufficient to either just specify sorters and filters in the Store configuration or call sort or filter:

 var store = Ext.create('Ext.data.Store', {
     model: 'User',
     sorters: [{
         property: 'age',
         direction: 'DESC'
     }, {
         property: 'firstName',
         direction: 'ASC'
     }],

     filters: [{
         property: 'firstName',
         value: /Ed/
     }]
 });

The new Store will keep the configured sorters and filters in the MixedCollection instances mentioned above. By default, sorting and filtering are both performed locally by the Store - see remoteSort and remoteFilter to allow the server to perform these operations instead.

Filtering and sorting after the Store has been instantiated is also easy. Calling filter adds another filter to the Store and automatically filters the dataset (calling filter with no arguments simply re-applies all existing filters). Note that by default sortOnFilter is set to true, which means that your sorters are automatically reapplied if using local sorting.

store.filter('eyeColor', 'Brown');

Change the sorting at any time by calling sort:

store.sort('height', 'ASC');

Note that all existing sorters will be removed in favor of the new sorter data (if sort is called with no arguments, the existing sorters are just reapplied instead of being removed). To keep existing sorters and add new ones, just add them to the MixedCollection:

store.sorters.add(new Ext.util.Sorter({
    property : 'shoeSize',
    direction: 'ASC'
}));

store.sort();

Registering with StoreManager

Any Store that is instantiated with a storeId will automatically be registered with the StoreManager. This makes it easy to reuse the same store in multiple views:

//this store can be used several times
Ext.create('Ext.data.Store', {
    model: 'User',
    storeId: 'usersStore'
});

new Ext.List({
    store: 'usersStore',
    //other config goes here
});

new Ext.view.View({
    store: 'usersStore',
    //other config goes here
});

Further Reading

Stores are backed up by an ecosystem of classes that enables their operation. To gain a full understanding of these pieces and how they fit together, see:



class type t = object .. end
class type configs = object .. end
class type events = object .. end
class type statics = object .. end
val of_configs : configs Js.t -> t Js.t
of_configs c casts a config object c to an instance of class t
val to_configs : t Js.t -> configs Js.t
to_configs o casts instance o of class t to a config object