Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic lookup within Rails controllers #175

Open
dillonwelch opened this issue Apr 19, 2018 · 6 comments
Open

Automatic lookup within Rails controllers #175

dillonwelch opened this issue Apr 19, 2018 · 6 comments
Labels
enhancement New feature or request

Comments

@dillonwelch
Copy link
Contributor

If I do something like render json: model, when I'm using AMS it automatically detects ModelSerializer but when I'm switching over to fast_jsonapi it doesn't seem to have that same magic. Am I messing something up or is that not a feature of this gem?

P.S. Overall love the gem and the philosophy, thanks for open sourcing this.

@shishirmk
Copy link
Collaborator

Yes this is not automatic yet. However #89 and other pull requests have made it a bit less verbose.

This should work

render json: WidgetSerializer.new(widget)

@shishirmk shishirmk added the enhancement New feature or request label Apr 22, 2018
@guilleiguaran
Copy link
Contributor

I have a PR to add this ready but I'm a bit concerned about causing conflicts with AMS (I imagine that there are projects using both libraries simultaneously)

WDYT about using:

render jsonapi: model

To avoid conflicts with json renderer overrided by AMS?

@dillonwelch
Copy link
Contributor Author

That doesn't seem necessary, as I feel like it should use the model name to load the appropriate serializer and that serializer would define whether it's using AMS or fast_jsonapi via what it's inheriting from/what it includes.

One thought - are you're saying that people have a model being serialized by both gems in different controllers/actions?

@guilleiguaran
Copy link
Contributor

@oniofchaos AMS right now is overriding ActionController::Renderers internal private methods making a bit hard your proposal.

To use :json and keep the compatibility with AMS we will need to detect if AMS is in the project and override again the methods that it's overriding to make them aware of fast_jsonapi serializers and have another code path to override the default JSON renderer if AMS is not present in the project. It can be done but it'll be "hacky" in my opinion.

One thought - are you're saying that people have a model being serialized by both gems in different controllers/actions?

I'm talking about people using AMS for some models and fast_jsonapi for other models, I think that is the case for some people looking to improving the performance in some serializers without having to migrate a whole existing project to fast_jsonapi.

@c0ze
Copy link

c0ze commented Aug 22, 2018

Just want to add a thumbs up to this.

Yes this is not automatic yet. However #89 and other pull requests have made it a bit less verbose.

This should work

render json: WidgetSerializer.new(widget)

Yes, it works, how about serializing an Array ?

It would be great if fast_json could detect models inside an array and serialize properly & automagically.

EDIT: Answering my question, if you pass an array it will serialize automatically. What got me was that you have to explicitly cast the AR relation to array.

   render json: WidgetSerializer.new(Widget.all.to_a)

@stas
Copy link
Contributor

stas commented Jan 14, 2019

I started a little project to help integrate fast_jsonapi with rails/.

To be honest, I'm not sure how much of the JSONAPI spec fast_jsonapi want's to include. While working on the renderer side it's kinda clear that it's not just the serializer lookup support that needs to be provided, it's also the error handling/rendering support and the error serializers (#102) that should available.

Consider this, as an example implementation:
https://github.com/stas/jsonapi.rb/blob/master/lib/jsonapi/rails.rb#L28-L100

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants