Found myself trying to find out a way to specify associations on the serializer level, and realized it wasn't supported. Here's a first pass at implementing that functionality.
For some extra background, my use case was the following:
I have a resource that references objects of the same class OR subclasses. But for the serialization, I want them to be all serialized the same way:
Something along these lines
# Directory has several subclasses, but when I serialize a directory, I want all `parent_directory` and `child_directories` to be serialized as if they were just a regular "directory"
class Directory
attr_accessor :parent_directory
attr_accessor :child_directories
attr_accessor :parition
end
class Parition < Directory
end
And this is what I wanted to be able to do:
class DirectorySerializer
has_one :parent_directory, serializer: DirectorySerializer
has_many :child_directories, serializer: DirectorySerializer
has_one :partition, serializer: PartitionSerializer
end
The changes in this PR enable this kind of configuration.
Looking through the code, I realized that we're always passing the options passed to the serializer for the main resource to all the included associations. Instead with this PR, we are passing the association options.
There was one main issue highlighted by the tests, and I am not sure that my fix is in line with what the maintainers of this project want. Basically, if a resource is serialized twice (as the main resource and in the under the included key), with my change the one in the included resource doesn't get the customization options from the serialization of the root resource.
I think it makes sense. Please let me know if you disagree.
I would actually argue that it would be safer to require each association to explicitly specify the serializer instead of having the serializer infer from the object class. But that may not be a very popular opinion.
Found myself trying to find out a way to specify associations on the serializer level, and realized it wasn't supported. Here's a first pass at implementing that functionality.
For some extra background, my use case was the following:
I have a resource that references objects of the same class OR subclasses. But for the serialization, I want them to be all serialized the same way:
Something along these lines
And this is what I wanted to be able to do:
The changes in this PR enable this kind of configuration.
Looking through the code, I realized that we're always passing the
options
passed to the serializer for the main resource to all theincluded
associations. Instead with this PR, we are passing the association options.There was one main issue highlighted by the tests, and I am not sure that my fix is in line with what the maintainers of this project want. Basically, if a resource is serialized twice (as the main resource and in the under the
included
key), with my change the one in theincluded
resource doesn't get the customization options from the serialization of the root resource.I think it makes sense. Please let me know if you disagree.
I would actually argue that it would be safer to require each association to explicitly specify the serializer instead of having the serializer infer from the object class. But that may not be a very popular opinion.