* The link was already there but I skipped over it on my first read.
This update makes the fact more prominent.
* I was testing to see if we wanted to move from AM Serializers to
fast_jsonapi but our API is not written according to the JSON:API spec
so, after converting one serializer over, I learned that this would not work for me.
* This update might save someone in my position the ~30 mins or so it
takes to bundle and write a serializer in the future. :)
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.
