Skip to content

Conversation

janetruluck
Copy link

This is to maintain the functionality of render :json as noted in the docs

This functionality used to exist in v0.8.1. This adds the ability to
pass other options that will be usable in the serializer via the
options accessor.

This works by adding an attr_accessor for options so it is available
and is set by the remaining options in the provided options hash during
initialization.

Fix #446

Please let me know what you think!

Cheers
-Jason

…ender :json as noted in the docs

This functionality used to exist in v0.8.1. This adds the ability to
pass other options that will be usable in the serializer via the
options accessor.

This works by adding an attr_accessor for options so it is available
and is set by the remaining options in the provided options hash during
initialization.
@tonywok
Copy link

tonywok commented Nov 26, 2013

Running into this as well. Is there a preferred way to do this now on 0.9.x? Otherwise, +1

spastorino added a commit that referenced this pull request Nov 28, 2013
Add @options back into serializers for passing custom options
@spastorino spastorino merged commit c65ac37 into rails-api:master Nov 28, 2013
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this in incur an Array allocation on every loop through the @options list or would extracting that out to a constant be too much of a micro-optimization?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nixme it definitely does. I wrote up a quick benchmark script to test the two methods very simply at https://gist.github.com/jasontruluck/7722888 . From the results I would say for an average use case it is negligible. At n=10 results list there is almost no discernible difference and even at 1,000,000 items is only fractions of a second. That being said, moving this out into a constant is a super easy change that can be made very easily. So even though I would consider it a micro-optimization there is no real harm in it to me, but I would like to differ to @spastorino as to whether this change is worth a PR or not.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can do the PR if @spastorino think's it's worth it. Thanks for running the numbers!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem at all!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 let's move this into a constant

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

naming it properly would also express better the intention

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unable to see any @options

4 participants