-
Notifications
You must be signed in to change notification settings - Fork 178
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
Support JSON serialize #196
base: master
Are you sure you want to change the base?
Conversation
If it use active hash with web api responses, `as_json` behavior is different between active hash's instance and active model's instance. ``` 1) ActiveHash Base #as_json returns a hash Failure/Error: expect(country.as_json).to eq({"id" => 1, "name" => "US", "language" => "English"}) expected: {"id"=>1, "name"=>"US", "language"=>"English"} got: {"attributes"=>{"id"=>1, "name"=>"US", "language"=>"English"}} ``` We don't need `attributes` route key. If it includes `ActiveModel::Serializers::JSON`, behavior of active hash's instance would be as same as a behavior active model's instance. Thanks :)
d393d3f
to
faa6f84
Compare
|
||
it "returns a hash" do | ||
country = Country.find(1) | ||
expect(country.as_json.stringify_keys).to eq({"id" => 1, "name" => "US", "language" => "English"}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rails 6.0 or later returns stringified keys hash, but Rails 5.2 or earlier returns symbolized keys hash. So I used stringify_keys
method.
This PR doesn't solve the underlying issue; namely that Even with this PR, the Country.find(1).as_json
=> { id: 1, name: "US", .. }
Country.find(1).as_json(only: [:name])
=> {} # Huh!? |
@pfeiffer Thanks for the comment. Let me check it. |
ActiveHash's attributes are converted to symbolized keys in its constructor. But in ActiveModel::Serialization: I consider a better solution. If you have an idea, let me know how resolve it. Thanks. |
I think way to solve this is to migrate to having keys as strings in the # ActiveRecord
class User < ApplicationRecord; end
User.find(1).attributes
# => { "id" => 1, "name": "John", ... }
# ActiveModel
class Product
include ActiveModel::Attributes
attribute :sku, :string
end
Product.new(sku: "red_shirt").attributes
# => { "sku": "red_shirt" } It's however a breaking change, since the keys of If needed, a potential migration path would be to store keys as strings with What do you and @zilkey think? |
What about sort of a parallel track?
We'd created a 3.x.x branch here, and can release changes on both for a little while. Any reason to not do this? |
Sounds like a great plan! Happy to contribute if needed :-) |
Looking back over this. I think you can manually add this to each of your models to gain this functionality. include ActiveModel::Serializers::JSON Looks like this lost steam. I'm not sure if there is desire to get this in and beak compatibility. |
kicking this build |
No the issue would still be here. The issue is that |
@pfeiffer ugh. you had already clearly stated the problem. sorry about that. Are the 2 branches going to be that much different? |
@pfeiffer Sorry for lag on this one. (going over unresolved PRs) So if we want this fixed we need to break compatibility and store strings as keys? But looking at #310, it seems like at least Just thinking out loud: And visiting the source for |
If it use active hash with web api responses,
as_json
behavior is different between active hash's instance and active model's instance.We don't need
attributes
route key.If it includes
ActiveModel::Serializers::JSON
, behavior of active hash's instance would be as same as a behavior active model's instance.Thanks :)
The reason to need this change
ActiveModel::Serializers::JSON
module to all active hash's models.