Serializer documentation can be improved (possibly contains an error?)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- php, symfony
- Domain
- documentation
Research direction
Start with the Symfony Serializer documentation page, especially the section on changing the serialization context per item and its decorator example. Verify the getSupportedTypes caching behavior and compare it with the proposed scalable alternative; done means both examples are technically correct and the documentation clearly explains when to use each approach.
Written by the indexing model from the issue text.
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.
- Dominant language
- No language data
- Stars
- 181
- Forks
- 1.1k
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 24
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from api-platform/docs
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
api-platform/docs#2284 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
api-platform/docs#2318 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
api-platform/docs#2310 ·
-
Needs Work
Difficulty 4/5 3-5 days Newbie friendliness 35/100
api-platform/docs#2133 · 9 comments · 1 reaction ·
-
good first issue
Difficulty 1/5 Under an hour Newbie friendliness 58/100
api-platform/docs#1450 · 2 comments ·
All issues in api-platform/docs
Similar issues
-
Area: Excel support
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
orbeon/orbeon-forms#7893 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
docToolchain/docToolchain#1705 ·
-
kb-infra-drift
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
OCHA-DAP/ds-knowledge-base#653 · 1 comment ·
-
area/dev-productivity area/disaster-recovery area/ipcei kind/enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
namespace operations
Difficulty 1/5 Under an hour Newbie friendliness 90/100
EclipseFdn/open-vsx.org#13419 ·