Ext.data.proxy.Rest.html and CRUD

[timmkd]

I'm using Ext.data.proxy.Rest.html to update my Store.

When I create a new model/row in my store, it is the proxy is sending a POST request correctly, however it is adding it's own id to the model it is creating, and sending that id to the server. I understand it needs a unique id when creating a new row in my Store, but when it sends that unique id to my servers API, it is causing an error because the API I am using is expecting to create it's own id.

Is there any way to remove the local id from the request and then use the servers id that will be sent in the API's response?

[tristan.lee]

Checkout the Ext.data.proxy.Rest#appendId config. This is true by default, but setting it to false should remove that from your request.

[timmkd]

Thanks Tristan, however the appendId config seems to be for resolving a different issue than mine. It seems to remove the id from appending id's to the URL sent to the server but there is no mention of it affecting the actual json object sent in a POST request. I have not been able to remove the id from the json sent to the server in a POST request with this config.

[tristan.lee]

Sorry, I think I misread your request. This would be handled by the Writer for the request, which also has a config to not send the record ID.

proxy: {
    type: 'rest',
    ...
    writer: {
        type: 'json',
        writeRecordId: false
    }
}

[timmkd]

Ah yes, this does solve the problem for POST requests which are used when adding items via a RESTful API.

However this now removed the id from ALL requests, when it is still needed for update and delete requests when it is sent via PUT and DEL.

Example
-CREATE an item, (POST) it is new and needs no id as the server needs to assign it one and it is a new item so it should have no id (especially one assigned by ExtReact).
-UPDATE an item, (PUT) it does need an id so the server knows which item to update.
-DELETE an item, (DEL) it does need an id so the server knows which item to delete.

Does that make sense? I feel like this should be standard but perhaps I am doing it the wrong way?

[timmkd]

Actually I can see I may be able to resolve this using the transform config. I'll look into that unless there is a better preferred method.

[tristan.lee]

A new model created from within the app will be a phantom record and therefore the ID should, by default, not be included in the request. I would need to double-check that though. However, transform function was going to be my final suggestion for you to modify the data as needed before it is finally sent off in the request.

[timmkd]

I think transform will be my goto for now.

It may be a bug that the ID is being included for phantom records as the proxy was definitely sending an id in my create POST requests.

[timmkd]

Is it possible to get some clarification on how a record is supposed to work when added to a store? It seems there may be some bugs here as Tristan, you mentioned that there should be no id for phantom records, but I can see that the store is definitely creating it's own id like 'extModel25-1'

I am trying to assign the server-created id to my item when it sends a 'create' request, but I don't seem to be able to get the Store to save the server-created id to the item even when I get a successful response from the server of the new items id.

How is the store supposed to assign the correct id of a new item if it is making up it's own id when it creates an new item in a store?

[tristan.lee]

The record in the store will always have an ID - whether it is one you give it, or a generated one for phantom records. When I said the I shouldn't be included in the request by default for phantom records, I was referring to this: http://docs.sencha.com/extreact/6.5....-writeRecordId

By default, each record's id is always included in the output for non-phantom records since in most cases the id will be required on the server to process the record action. This is helpful since the id will normally not be modified, and so would not be sent to the server unless writeAllFields was explicitly enabled.
However, there are cases where it is not desirable for the record id to be passed in the data directly. For example, when using a RESTful API the record id would typically be appended to the url instead.

That lead me to believe that when saving a phantom record, the ID would not be passed in the request. I see that it is so either that part is a bug or I am not fully understanding the behavior.

However, upon saving the model, if you return the server-generated ID in the response, it will update the model instance in the store. Here's an example:


Granted this is using a hard-coded response in data1.json, this still simulates how things should behave if you got the response from your server.