Parse the response, validate that it matches the shape your demo-item UI expects, and render only the validated data. JSON parsing confirms the body is valid JSON; it does not confirm that it contains the fields or types your components need.
Why parsing JSON is not enough
A JSON parser can return an array, string, number, object, or null. Even an object can be missing required fields or contain values of the wrong type. If a renderer assumes every item has an ID and title, an unexpected response can cause errors, display broken content, or silently produce misleading UI.
Define the response contract at the boundary between the API and the UI. Validate the parsed value against that contract before handing it to a component or mapping it into demo items. This separates two questions: “Could this body be decoded as JSON?” and “Is this value safe and usable for this UI?”
Validate first, then render
- Read and parse the response. Use your framework’s normal response API, and handle a failed JSON parse as a parsing error.
- Validate the parsed value. Check the expected top-level structure and the fields and types required by the renderer. Keep this validation at the API boundary rather than scattering assumptions through components.
- Render only accepted data. Pass the validator’s successful result to the demo-item renderer; do not pass the original unchecked value.
- Handle rejection explicitly. Show a suitable error or fallback state instead of trying to render invalid data. If the interface has loading or empty states, keep them distinct from a malformed-response error.
This outline is stack-neutral rather than runnable code: the endpoint, item fields, framework, and installed validation library are not specified here. Choose a runtime schema that matches the actual response and UI contract.
#1 Best Overall
Choose the validation boundary that fits your app
Validate an endpoint response schema
If the project uses Redux Toolkit Query, its query documentation describes runtime response validation with responseSchema. This places the check in the endpoint’s data lifecycle, before the result is consumed by the UI. Use it when the response is ordinary API data and the schema can represent the endpoint’s actual payload. See Redux Toolkit Query: Queries.
Validate a UI specification and its allowed components
Generated UI specifications need more than item-record checks: the accepted structure and component properties should be constrained too. json-render describes a predefined catalog and validation of specs before rendering; its core API also documents schema parsing and safeParse. After validation, its documented React flow renders through a Renderer and registry. This is relevant when the JSON describes a component tree, not just a list of records. See json-render: Specs and json-render: Core API.
Check structured model output at the client boundary
OpenAI’s structured-output guidance recommends confirming that a response matches its JSON Schema and parsing it into native data structures. Structured output can constrain model responses, but the client should still enforce the contract its renderer relies on rather than treating any received value as inherently safe to render. See OpenAI: Structured model outputs.
When JSON is allowed to describe UI
Do not let arbitrary response data decide which components or props can be executed. For data-driven component trees, define the allowed component catalog and validate the specification against it before rendering. json-render’s introduction and specification documentation describe this constrained approach. For a normal demo list, validate the item records and render with components already chosen by your application.
What to check in the contract
- Top-level type: Is the response an array, an object containing an array, or another documented shape?
- Required fields: Do all fields used for display, keys, links, or actions exist?
- Field types and constraints: Are IDs strings or numbers as expected? Can display text be null? Are optional fields actually optional?
- Nested values: If the component reads nested properties, does the schema validate those structures too?
- Failure path: Does a parse failure differ from a schema failure in logging or user-facing behavior?
Use the endpoint’s documented contract as the source of truth. Avoid “fixing” invalid input with unchecked casts or rendering whatever fields happen to be present; if partial data is intentionally acceptable, represent that explicitly in the schema and UI.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Which approach should you use?
There is no universal winner among endpoint schemas, UI-spec catalogs, and structured-output checks. Use endpoint validation for conventional API payloads, catalog/spec validation when JSON describes UI structure, and structured-output support when the producer is a model—while preserving a client-side rendering contract in each case. The right choice depends on the stack already in use and on what the response represents; the cited documentation does not establish comparative performance results.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
