I use side-loading extensively in my Ember Data app to avoid making multiple round-trips to the API, and until now it has always worked out great.
I am using Ember 1.6.0-beta.3, Ember Data 1.0.0-beta.7, DS.ActiveModelAdapter, and DS.ActiveModelSerializer.
If I save a Foo model, which causes this request:
POST /foos
{
"foo": {
"name": "Foo"
}
}
The server responds with the created Foo, but also with a side-loaded Bar that references the new Foo.
201 Created
{
"foo": {
"id": 1,
"name": "Foo"
},
"bars": {
"id": 1,
"foo_ids": [1]
}
}
After this response, it appears that the Bar does not know that a Foo with ID=1 is in the store, and issues the following request:
GET /foos?ids[]=1
This request fails because I don't have that endpoint. I would not expect that Ember Data should send this request at all, because we just loaded the Foo with ID=1.
Instead, I would expect that no additional request should be made. Instead, the Bar should become associated with the newly created Foo.
Is my expectation out of line? Is this a bug?
EDIT
I was able to work around this issue by explicitly side-loading the foo. This is very inelegant, but hey, it's a work-around.
Specifically, I changed my API to respond with the following after a POST /foos:
{
"foo": {
"id": 1,
"name": "Foo"
},
"bars": {
"id": 1,
"foo_ids": [1]
},
"foos": [{
"id": 1,
"name": "Foo"
}]
}
Then the side-loaded Bar doesn't try to load it's Foo.
I'm going to leave this open, because a work-around is not a fix.
Related
I’m running into an issue with the REST Adapter/Serializer and EmbeddedRecordsMixin, specifically my app needs to be able to sideload an model’s parent record in create/POST responses, and that parent model contains the child record embedded in a hasMany array. This is resulting in “You cannot update the id index of an InternalModel once set.” errors. heres a simplified version of the JSON structure my api is returning:
// POST /child-model response
{
"childModel": {
"id": 1,
"foo": "Bar"
},
"parentModel": {
"id": 2,
"children": [
{
"id": 1,
"foo": "Bar"
}
]
}
}
Is there any way to allow this type of response? Essentially I want ember-data to just treat the embedded child record as just an "update" to the record that was just created, where it is just using it to make the association between it and the parent record.
I am trying to use the JSON API Adapter with ember-cli 2.5.1 , but I'm having a bit of trouble.
I have a todo-list.js model, which has a "hasMany" relationship to todo-list-item.js. Getting the todo-list, the server returns this:
{
"links": {
"self": "http://localhost:4200/service/v1/todolists/b-tlst-af69786c-cbaf-4df9-a4a3-d8232677006a"
},
"data": {
"type": "todo-list",
"id": "b-tlst-af69786c-cbaf-4df9-a4a3-d8232677006a",
"attributes": {
"name": "b1-TodoList",
"created-on": 1468474962458,
"modified-on": 1468474962458
},
"relationships": {
"todolistitems": {
"data": {
"type": "todo-list-item",
"id": "b-todo-b5e3c146-d93a-4f97-8540-875bbcd156ca"
}
}
}
}
}
If there had been two TodoListItem children instead of one, the value of that "data" key would have been an array, rather than an object.
After receiving this, I was expecting the Ember Chrome plug-in's "Data" tab to show 1 TodoList and 1 child TodoListItem. Instead, it shows 1 TodoList and 0 TodoListItems.
I note from the Network tab that the browser never makes a request to get the items listed in the "data" section of the response.
Is the relationships section above correct and sufficient?
It turns out to have been caused by promise misunderstandings on the client side, and additionally, on the server I had to put dashes in the "relationships" key (i.e. "todo-list-items") and make the value of "data" an array.
I am new to Ember and I will like to implement a server side search endpoint that returns results for several models/tables in DB.
Trying to figure out what is the best practice to do this in Ember.
Server results can contain several types of objects/models, each model is already defined in ember-data.
So far I am able to retrieve the results (I can see the results in ember-inspector) but I am not able to render it properly (I only have access to first object for some reason).
Current architecture:
rails-5 server with JSONAPI response
ember 2.3 with multiple models
Flow:
POST /search with body:
{"search":{"query": "xxx","size": "10"}}
RESULT:
{
"data": [
{
"id": "111111",
"type": "foo",
"attributes": {
"x": "y"
}
},
{
"id": "222222",
"type": "bar",
"attributes": {
"z": "y"
}
}
]
}
I'm trying to create record with associated records in one request. In case if some of nested records have validation errors, I'd like to access appropriate errors on that record. I'm using json-api adaptor, so what should be the format of errors from the backend? I'm trying something like this, with no luck though:
{"errors":[
{
"detail": "can't be blank",
"source": {
"pointer":"data/relationships/steps/0/data/attributes/est_threshold"
}
}
]}
According to this line, it should be implemented somehow:
https://github.com/emberjs/data/blob/master/addon/adapters/errors.js#L7
Any ideas?
You'll need to sideload nested records in the data. The example structure given in the ember guides is:
{
"post": {
"id": 1,
"title": "Node is not omakase",
"comments": [1, 2, 3]
},
"comments": [{
"id": 1,
"body": "But is it _lightweight_ omakase?"
},
{
"id": 2,
"body": "I for one welcome our new omakase overlords"
},
{
"id": 3,
"body": "Put me on the fast track to a delicious dinner"
}]
}
https://guides.emberjs.com/v1.10.0/models/the-rest-adapter/
So it doesn't seem to be implemented yet. I found kinda hackish way to do that in the model mixin:
`import Ember from 'ember'`
RelatedErrors = Ember.Mixin.create
save: ->
#_super().catch (resp) =>
resp.errors.forEach (err) =>
if [_, rel, idx, attr] = err.source.pointer.match /^data\/relationships\/(\w+)\/(\d+)\/data\/attributes\/(\w+)$/
#get(rel).objectAt(idx).get('errors').add(attr, err.detail)
`export default RelatedErrors`
However, add on DS.Errors is deprecated, so this is still not a perfect solution. Also invalid state of related models need to be cleared before each commit, which is not happening this far.
I'm working on a web service API using the HATEOAS REST representation.
My client can create an item (e.g. a stub of a blogpost):
POST /item
204 Created
Content-Type: application/vnd.foo.item+json
{
"id": 42,
"title": "Lorem Ipsum",
"status": "STUB",
"body": "Very long text."
"_links": {
"self": {
"href": "/item/42"
},
"activate": {
"href": "/item/42/activate"
},
}
}
After that the client can activate the item following the activate link (e.g. go live with the post). So it makes another call to the API:
POST /item/42/activate
200 Ok
Content-Type: application/vnd.foo.item+json
{
"id": 42,
"title": "Lorem Ipsum",
"status": "ACTIVE",
"body": "Very long text."
"_links": {
"self": {
"href": "/item/42"
},
"permalink": {
"href": "/item/42/permalink"
}
}
}
Up to here it is fine. But the problem is that I'm looking for a way to tell the client a suggestion about the next action to do (it's backend business logic).
In my case could be:
Bring the user to post page following the permalink
Bring the user to a shop cart to buy post extra features (visibility, more images, homepage positions and so on...)
Tell the user that the post is pending content review
I don't have an idea on how I could encapsulate this information in HATEOAS.
I was thinking to something like:
POST /item/42/activate
200 Ok
Content-Type: application/json
{
"suggested-action": "check-censure-panel",
"censure-reason": "censored (gambling)",
"_embedded": {
"foo.item": {
"id": 42,
"title": "Lorem Ipsum",
"status": "ACTIVE",
"body": "Very long text."
"_links": {
"self": {
"href": "/item/42"
},
"permalink": {
"href": "/item/42/permalink"
}
}
}
}
But the problem is that every suggested action is heterogeneous for extra attributes, another example may be:
"suggested-action": "go-to-checkout",
"product-order": 424242100,
They don't have a common interface, so I can't make a a vnd.foo.suggestedAction+json type.
What is the best way to design this response?
The next action is a state transition, and you seem to be using HAL so any state transitions should be presented as HAL.
Clients of your app need to react to what state transitions your app provides. So one very simple thing you could do is send a Location header to the next resource the app should present. You could even 302 redirect them there instead of 200'ing them with the updated resource.
You could provide the next action as a link...and not necessarily a HAL link. You could do it as a Link header (https://www.rfc-editor.org/rfc/rfc5988) but i think that would be weird, i just bring it up to knock home the point that your app needs to tell your client about a link.
You seem to want to use custom media types, but you could use profile links (https://www.rfc-editor.org/rfc/rfc6906) and mix in a profile into your vnd.foo type. You can stick to your vnd.foo type and just have it defined that there is an optional suggested-action link relationship. The problem in your example is you're defining it with data fields, but use a link:
{
"id": 42,
"title": "Lorem Ipsum",
"status": "ACTIVE",
"body": "Very long text."
"_links": {
"self": {
"href": "/item/42"
},
"permalink": {
"href": "/item/42/permalink"
},
"x:suggested-action" : {
"href" : "/path/to/best/action"
}
}
the client can follow that link, present the user with an option to follow that link, or ignore it. In the middle case, it's nice if your app provides some context to the user, like a title field:
"x:suggested-action" : {
"href" : "http://path/to/check/censure/panel",
"title" : "Check Censure Panel"
}
Also you can give a hint as to the resource the app can expect:
"x:suggested-action" : {
"href" : "http://path/to/check/censure/panel",
"title" : "Check Censure Panel",
"type" : "vnd.censure.panel/json"
}
I personally don't like doing that as i like my client to react to whatever i send them, but it's useful when you give multiple suggested actions:
"x:suggested-action" : [
{
"href" : "http://path/to/check/censure/panel",
"title" : "Check Censure Panel",
"type" : "vnd.censure.panel/json"
},
{
"href" : "http://path/to/checkout",
"title" : "Start Checkout",
"type" : "vnd.checkout/json"
}
]
now the app can decide based on well defined media types which of the suggested actions it wants to do, present, or ignore.