Skip to content

fix(api): add missing response type in response section#42

Open
janelletam wants to merge 7 commits into
masterfrom
janelle/docs-v2/add-missing-response-type
Open

fix(api): add missing response type in response section#42
janelletam wants to merge 7 commits into
masterfrom
janelle/docs-v2/add-missing-response-type

Conversation

@janelletam

@janelletam janelletam commented Jun 12, 2026

Copy link
Copy Markdown
Contributor
image

Closes DOCS-112

@linear-code

linear-code Bot commented Jun 12, 2026

Copy link
Copy Markdown

DOCS-112

@greptile-apps

greptile-apps Bot commented Jun 12, 2026

Copy link
Copy Markdown

Greptile Summary

This PR fixes a missing response type label in the API page's Response section by rendering a short sentence that shows the schema's title and inferred type string (via the now-exported schemaTypeLabel helper from schema-explorer).

  • A new inline paragraph is inserted above the <SchemaExplorer> block; it renders only when schema.title or schema.type is present and combines both into a human-readable label.
  • schemaTypeLabel is exported from schema-explorer.tsx and re-used here, keeping the type-label logic in a single place.

Confidence Score: 4/5

Safe to merge — the change is additive UI-only and does not affect data fetching, routing, or any shared state.

The new paragraph is purely presentational and the fallback (no label rendered) is benign. The only gap is that schemas expressed entirely via oneOf/anyOf/enum without a top-level type or title will silently produce no label, even though schemaTypeLabel would generate a useful string for them. This is a display omission rather than a data or runtime error.

src/components/api-page.tsx — specifically the guard condition on line 165 around oneOf/anyOf schema variants.

Important Files Changed

Filename Overview
src/components/api-page.tsx Adds a response type label in the ResponseSection using the newly-exported schemaTypeLabel helper; guard condition doesn't cover all schema variants that schemaTypeLabel handles.

Sequence Diagram

sequenceDiagram
    participant R as ResponseSection
    participant S as schema (OpenAPI object)
    participant L as schemaTypeLabel()
    participant UI as Rendered UI

    R->>S: read schema.title, schema.type
    alt "schema.title || schema.type"
        R->>L: schemaTypeLabel(schema)
        L-->>R: "type string (e.g. "object", "string | null")"
        R->>UI: "render "The response is of type [title ·] <type>.""
    else no title and no type
        R->>UI: skip type label paragraph
    end
    R->>UI: render SchemaExplorer
Loading

Reviews (1): Last reviewed commit: "fix(api): add missing response type in r..." | Re-trigger Greptile

Comment on lines +165 to +177
{schema && (schema.title || schema.type) && (
<p className="mb-3 text-sm text-stone-600 dark:text-stone-400">
The response is of type{' '}
{schema.title && (
<>
<code className="rounded bg-stone-100 px-1 py-0.5 text-xs text-stone-900 dark:bg-stone-800 dark:text-stone-100">
{schema.title}
</code>
{' · '}
</>
)}
{schemaTypeLabel(schema)}.
</p>

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Guard condition misses oneOf/anyOf and enum-only schemas

The render condition schema.title || schema.type won't fire for schemas whose entire type information comes from oneOf, anyOf, or enum without a top-level type. schemaTypeLabel handles all three cases and would return a meaningful string (e.g. string | null, enum<string>), but the outer guard prevents the paragraph from ever appearing for them. A schema like { oneOf: [...] } with no title and no type would silently skip the label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant