Redocly / Redocly/redoc

Customizable "required" label value

Open
#2,412 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Type: Enhancement
Dominant language
TypeScript
Stars
25.9k
Forks
2.4k
Avg merge
13h 10m
Merged PRs (30d)
4

Description

Describe the problem to be solved
I'm currently using redoc to expose a documentation of my API for my consumers. The API itself is generated with openapi generator which also generates the client in form of a package. Such package is used in another service of mine. I want to properly annotate what property is not nullable.

If I do something like

required:
    - propertyA

in the redoc result page, such property will be having a "required" word... this case is present in your demo page in here. Taking that as an example, it doesn´t make sense to mark as "required" properties in the result body like so:

Screenshot 2023-09-09 at 19 53 59

Is it there a way to change this "required" keyword for something like "Non nullable" or simply not showing it?

If not, consider this an enhancement for additional customization

Take in mind that is not only tech people who will read the redoc's generated page and this is something that can cause confusion.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No file, test, or entry point is identified in the issue. Start by locating the rendering of the OpenAPI required label in the generated documentation and determine how display text or visibility could be configured. Done means supporting a configurable replacement such as “Non nullable” or hiding the label without changing the API specification.

Written by the indexing model from the issue text.

Assessment

Tech stack
openapi, typescript
Domain
documentation, frontend
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.