Symfony 6 Certification New exam with updated questions 100% online Show your expertise

New in Symfony 5.4: Serializer improvements

Symfony 5.4 is backed by Private Packagist. Private Packagist is a fast, reliable, and secure Composer repository for your private packages. It mirrors all your open-source dependencies for better availability and monitors them for security vulnerabilities.

Symfony 5.4 was released yesterday, but we still have some blog posts pending to show its main new features. In this post we're highlighting the improvements added to the Serializer component.

Globally configured serializer context

Contributed by
Antoine Bluchet
in #38542.

The Serializer context controls the (de)serialization of resources. In current Symfony versions, this context is passed to all normalizers. In Symfony 5.4 we're improving the Serializer component configuration to allow you configure the default context globally. For example:

1
2
3
4
# config/packages/serializer.yaml
serializer:
    default_context:
        enable_max_depth: true

This example shows the YAML configuration, but you can also use XML and PHP.

Custom serializer for Symfony Messenger

Contributed by
Mathieu Santostefano
in #42257.

JSON-encoded messages consumed by Symfony Messenger are expected to have the following structure:

1
2
3
4
5
6
{
    "message": {
        "body": {},
        "headers": []
    }
}

However, when consuming messages generated by different third-parties, you won't get that message structure. That's why in Symfony 5.4 you can use your own serializer to JSON-decode messages.

Collect Denormalization Type Errors

Contributed by
Grégoire Pineau
in #42502.

In previous Serializer versions, when using typed PHP properties you could see errors in certain situations. For example, consider the following simple DTO:

1
2
3
4
5
6
class MyDto
{
    public string $property1;
    public int $property2;
    public array $property3;
}

If your JSON data is like the following:

1
2
3
4
5
{
    "property1": null,
    "property2": 7,
    "property3": []
}

When trying to deserialize that data you'll see a 500 error because the type of property1 is string and you're passing a null value. In Symfony 5.4 we've improved this behavior thanks to the new COLLECT_DENORMALIZATION_ERRORS option.

If you pass that option, the PHP exception will include the detailed list of errors. Then you can process it like in the following example that handles some API:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#[Route('/api', methods:['POST'])]
public function apiPost(SerializerInterface $serializer, Request $request): Response
{
    try {
       $dto = $serializer->deserialize($request->getContent(), MyDto::class, 'json', [
            DenormalizerInterface::COLLECT_DENORMALIZATION_ERRORS => true,
        ]);
    } catch (PartialDenormalizationException $e) {
        $violations = new ConstraintViolationList();
        /** @var NotNormalizableValueException */
        foreach ($e->getErrors() as $exception) {
            $message = sprintf('The type must be one of "%s" ("%s" given).', implode(', ', $exception->getExpectedTypes()), $exception->getCurrentType());
            $parameters = [];
            if ($exception->canUseMessageForUser()) {
                $parameters['hint'] = $exception->getMessage();
            }
            $violations->add(new ConstraintViolation($message, '', $parameters, null, $exception->getPath(), null));
        };

        return $this->json($violations, 400);
    }

    return $this->json($dto);
}
Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.

Comments

Call me old-fashion but, validate($rawPayload); deserialize($rawPayload, TypedDto::class) works for me.
Thanks Grégoire! Once again you add things to improve DX on Symfony new project bootstrap to avoid doing same things again and again from one app to another.
@Roland Franssen completely agree with you when you control the deserialization logic, however this errors collection feature is amazing in the context of API Platform where serialization is done first, and validation second on instantiated DTOs. In this case, I think it will help the API Platform community to do great things :)
To all reading, "validation before hydration" benefits object design :)
Login with SymfonyConnect to post a comment