Nested and sibling oneOf's

[max-kahnt-keylight]

Hi! 👋

Firstly, thanks for your work on this project! 🙂

Today I used patch-package to patch docusaurus-theme-openapi-docs@4.7.1 for the project I'm working on.

The current implementation does not handle some of my configurations gracefully,
in particular this abstract setting

 allOf:
   - $ref: CommonProps.yaml
   - oneOf:
       - TypeA
       - TypeB
       - TypeC
      discriminator:
        propertyName: type
      mapping:
        type-a: TypeA
        type-b: TypeB

title: TypeA
allOf:
  - $ref: CommonTypeProps.yaml 
  - oneOf:
    - Mode1
    - Mode2
    discriminator
      propertyName: mode
    mapping:
      mode-1: Mode1
      mode-2: Mode2

title: TypeB
allOf:
  - $ref: CommonTypeProps.yaml 
  - oneOf:
    - Mode3
    - Mode4
    discriminator
      propertyName: mode
    mapping:
      mode-3: Mode3
      mode-4: Mode4
  
title: TypeC
oneOf: 
  - Mode1
  - Mode2
discriminator
  propertyName: mode
mapping:
  mode-1: Mode1
  mode-2: Mode2

(I am willing to update this abstract example to something more concrete if there is interest in it.)

For the outer allOf, the discriminator is disregarded by the current implementation since it is nested.
For the inner oneOf, the propertyName produces an error since the property definition is nested.

The respective resolution of oneOf use-cases appears to be very inconsistent to me.
I don't understand why discriminators nested in allOf constructs are handled any differently than plain ones? Merging the schemas unconditionally beforehand fixed the issue for my specific use-case.
Why do discriminated and non-discriminated oneOf's have signifiantly different render paths? Shouldn't they only differ in how the "rendered discriminator" either uses the explicit discriminator (hint) or some defaults extracted from the oneOf contributions instead while coinciding for all subsequent properties within the tabs? I was happy to see the recent changes regarding nested allOf/oneOf constructs and they seem to apply to my setting without discriminators. Can't both cases (oneOf's with and w/o discriminator) be treated in corresponding fashion?

My adjustments almost certainly are not ready for merge, in particular the empty object omission was necessary for cases where a oneOf consists of nothing but the discriminating value itself. However, I expect issues with the discriminator resolution changes as well, probably even affecting my current document - just that I haven't found the regressions yet.

Here is the diff that solved my problem:

diff --git a/node_modules/docusaurus-theme-openapi-docs/src/theme/Schema/index.tsx b/node_modules/docusaurus-theme-openapi-docs/src/theme/Schema/index.tsx
index 631c464..bca76bc 100644
--- a/node_modules/docusaurus-theme-openapi-docs/src/theme/Schema/index.tsx
+++ b/node_modules/docusaurus-theme-openapi-docs/src/theme/Schema/index.tsx
@@ -314,14 +314,15 @@ const Properties: React.FC<SchemaProps> = ({
   }
   if (Object.keys(schema.properties as {}).length === 0) {
     return (
-      <SchemaItem
-        collapsible={false}
-        name=""
-        required={false}
-        schemaName="object"
-        qualifierMessage={undefined}
-        schema={{}}
-      />
+      <></>
+      // <SchemaItem
+      //   collapsible={false}
+      //   name=""
+      //   required={false}
+      //   schemaName="object"
+      //   qualifierMessage={undefined}
+      //   schema={{}}
+      // />
     );
   }
 
@@ -434,6 +435,13 @@ interface DiscriminatorNodeProps {
   schemaType: "request" | "response";
 }
 
+function findProperty(schema: SchemaObject, propertyName: string) {
+  return schema.properties?.[propertyName] 
+    ?? schema.oneOf?.find(subschema => findProperty(subschema, propertyName))
+    ?? schema.allOf?.find(subschema => findProperty(subschema, propertyName))
+    ?? {};
+}
+
 const DiscriminatorNode: React.FC<DiscriminatorNodeProps> = ({
   discriminator,
   schema,
@@ -443,9 +451,7 @@ const DiscriminatorNode: React.FC<DiscriminatorNodeProps> = ({
   let inferredMapping: any = {};
 
   // default to empty object if no parent-level properties exist
-  const discriminatorProperty = schema.properties
-    ? schema.properties![discriminator.propertyName]
-    : {};
+  const discriminatorProperty = findProperty(schema, discriminator.propertyName);
 
   if (schema.allOf) {
     const mergedSchemas = mergeAllOf(schema) as SchemaObject;
@@ -997,6 +1003,8 @@ const SchemaNode: React.FC<SchemaProps> = ({
     return null;
   }
 
+  schema = schema.allOf ? mergeAllOf(schema) as SchemaObject : schema;
+
   if (schema.discriminator) {
     const { discriminator } = schema;
     return (

I would be happy to push this topic towards an eventual PR merge, obtaining and providing feedback in the process, if everybody's time allows :)

This issue body was partially generated by patch-package.

[max-kahnt-keylight]

To anybody who wants to apply the patch above, please note that it only adjusts the src file.
But since the respective docusaurus build will use the lib file instead, the changes won't have any effect.
You can patch and swizzle to see it in effect.
In either case you might want to patch using the changes from the associated PR over my patch above.

[max-kahnt-keylight]

@sserrata You find me amazed and happy by how quickly you made this into a descriptive PR. The PR solves the immediate issue that had me go after this in the first place, so thank you! 🥇

Please note that my description above also points at a related issue regarding differences in the render paths which should become more apparent now:

• When the outer oneOf has a discriminator, the schema renders as I would expect with the changes from your PR.
• When the outer oneOf has no discriminator, the outer schema renders all/some of its properties, followed by the inner oneOf. The inner oneOf then renders its inner properties, but also merged with the outer properties again, duplicating them.

The latter buggy behavior exists on current main and after your PR.
My impression is that this is a related but also decently independent issue and requires a soft rewrite. My understanding and suggestion would be that oneOf rendering should not differ depending on the existence of an explicit discriminator. Only the tab descriptions should be affected.
Do you require a more detailed example to reproduce/assess/address this?