AbstractCrudManagerMixin

Convenience shortcut to set only the url to load from, when you do not need to supply any other config options in the load section of the transport config.

Using loadUrl:

{
    loadUrl : 'read.php
}

Equals the following transport config:

{
    transport : {
        load : {
            url : 'read.php'
        }
    }
}

When read at runtime, it will return the value from transport.load.url.

Convenience shortcut to set only the url to sync to, when you do not need to supply any other config options in the sync section of the transport config.

Using loadUrl:

{
    syncUrl : 'sync.php
}

Equals the following transport config:

{
    transport : {
        load : {
            url : 'sync.php'
        }
    }
}

When read at runtime, it will return the value from transport.sync.url.

Specify true to automatically call load method on the next frame after creation.

Called on the next frame to allow a Scheduler (or similar) linked to a standalone CrudManager to register its stores before loading starts.

true to automatically persist store changes after edits are made in any of the stores monitored. Please note that sync request will not be invoked immediately but only after autoSyncTimeout interval.

The timeout in milliseconds to wait before persisting changes to the server. Used when autoSync is set to true.

Sets the list of stores controlled by the CRUD manager.

When adding a store to the CrudManager, make sure the server response format is correct for load and sync requests. Learn more in the Working with data guide.

Store can be provided by itself, its id or as a store descriptor.

Specify as true to force sync requests to be sent when calling sync(), even if there are no local changes. Useful in a polling scenario, to keep client up to date with the backend.

Set to true to make STM ignore changes coming from the backend. This will allow user to only undo redo local changes.

Set to false to only include the id of a removed parent node in the request to the backend (also affects programmatic calls to get changes etc.), and not the ids of its children.

Consider the following scenario, removing parent 1:

{
  id : 1,
  children : [
    { id : 11 },
    { id : 12 }
  ]
}

With includeChildrenInRemoveRequest : false, the backend will only receive the removal of id 1.

With includeChildrenInRemoveRequest : true (the default), the backend will receive the removal of id 1, 11 and 12.

Field name to be used to transfer a phantom record identifier.

Field name to be used to transfer a phantom parent record identifier.

True to reset identifiers (defined by idField config) of phantom records before submitting them to the server.

Name of a store property to retrieve store identifiers from. Make sure you have an instance of a store to use it by id. Store identifier is used as a container name holding corresponding store data while transferring them to/from the server. By default, id property is used. And in case a container identifier has to differ this config can be used:

class CatStore extends Store {
    static configurable = {
        // store id is "meow" but for sending/receiving store data
        // we want to have "cats" container in JSON, so we create a new property "storeIdForCrud"
        id             : 'meow',
        storeIdForCrud : 'cats'
    }
});

// create an instance to use a store by id
new CatStore();

class MyCrudManager extends CrudManager {
    ...
    crudStores           : ['meow'],
    // crud manager will get store identifier from "storeIdForCrud" property
    storeIdProperty  : 'storeIdForCrud'
});

The storeIdProperty property can also be specified directly on a store:

class CatStore extends Store {
    static configurable = {
        // storeId is "meow" but for sending/receiving store data
        // we want to have "cats" container in JSON
        id              : 'meow',
        // so we create a new property "storeIdForCrud"..
        storeIdForCrud  : 'cats',
        // and point CrudManager to use it as the store identifier source
        storeIdProperty  : 'storeIdForCrud'
    }
});

class DogStore extends Store {
    static configurable = {
        // storeId is "dogs" and it will be used as a container name for the store data
        storeId : 'dogs',
        // id is set to get a store by identifier
        id      : 'dogs'
    }
});

// create an instance to use a store by id
new CatStore();
new DogStore();

class MyCrudManager extends CrudManager {
    ...
    crudStores : ['meow', 'dogs']
});

When true the Crud Manager does not require all updated and removed records to be mentioned in the sync response. In this case response should include only server side changes.

Please note that added records should still be mentioned in response to provide real identifier instead of the phantom one.

An array of store identifiers sets an alternative sync responses apply order. By default, the order in which sync responses are applied to the stores is the same as they registered in. But in case of some tricky dependencies between stores this order can be changed:

class MyCrudManager extends CrudManager {
    // register stores (will be loaded in this order: 'store1' then 'store2' and finally 'store3')
    crudStores : ['store1', 'store2', 'store3'],
    // but we apply changes from server to them in an opposite order
    syncApplySequence : ['store3', 'store2', 'store1']
});

When true forces the CRUD manager to process responses depending on their type attribute. So load request may be responded with sync response for example. Can be used for smart server logic allowing the server to decide when it's better to respond with a complete data set (load response) or it's enough to return just a delta (sync response).

true to write all fields from the record to the server. If set to false it will only send the fields that were modified. Note that any fields that have persist set to false will still be ignored and fields having alwaysWrite set to true will always be included.

Convenience shortcut to set only the url to load from, when you do not need to supply any other config options in the load section of the transport config.

Using loadUrl:

{
    loadUrl : 'read.php
}

Equals the following transport config:

{
    transport : {
        load : {
            url : 'read.php'
        }
    }
}

When read at runtime, it will return the value from transport.load.url.

Convenience shortcut to set only the url to sync to, when you do not need to supply any other config options in the sync section of the transport config.

Using loadUrl:

{
    syncUrl : 'sync.php
}

Equals the following transport config:

{
    transport : {
        load : {
            url : 'sync.php'
        }
    }
}

When read at runtime, it will return the value from transport.sync.url.

Returns current changes as an object consisting of added/modified/removed arrays of records for every managed store, keyed by each store's id. Returns null if no changes exist. Format:

{
    resources : {
        added    : [{ name : 'New guy' }],
        modified : [{ id : 2, name : 'Mike' }],
        removed  : [{ id : 3 }]
    },
    events : {
        modified : [{  id : 12, name : 'Cool task' }]
    },
    ...
}

