-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Serializer documentation can be improved (possibly contains an error?) #2280
Description
2 part question, both relating to (Symfony) Serializer docs.
1:
The Serializer docs show an example of decorating the json-ld normalizer to add a few fields, but wouldn't a completely custom serializer be better so the getSupportedTypes can be used to efficiently decide if this serializer should be used instead of having 20,30, maybe 100s of services decorating the json-ld normalizer and it having to go through all those layers with like if (!$data instanceof ...) or if (!is_a($type, SomeClass::class, true))
Should we add an example for a cache-able/scalable solution that doesn't involve decorating the json-ld one?
2:
Then looking at the example code here:
https://api-platform.com/docs/core/serialization/#changing-the-serialization-context-on-a-per-item-basis-for-symfony
Specifically:
public function supportsNormalization($data, $format = null, array $context = [])
{
// Make sure we're not called twice
if (isset($context[self::ALREADY_CALLED])) {
return false;
}
return $data instanceof Book;
}
public function getSupportedTypes(?string $format): array
{
return [
Book::class => true
];
}Returning true on getSupportedTypes means the usage of the serializer gets cached, and the supportsNormalization method is only checked once, then never again. So adding the self::ALREADY_CALLED in the normalize method doesn't do anything,... next time it goes through this normalizer, the supportsNormalization is skipped and boom, it now executed normalize on an item that has possibly already gone through it?
I can contribute a change for both things, but would like to get a second opinion first to see if I'm maybe missing something.