* Add note that any controller reference is acceptable for `serialization_scope`
* Add note about `ActionController::API` and `view_context` set to `nil`, with respect to accessing helpers in a Serializer
* refs #2144
* Update CHANGELOG.md
If the `id` attribute for a class isn't taken directly from the object when
serializing it, it may be desirible for other classes that serialize a
relationship with that class to overwrite the relationship IDs they serialize.
For example, suppose we have:
```(ruby)
class Repo < Model
attributes :id, :github_id, :name
associations :configs
end
class Config < Model
attributes :id
belongs_to :repo
end
class RepoSerializer < ActiveModel::Serializer
attributes :id, :name
has_many :update_configs
def id
object.github_id
end
end
class ConfigSerializer < ActiveModel::Serializer
attributes :id
belongs_to :repo
end
```
In the above example, serializing a list of `Repo`s will give the `github_id`
for each one, but serializing a `Config` will give the `id` for its parent repo.
Ideally AMS would inspect the `RepoSerializer` when serializing the `Config`,
and realise it can't just output the foreign key. Unfortunately, getting the
serialization class for the child repo currently requires loading the record
(via evaluating `lazy_assocation`), and loses the performance benefit of the
existing `belongs_to?` path. Instead, I've opted to use
`read_attribute_for_serialization` instead of `object.send` to fetch the
serialized foreign key. This allows the serialized relationship ID to be
overwritten using
```(ruby)
class ConfigSerializer < ActiveModel::Serializer
...
def repo_id
object.repo.github_id
end
end
```
- Updating general/serializers.md
- Updating docs/general/rendering.md
- adding to changelog
- Updating rendering.md to indicate that `each_serializer` must be used on a collection
- updating my handle in previous changelog entry
Currently (2017-02-20) the latest version is 0.1.2.
Why not use a version constraint like '~> 0.1.1'? Because
we know of no reason why 0.1.1.beta1 cannot still be used.
That said, we have done no research looking for such a reason.
From the author of jsonapi:
> .. The jsonapi gem was previously just a bundle of jsonapi-serializer and jsonapi-renderer, and AMS is using only a helper class of jsonapi-renderer (namely JSONAPI::IncludeDirective). The AMS dependency was previously not properly pinned to a specific version, which I saw as a risk for many users, so I avoided updating this gem. Moreover, the name jsonapi being somewhat too generic for what this gem evolved into (namely jsonapi-rb, which bundles jsonapi-renderer and jsonapi-parser, along with serializers and deserializers, with tight integrations with various frameworks), I decided to stay away from it for fairness.
> TL;DR: Yes, people should use jsonapi-parser and jsonapi-renderer directly (or give a try to jsonapi-rb, depending on their needs).
We should also update jsonapi-renderer to the latest, currently 0.1.2, but I thought that should be a separate PR.
* Merge pull request #1990 from mxie/mx-result-typo
Fix typos and capitalization in Relationship Links docs [ci skip]
* Merge pull request #1992 from ojiry/bump_ruby_versions
Run tests by Ruby 2.2.6 and 2.3.3
* Merge pull request #1994 from bf4/promote_architecture
Promote important architecture description that answers a lot of questions we get
Conflicts:
docs/ARCHITECTURE.md
* Merge pull request #1999 from bf4/typos
Fix typos [ci skip]
* Merge pull request #2000 from berfarah/patch-1
Link to 0.10.3 tag instead of `master` branch
* Merge pull request #2007 from bf4/check_ci
Test was failing due to change in JSON exception message when parsing empty string
* Swap out KeyTransform for CaseTransform (#1993)
* delete KeyTransform, use CaseTransform
* added changelog
Conflicts:
CHANGELOG.md
* Merge pull request #2005 from kofronpi/support-ruby-2.4
Update jsonapi runtime dependency to 0.1.1.beta6
* Bump to v0.10.4
* Merge pull request #2018 from rails-api/bump_version
Bump to v0.10.4 [ci skip]
Conflicts:
CHANGELOG.md
* Merge pull request #2019 from bf4/fix_method_redefined_warning
Fix AMS warnings
* Merge pull request #2020 from bf4/silence_grape_warnings
Silence Grape warnings
* Merge pull request #2017 from bf4/remove_warnings
Fix mt6 assert_nil warnings
* Updated isolated tests to assert correct behavior. (#2010)
* Updated isolated tests to assert correct behavior.
* Added check to get unsafe params if rails version is great than 5
* Merge pull request #2012 from bf4/cleanup_isolated_jsonapi_renderer_tests_a_bit
Cleanup assertions in isolated jsonapi renderer tests a bit
* Add Model#attributes helper; make test attributes explicit
* Fix model attributes accessors
* Fix typos
* Randomize testing of compatibility layer against regressions
* Test bugfix
* Add CHANGELOG
* Merge pull request #1981 from groyoh/link_doc
Fix relationship links doc
Conflicts:
CHANGELOG.md
* This adds namespace lookup to serializer_for
* address rubocop issue
* address @bf4's feedback
* add docs
* update docs, add more tests
* apparently rails master doesn't have before filter
* try to address serializer cache issue between tests
* update cache for serializer lookup to include namespace in the key, and fix the tests for explicit namespace
* update docs, and use better cache key creation method
* update docs [ci skip]
* update docs [ci skip]
* add to changelog [ci skip]
For JSONAPI, `include_data` currently means, "should we populate the
'data'" key for this relationship. Current options are true/false.
This adds the `:if_sideloaded` option. This means "only
populate the 'data' key when we are sideloading this relationship." This
is because 'data' is often only relevant to sideloading, and causes a
database hit.
Addresses https://github.com/rails-api/active_model_serializers/issues/1555
If you specify include_data false, and do not have any links for this
relationship, we would output something like:
`{ relationships: { comments: {} } }`
This is not valid jsonapi. We will now render
`{ relationships: { comments: { meta: {} } } }`
Instead.
Relevant jsonapi spec: http://jsonapi.org/format/#document-resource-object-relationships
