buildQuery RFC - #135
Conversation
|
@grapho For normalizing queryParams I resorted many times to override the Can you elaborate why you think this approach is not enough? |
|
@cibernox my goal is to make the process just a little simpler, even provide a dedicated place to perform said "mangling" :P In my project environment, all of our APIs use snake_case keys even for query params, so I have spent a lot of time camelCasing my keys to make things "prettier" for ember. I have done the same thing you described with many of my query and queryRecords, until I decided to dry up my code and make a couple custom methods. I figured maybe more people might find this PR convenient if they find themselves in similar use case |
|
@grapho What about overriding function camelCaseObject(obj) {
// camelCase here
}
export default Serializer.extend({
queryRecord(store, type, query) {
camelCaseObject(query);
return this._super(...arguments);
},
query(store, type, query) {
camelCaseObject(query);
return this._super(...arguments);
}
});Given that this doesn't enable any new feature, I'm just trying to balance if this significantly more convenient that what we have right now so it existence is justified. I don't know how the core team feels about increasing the API surface of the adapters. Even if this goes ahead, I think that the naming is a bit confusing, because |
|
Good points, @cibernox. I'll leave this open and see if any more opinions pop up.. if no one else seems interested, I can close. |
This is my first ever RFC. I hope it is good!
Let me know what you think!
https://github.com/grapho/rfcs/blob/build-query-rfc/new-build-query-adapter-api.md