Serializer documentation can be improved (possibly contains an error?)

从 Symfony Serializer 文档页面开始，重点查看按项目更改序列化上下文的部分及其 decorator 示例。验证 getSupportedTypes 的缓存行为，并将其与提议的可扩展替代方案进行比较；当两个示例在技术上都正确，并且文档清楚说明何时使用每种方法时，即视为完成。

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.