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
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
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
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);
}
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 :)