* fix(ObjectSerializer): pass to_json arguments
to_json takes arguments that serialized_json did not define. This breaks a lot of things.
* Update CHANGELOG.md with latest fix and release
- Very explicit where caching is stored
- No `Rails.cache` automagic with possible colliding keys
- Rails 5.2+ cache versioning support
- Implicit namespace support (by cache instance, e.g.
ActiveSupport::Cache::MemoryStore.new(namespace: 'jast_jsonapi')
- All cache instance options are supported
* allow the relationship's serializer key to be a Proc
* fixes
* specifically test the relationship name and the resource type
* support object blocks without a serializer defined
* stop validation gracefully if the relationship is polymorphic
* improve performance by using instance variables instead of accessor methods
* force initialization up front to avoid the iterative calls
* serializer procs should act like polymorphic when determining the id_method_name
* specs for serializer procs
* updated with more details and examples for relationship serializer options
* adjust specs to define the serializers
* avoid extra method calls for performance
* name change
* one less function call for better performance
* do not require lazy loaded relationships to resolve the serializer
* give polymorphic precedence for backwards compatibility
* move serializer inference into ObjectSerializer to allow for overriding
* move method for better diff
* fix race condition in multi-threaded environments
* Add params to set_id block arguments
Pull request #331 added a block to the ObjectSerializer.set_id class
method, which allows passing a block to the set_id method. Currently
this block takes only one argument `record`:
```
set_id do |record|
"#{record.name.downcase}-#{record.id}"
end
```
This PR adds another argument `params` to the block:
```
set id do |record, params|
params[:admin] ? record.id : "#{record.name.downcase}-#{record.id}"
end
```
This customization can be useful in situation where we serve different
clients that may need different IDs. One nice side effect is also that
the `set_id` method has the same method signature as the `attribute`
method.
* Update the README
Allow an ID of object to be customized directly on the serializer by
passing a block to `set_id` as opposed to only through a model property.
We already allow for attributes that do not have a model property of the
same name to be customized directly on the serializer using a block.
This customization can be useful in situation in which you have
different classes being serialized using the same serializer. For
example, if we have `HorrorMovie`, `ComedyMovie` and `DramaMovie` using
the same `MovieSerializer`, we can unify their IDs using
```
class MovieSerializer
include FastJsonapi::ObjectSerializer
attributes :name, :year
set_id do |record|
"#{record.name.downcase}-#{record.id}"
end
```
which is preferable to creating a `#serialized_id` method in every model
that will use `MovieSerializer` to encapsulate the customization.
Closes#315
If you include a default empty `data` option in your JSON API response,
many frontend frameworks will ignore your `related` link that could be
used to load relationship records, and will instead treat the
relationship as empty.
This adds a `lazy_load_data` option which will:
* stop the serializer attempting to load the data and;
* exclude the `data` key from the final response
This allows you to lazy load a JSON API relationship.
Core extensions do not play well with many other gems; especially
considering that they only seem to be included for one `to_json` call,
they should be avoided.
If you forgot to set any `has_many` in the serializer and tried to serialize with an `include` you would get:
```
NoMethodError (undefined method `[]' for nil:NilClass):
```
That is not very helpful. Setting the variable with a default case makes sure the right error message gets displayed.
