Hi,
When you do a custom serializer I can’t understand why it assumes that the serializer will be the same for each type of call. It hides what type of requestType it is. You really need a serializeCreateRecord, serializeDeleteRecord, serializeFindAll etc. in order for it to be flexible to the server’s requirements.
The whole point of serializers were to customise the responses to suit a third party server that maybe you can’t change. Yet 9/10 you end up having to just bin off the serializer and do the custom serialization work in the adapter instead because it is only the adapter that lets you identify what request you’re in (e.g via the createRecord, findAll, deleteRecord, findRecord hooks), I find.
Am I doing anything wrong here or missing something?
If you’re referring to responses coming back from the server to the client (normalization) I’ve definitely encountered places where I had to handle some things in the adapter handleResponse method, BUT the serializer API is very broad and does have methods for normalizing a lot of different response types e.g.:
normalize
normalizeArrayResponse
normalizeCreateRecordResponse
normalizeDeleteRecordResponse
normalizeFindAllResponse
normalizeFindBelongsToResponse
normalizeFindHasManyResponse
normalizeFindManyResponse
normalizeFindRecordResponse
normalizeQueryRecordResponse
normalizeQueryResponse
normalizeSaveResponse
normalizeSingleResponse
normalizeUpdateRecordResponse
Hi,
Thanks, as far as I know - those function are handling the replies coming back (as you say) from the server not the request being sent out.
The infrastructure in ember data around request being sent out seems very rigid and not flexible hence the need to always override the createRecord/deleteRecord/findAll etc
What I would like is for serialize() to always be called for all the requestTypes instead of just the ones that send a POST/PATCH/PUT. Or to have a shouldSerialize() callback which means data is sent even if it violates what that request type is (e.g the data should be sent for a GET).
All the requestTypes should have a VERB override hook e.g function GetVerb() { return “POST”; } and they all should give the adapter the chance to set the data in it without having to redefine the whole call to createRecord/findAll/findRecord/updateRecord which requires background knowledge that frankly is not in the guides or API docs.
This way, you could take it further with hooks before having to start rewriting the whole adapter.
By default, the serializer could have serializeFindRecord/serializeFindAll/serializeCreateRecord and the rest - even if they by default they resolve to the same serialize() functionality that makes them behave as it is now.
The reason for the proposed madness is that some servers or API writers are madness.
Yeah I understand the frustration but I’d also say it seems like it stems mostly from the API in question vs Ember Data. One of the staple ideas of Ember is convention over configuration, and so (and this is me extrapolating here, I’m not a core team member or anything) I think Ember Data was designed to be used with conventional use of HTTP requests.
I think most people also tend to assume that Ember Data is the right path since it is included by default but sometimes it’s a better choice not to use Ember Data at all, so if you find yourself running into cases where Ember Data conventions don’t fit your needs looking at other solutions may be in your best interest.
That said, the great thing about the Ember community is that you can open an RFC to propose features or changes so I would encourage you to do that if you feel like you have a strong supporting case.
Thanks for your reply.
I don’t want to diss it too much, I do like the ability of being able to keep the application the same with the createRecord/deleteRecord etc calls and just swap in a new adapter for different servers.
My bug bear is that the adapter customization is really to be able to adjust to the server’s way of doing things but Ember Data doesn’t take it far enough - but is almost there. It also is terrible on the docs and guides - ample stuff seems missing from release to release. That doesn’t help.
If they just gave more freedom on REST requests it would be perfect for JSON-API emulation on dodgy server API’s.
FWIW the EmberData team agrees these limitations are bad and we’ve been working on a replacement for adapters and serializers that keeps request context both outbound and inbound.
That said, you don’t have to use serializers at all and can do whatever you want in the adapter.
I must admit, I was thankful for that.