fix(theme): stop duplicating branch properties in nested anyOf/oneOf renders#1549
Merged
Merged
Conversation
|
Size Change: 0 B Total Size: 2.36 MB ℹ️ View Unchanged
|
|
Visit the preview URL for this PR (updated for commit cdff976): https://docusaurus-openapi-36b86--pr1549-yyuij7om.web.app (expires Fri, 17 Jul 2026 18:28:36 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: bf293780ee827f578864d92193b8c2866acd459f |
…renders
When an outer schema shapes as `{properties, anyOf: [{oneOf: [...]}, ...]}`,
`foldSiblingsIntoBranches` merges the outer properties into each anyOf
branch, giving each branch its own inner `oneOf` alongside merged
properties. AnyOneOf then delegates that branch to SchemaNode, which
folds *again* into each inner variant — but AnyOneOf was also rendering
<Properties> directly for the branch, so the merged fields showed up
twice per selected inner variant tab.
Gate the direct <Properties> render on the branch having no nested
oneOf/anyOf/allOf. When a nested composition is present, the delegated
SchemaNode already folds those properties into every variant, so
rendering them inline as well is redundant.
Repro (see demo `/tests/any-of-with-nested-one-of-and-properties`):
the ethernet-interfaces-style shape rendered `name`, `default_value`,
etc. once at the outer object tab and again inside each aggregate_group
/ tap / layer2 / layer3 variant tab. After the fix each field appears
exactly once — inside the variant tab where the merge lives.
Regression covered by a Jest test asserting that a two-level fold
(outer anyOf branch, inner oneOf variant) leaves the merged
properties on the innermost variant only, matching the invariant the
render layer now relies on.
sserrata
force-pushed
the
fix-anyof-nested-oneof-property-duplication
branch
from
0d29cad to
cdff976
Compare
📸 Visual Diff ReportSnapshot comparison against https://docusaurus-openapi.tryingpan.dev/
❌ 1 page(s) with visual regressions
|
| Prod | Preview | Diff |
 |
 |
 |
Updated at 2026-07-10T18:36:03.074Z · run 29114452272
This was referenced Jul 10, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When an outer schema shapes as
{properties, anyOf: [{oneOf: [...]}, ...]},foldSiblingsIntoBranchesmerges the outer properties into each anyOf branch, giving each branch its own inneroneOfalongside merged properties.AnyOneOfthen delegates that branch toSchemaNode, which folds again into each inner variant — butAnyOneOfwas also rendering<Properties>directly for the branch, so the merged fields showed up twice per selected inner variant tab.Gate the direct
<Properties>render on the branch having no nestedoneOf/anyOf/allOf. When a nested composition is present, the delegatedSchemaNodealready folds those properties into every variant, so rendering them inline as well is redundant.Repro
Downstream discovered by pan.dev PR #1342 on the
POST /ethernet-interfacesrequest schema. The spec shape:Before this fix:
name,default_value,comment,link_speed, … render once at the outerobjecttab and again inside eachaggregate_group/tap/layer2/layer3variant tab.After this fix: each field appears exactly once — inside the variant tab where the merge lives, matching pre-5.1.0 behavior.
The existing demo fixture
/tests/any-of-with-nested-one-of-and-properties(added indemo/examples/tests/anyOf.yaml) exercises this exact shape and demonstrates the fix visually on the demo site.Test plan
yarn jest packages/docusaurus-theme-openapi-docs/src/theme/Schema/normalize.test.ts— all 30 tests pass, including the new regression test that documents the two-level fold invariant the render layer relies on.yarn buildin the demo — clean./tests/any-of-with-nested-one-of-and-properties: base properties should render once per variant tab, not twice.Fixes the duplication observed in PaloAltoNetworks/pan.dev#1342.
🤖 Generated with Claude Code