Composability question

[aviemet]

Firstly, thanks for your work on this, it looks pretty great and very performant.

I'm hoping you could expand on the composability section of the readme. I'm confused about the use of flat_one, particularly the first argument, which I can't seem to tell what it does. Actually, I just found the method in source and now I understand.

Also wondering if you have any suggestions for creating seralizers which would change slightly for each view. For instance, if I have an Articles model, I would likely want to send all fields and all associations to the "show" view, but I might only need to send the title and body fields to an "edit" view.

Thank you

[ElMassimo]

Hi Avram!

any suggestions for creating seralizers which would change slightly for each view

Typically the way I like to structure them, is to create one serializer per "use case".

For example, you might have a lighter serializer for an index page, and a serializer with more info for a show page.

Because serializers should not typically contain business logic, unless the difference is very simple, I'd typically avoid using inheritance and specify the full list of attributes that are needed upfront.

The benefit of that, is that adding more attributes to one "endpoint" does not accidentally add that unnecessarily to other endpoints, which can be hard to notice (and could affect performance indirectly via additional queries).

class SongIndexSerializer < BaseSerializer
  attributes(
    :id,
    :title,
  )
end

class SongDetailsSerializer < BaseSerializer
  attributes(
    :id,
    :title,
  )

  has_one :composer, serializer: ComposerSerializer

  has_many :video_clips, as: :videos, serializer: VideoSerializer
end

Although at first this seems like "a lot of duplication", in most cases it doesn't have any downsides, and in the long term it simplifies maintenance and refactoring, and prevents accidental breakage. Having different classes makes usages easier to find, and the code is easier to reason about (what you see is what you get).

---

However, just to illustrate what you can do in cases where the data should be "shared":

class SongSerializer < BaseSerializer
  attributes(
    :id,
    :title,
  )

  has_one :composer, serializer: ComposerSerializer

  has_many :video_clips, as: :videos, serializer: VideoSerializer, if: ->{ options[:include_videos] }
end

SongSerializer.one(song, include_videos: true)

You could use this same pattern with if and flat_one to create "views":

class SongSerializer < BaseSerializer
  attributes(
    :id,
    :title,
  )

  class Detailed < BaseSerializer
    has_one :composer, serializer: ComposerSerializer
    has_many :video_clips, as: :videos, serializer: VideoSerializer
  end

  flat_one :song, serializer: Detailed, if: -> { options[:view] == :detailed }
end

SongSerializer.one(song, view: :detailed)

In the future I might add this as a built-in views feature, but as I mentioned above, this style has certain downsides from a maintainability point of view, and I'm not sure I'd like to "encourage it".

[aviemet]

Yes, that makes sense, and is actually the route I was about to take. I'm testing this as a replacement for Blueprinter since it can automatically generate the typescript types for my Inertia project. My solution with Blueprinter was to add extra functions to my base class which allowed me to exclude fields. In this way, I essentially was able to define a main "blueprint" for each model with all possible fields, and then using views, exclude fields which weren't relevant. I imagine this approach would add overhead, so not sure if that's a route worth going down.

I'm considering namespacing them by putting the serializers in a directory per model, so with your example above, have a directory at app/serializers/songs with files called index_serializer.rb and show_serializer.rb. Then in the controller I could call Songs::IndexSerializer.many(songs) and Songs::ShowSerializer(song).

Thank you very much for suggestions and examples.

[ElMassimo]

I like the views approach in Blueprinter, and it would be simple to implement internally using mixins and conditional flat_one.

What I'm still deciding is how to model the generated types in a way that is still intuitive to use in the frontend.

---

Regarding your approach to namespace by models, that should give nice results (i.e. SongIndex and SongShow), and provides a convention that is easy to follow 👍