How to use api property in config of store proxy - the CRUD Methods

Question

Can anyone tell me where should we write the create/update etc snippet of codes. I am writing it under the api property of proxy. How to verify the output. Please guide me on how to use store api.

I'm into testing, so please be more clear in making me understand and usage of the functionality

Answer 1

The config itself is described here in the docs. But it sounds like you have the syntax correct.

The first thing you should know is that this config only applies to proxies which extend Ext.data.proxy.Server. Read the "Types of Proxy" section here.

By defining different URLs in this config you are simply telling the store where to send the ajax request to perform the different CRUD actions on your server side.

For example, a call to store.load() will send the ajax request to the api.read URL, it is up to you to make sure this URL returns the data properly.

An Ext.data.Store internally keeps track of the other actions performed on "dirty" records (created, updated or destroyed). Based on this it will send an ajax request to the appropriate api config URL. Or if you performed different types of actions e.g. created and deleted records it will send more than one ajax request (one to each URL) along with the data about the records you created or deleted.

Here's some example code to illustrate this (which you could also use for testing if you fill in your own URLs and data.model). The example uses the default reader/writer which sends data to the server as JSON (there are configs in the proxy to specify a different format).

var myStore = Ext.create('Ext.data.Store', {
    model: 'MyApp.model.SomeModel',
    proxy: {
        type: 'ajax',
        // without api defined ALL ajax calls will use the 'url' config
        url: '/some/url',
        api: {
            create: '/some/url/to/insert/records/in/db',
            read: '/some/url/to/select/records/from/db',
            update: '/some/url/to/update/records/in/db',
            destroy: '/some/url/to/delete/records/in/db'
        }
    }
}

// this calls the api.read URL
myStore.load(); 

// assuming we now have records, this will delete the first record 
// on the client side (it will error if there are not records)
myStore.remove(myStore.first());

// the store knows we deleted a record so this will call the api.destroy URL
myStore.sync();

// this updates the first record on the client side
myStore.first().set('some_field_name', 'a string value');

// now we are creating a record on the client side
myStore.add(Ext.create('MyApp.model.SomeModel'));

// the store knows we updated AND created a record so this will call the
// api.update URL AND the api.create URL
myStore.sync();

Two other useful tidbits of information about this:

1. There is a proxy config called batchActions described here in the docs. It is true by default, which means that all CRUD actions of a certain type are grouped into an array when you send the request to the database. E.g. if you deleted 4 records, your api.destroy URL will not receive 4 ajax requests, it will receive 1 ajax request with an array of 4 records. This helps cut down on the network traffic as long as you configure your URL to handle an array. You can set this config to false and the store will send 4 requests to the api.destroy URL instead. You can also set the writer's allowSingle config (described here) to ensure that all requests are sent as an array even if there is only one record (that way you can set up your server side code to always handle an array).

2. Ext.data.Store is set-up to handle a callback for create and update actions, you just have to make sure your URL sends one back. When you call myStore.sync() the store will automatically replace the record on the client side with the one you send in your callback. This is useful for created records because you can send back the correct database ID with the created record and have it available on the client side, later if the user wants to edit or delete the record you have the correct database ID to work with. You can also do other processing on the server side and send back other data as well so that you have a complete record (e.g. I sometimes send back the create user ID and create time as well).