Custom serializer [Feature] about ngactiveresource HOT 15 CLOSED

What I've done in production is to use a custom $http interceptor to return the data as expected. This would be fairly easy to implement as part of the library though, too. If you're interested in working on it, you'd want to look at the query methods, and alter them to use a strategy pattern that would allow you to set a function to process this data. Basically just create a join point in those functions that can be tapped into. I think it's a cool idea.

from ngactiveresource.

If I get a chance at work I'll make a start on this today :)

from ngactiveresource.

Sorry I didn't get a chance to look into this, had a massive workload today.

Maybe you could brief me on the general flow of a request / response so I can get a better understanding of what I'll need to do (and reduce the possibility of mistakes).

I did manage to get what I wanted using a custom $http interceptor like you said, thanks.

from ngactiveresource.

Surely; I apologize it's hard to read at the moment. I'm in the process of re-writing the lib into smaller, more reusable components so it should be easier to go through in the future. I think this may actually be simpler than I even initially told you--all the API methods make their $http requests, get a response (in only JSON currently), and then call deserialize on it (that's the part you should be concerned with).

Deserialize has the job of finding the resources on that JSON and turning them into objects. It actually looks to me right now like I was already handling for a nested data attribute (since it's such a common occurrence), but clearly something isn't working properly there. Deserialize then passes the JSON off to other methods to handle object creation, and possibly making other requests for related resources, if applicable.

So it seems the join point would be in that deserialize method; you could pass the user the JSON and let them handle it, assume they've done it correctly, and then hand it off. If they don't specify any deserialization methods, we can fall back on the default ones. Does that make sense?

from ngactiveresource.

Yea that helps thanks. Obviously you can assume the developer has a better understanding of their response structure. I'll have another dig around at some point today, hopefully I can get a PR setup some point this week as it doesn't sound like a big job.

from ngactiveresource.

It actually looks to me right now like I was already handling for a nested data attribute (since it's such a common occurrence), but clearly something isn't working properly there.

If you're referring to if (httpResponse && httpResponse.data) I don't think it's working because httpResponse is only a part of the actual response. At least when deserializing a collection. The loop means if the resource follows, for example, the following structure:

{
  "data": [ /* Collection of resources */ ],
  "embeds": []
}

The serializer will actually receive data and embeds before it gets a chance to deserialize the data.

from ngactiveresource.

As it stands the deserialize method handles more than I think it should (setAssociationsAndUpdate & updateLocalInstance). Ideally it should receive the data, restructure it and give it back to be transformed into a instance.

Any chance these method calls can be moved into an event listener or something outside the deserialize method?

--- EDIT

If I create two new functions parseResource and parseCollection will that make sense? That way deserialize can continue to handle to creation of the objects while the parse functions will be responsible to transforming the response before it's converted.

from ngactiveresource.

That sounds good. Send a PR when you're ready :)

from ngactiveresource.

I'm one step closer to completing this feature however as it stands you can only define one response parser, which suites me because all my requests follow a styleguide but others are likely to want different parsers for different APIs. Therefore I'm currently looking into a minor alteration on what was originally proposed.

If there is a collection of parsers that can be matched to a specific url like http://localhost:8000/api/dashboards/:id. Then if showURL matches that pattern it will be used instead of the default which simply returns the unmodified httpResponse object.

What do you think? Are there any major caveats to the plan that aren't obvious to me? Or is there a simpler way to match parsers to responses that I haven't seen?

from ngactiveresource.

@brayniverse Any chance you can commit the code for the one response parser to your repo? My data is formatted in the same exact way with 'data' and 'meta' at the top level, where data is an array of objects.

from ngactiveresource.

That makes sense to me, @brayniverse

from ngactiveresource.

@brayniverse Any status updates on this issue?

from ngactiveresource.

@brayniverse We're all counting on you.

from ngactiveresource.

@brayniverse Are you still working on this issue? I might start work on my own to get this to work otherwise.

from ngactiveresource.

@jonkoops I had a very busy period at work and lost track of this project. You're more than welcome to take this issue over and develop it yourself.

from ngactiveresource.