The server revision stamp. The revision stamp is a number which should be incremented after each server-side change. This property reflects the current version of the data retrieved from the server and gets updated after each load and sync call.

A list of registered stores whose server communication will be collected into a single batch. Each store is represented by a store descriptor.

Specify as true to force sync requests to be sent when calling sync(), even if there are no local changes. Useful in a polling scenario, to keep client up to date with the backend.

Set to true to make STM ignore changes coming from the backend. This will allow user to only undo redo local changes.

Returns true if changes tracking is suspended

Returns true if the crud manager is currently loading data

Returns true if the crud manager is currently syncing data

An array of stores presenting an alternative sync responses apply order. Each store is represented by a store descriptor.

Accepts all changes in all stores, resets the modification tracking:

• Clears change tracking for all records
• Clears added
• Clears modified
• Clears removed Leaves the store in an "unmodified" state.

Adds a store to the collection.

// append stores to the end of collection
crudManager.addCrudStore([
    store1,
    // storeId
    'bar',
    // store descriptor
    {
        storeId : 'foo',
        store   : store3
    },
    {
        storeId         : 'bar',
        store           : store4,
        // to write all fields of modified records
        writeAllFields  : true
    }
]);

Note: Order in which stores are kept in the collection is very essential sometimes. Exactly in this order the loaded data will be put into each store.

When adding a store to the CrudManager, make sure the server response format is correct for load and sync requests. Learn more in the Working with data guide.

Adds a store to the alternative sync responses apply sequence. By default, the order in which sync responses are applied to the stores is the same as they registered in. But this order can be changes either on construction step using syncApplySequence option or by calling this method.

Please note, that if the sequence was not initialized before this method call then you will have to do it yourself like this for example:

// alternative sequence was not set for this crud manager
// so let's fill it with existing stores keeping the same order
crudManager.addStoreToApplySequence(crudManager.crudStores);

// and now we can add our new store

// we will load its data last
crudManager.addCrudStore(someNewStore);
// but changes to it will be applied first
crudManager.addStoreToApplySequence(someNewStore, 0);

add registered stores to the sequence along with the store(s) you want to add

Applies a set of changes, as an object keyed by store id, to the affected stores. This function is intended to use in apps that handle their own data syncing, it is not needed when using the CrudManager approach.

Example of a changeset:

project.applyChangeset({
    events : {
        added : [
            { id : 10, name : 'Event 10', startDate : '2022-06-07' }
        ],
        updated : [
            { id : 5, name : 'Changed' }
        ],
        removed : [
            { id : 1 }
        ]
    },
    resources : { ... },
    ...
});

Optionally accepts a transformFn to convert an incoming changeset to the expected format. See applyChangeset for more details.

Setting clearChanges param to false will result in restoring the changes on the store applied using the applyChangeset method. By default, it has been set to true to clear all the applied changes on the store.

For example, following will restore the changes on the store:

// Apply these changes using the applyChangeset method
project.applyChangeset({
    events : {
        added : [
            { id : 10, name : 'Event 10', startDate : '2022-06-07' }
        ],
        updated : [
            { id : 5, name : 'Changed' }
        ],
        removed : [
            { id : 1 }
        ]
    },
    resources : { ... },
    ...
}, null, '$PhantomId', false);

Returns true if any of registered stores (or some particular store) has non persisted changes.

// if we have any unsaved changes
if (crudManager.crudStoreHasChanges()) {
    // persist them
    crudManager.sync();
// otherwise
} else {
    alert("There are no unsaved changes...");
}

Returns a registered store.

Returns a registered store descriptor.

Loads data to the stores registered in the crud manager. For example:

crudManager.load(
    // here are request parameters
    {
        store1 : { append : true, page : 3, smth : 'foo' },
        store2 : { page : 2, bar : '!!!' }
    }
).then(
    () => alert('OMG! It works!'),
    ({ response, cancelled }) => console.log(`Error: ${cancelled ? 'Cancelled' : response.message}`)
);

** Note: ** If there is an incomplete load request in progress then system will try to cancel it by calling cancelRequest.

Loads data to the Crud Manager

Removes a store from collection. If the store was registered in alternative sync sequence list it will be removed from there as well.

// remove store having storeId equal to "foo"
crudManager.removeCrudStore("foo");

// remove store3
crudManager.removeCrudStore(store3);

Removes a store from the alternative sync sequence.

// remove store having storeId equal to "foo"
crudManager.removeStoreFromApplySequence("foo");

Resumes automatic sync upon store changes. Will schedule a sync if the internal counter is 0.

Resumes hasChanges and noChanges events. By default, it will check for changes and if there are any, hasChanges or noChanges event will be triggered.

Reverts all changes in all stores and re-inserts any records that were removed locally. Any new uncommitted records will be removed.

Suspends automatic sync upon store changes. Can be called multiple times (it uses an internal counter).

Suspends hasChanges and noChanges events.

Persists changes made on the registered stores to the server and/or receives changes made on the backend. Usage:

// persist and run a callback on request completion
crud.sync().then(
    () => console.log("Changes saved..."),
    ({ response, cancelled }) => console.log(`Error: ${cancelled ? 'Cancelled' : response.message}`)
);

** Note: ** If there is an incomplete sync request in progress then system will queue the call and delay it until previous request completion. In this case syncDelayed event will be fired.

** Note: ** Please take a look at autoSync config. This option allows to persist changes automatically after any data modification.

** Note: ** By default a sync request is only sent if there are any local changes. To always send a request when calling this function, configure forceSync as true.

Cancels request to the server.

Decodes response from the server.

Encodes request to the server.

Sends request to the server.