Serializer default groups

[kingschnulli]

Let's say I have an entity Book:

/**
 * @ApiResource()
 */
class Book
{
    /**
     * @Groups({"read", "write"})
     */
    public $name;

    /**
     * @Groups("write")
     */
    public $author;

    /**
     * This property has no groups
     */
    public $foo;

    // ...
}

What I'm trying to achieve now is to serialize the $foo property, regardless of the current context groups. Is there some way to configure some kind of "default group" for properties where no group was given?

I know I could just add the group to my property, but I was hoping to configure something (or decorate something) so the serializer will return the property $foo.

TLDR: How can I define a default group for all properties? Is this already possible or might be a new feature?

[noemi-salaun]

I think this issue could be reopened. I don't think @kingschnulli was talking about a context group that serialize everything, like the *, but a default group that serialize only properties that don't have a group. Like the Default group with JMS Serializer.

See https://jmsyst.com/libs/serializer/master/cookbook/exclusion_strategies#creating-different-views-of-your-objects

Any property without an explicit @groups annotation will be included in a Default group, which can be used when specifying groups in the serialization context.

@fabpot should I create a new issue or can this one be reopened ?

[noemi-salaun]

Thanks. I already have a working POC that use a null context group.

I don't know what could be the best option to reduce the BC break.

• A special char, like for the *. Could be _. (not a fan of this solution)
• A special word, like Default in the JMS Serializer (high chance of BC breaks with existing project)
• The null value
• The empty string value

null or empty string value cannot be use in @Groups annotation, so we are sure there is no BC break with this solution

[kingschnulli]

I think this issue could be reopened. I don't think @kingschnulli was talking about a context group that serialize everything, like the *, but a default group that serialize only properties that don't have a group. Like the Default group with JMS Serializer.

This is exactly what I was talking about, makes it way easier to integrate into existing code bases.

[ninsuo]

Another example if it can help people understand the purpose of this feature:

Currently, I am using 3 classes to handle common and r/w operations:

• Profile which contain "nickname",
• ProfileRead which extends Profile and adds $pictureUrl without groups
• ProfileWrite which extends Profile and adds $picture without groups

With a default group, everything could be simplified to a single class:

<?php

namespace App\DTO\Account;

use App\API\Model\File;
use Symfony\Component\Serializer\Annotation\Groups;
use Symfony\Component\Validator\Constraints\Image;
use Symfony\Component\Validator\Constraints\Length;
use Symfony\Component\Validator\Constraints\Valid;

class Profile
{
    /** User's nickname */
    #[Length(max: 64)]
    public ?string $nickname = null;

    /** Profile picture's URL */
    #[Groups("read")]
    public ?string $pictureUrl = null;

    /** Profile picture update */
    #[Image(maxSize: '1M', detectCorrupted: true)]
    #[Valid]
    #[Groups("write")]
    public ?File $picture = null;
}

[TerjeBr]

Any progress on this? @noemi-salaun seems to have provided a PR, but that seems to have stopped?

[sergey-kravchenk0]

Any progress on this? @noemi-salaun seems to have provided a PR, but that seems to have stopped?

@TerjeBr , as I can see, you can use the special char * as a default group.

[TerjeBr]

@sergey-kravchenk0 I do not think * will do what we want.

Let's say you have 7 properties on a class, and 2 of them has group annotation "cat" and 1 has group annotation "dog" and 4 has no group annotation. Then I want to serialize an object of that class, and I want what is in group "cat" and also what has no group annotation, but not what is in group "dog". As I have understood it if I specify * I will get everything, but I do not want that because I do not want what is in group "dog". That is why we want a default group, so we can say we want "cat" + "Default" and then I get the 4 properties that had no group annotation plus the two in the "cat" group.

[sergey-kravchenk0]

@TerjeBr I see, you are right, now there is no way to define the "Default" group. The only solution is to explicitly define the "Default" group for properties.

[carsonbot]

Thank you for this suggestion.
There has not been a lot of activity here for a while. Would you still like to see this feature?

[ninsuo]

Ohh yes!

[kadet1090]

I've created workaround for this issue by decorating the \Symfony\Component\Serializer\Mapping\Loader\LoaderInterface class:

<?php

namespace App\Serialization;

use Symfony\Component\Serializer\Mapping\ClassMetadataInterface;
use Symfony\Component\Serializer\Mapping\Loader\LoaderInterface;

class MetadataLoader implements LoaderInterface
{
    public function __construct(
        private readonly LoaderInterface $decorated
    ) {
    }

    public function loadClassMetadata(ClassMetadataInterface $classMetadata)
    {
        $loaded = $this->decorated->loadClassMetadata($classMetadata);

        foreach ($classMetadata->getAttributesMetadata() as $attributeMetadata) {
            if (empty($attributeMetadata->getGroups())) {
                $attributeMetadata->addGroup('default');
            }
        }

        return $loaded;
    }
}

services.yaml:

  App\Serialization\MetadataLoader:
    decorates: 'serializer.mapping.chain_loader'

Now if you apply the default group by default in the default context it should work as mentioned. I did that in Symfony 5.4, and don't know if it works in any other versions.

[carsonbot]

Thank you for this suggestion.
There has not been a lot of activity here for a while. Would you still like to see this feature?

[noemi-salaun]

Keep it open please. There is also a PR for it already

[mtarld]

Hey! I tried a different approach to solve the issue in this PR: #51514

[TerjeBr]

Should this be closed, since #51514 has been merged?

[mtarld]

Yes, I think it can be 🙂 (when it'll be merged)

[nicolas-grekas]

#51514 has not been merged yet