Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to customise Redoc and Swagger UI HTML #1332

Closed
retnikt opened this issue Apr 27, 2020 · 4 comments
Closed

Ability to customise Redoc and Swagger UI HTML #1332

retnikt opened this issue Apr 27, 2020 · 4 comments

Comments

@retnikt
Copy link
Contributor

retnikt commented Apr 27, 2020

Is your feature request related to a problem? No

Currently, Redoc and Swagger UI are served from literal strings in the code with formatted-in options for Title, JS URL, etc. However, these are not customisable and the hardcoded defaults are always used.

The solution you would like

I propose to add some a redoc_kwargs and docs_kwargs (or similar) parameter to the FastAPI class (because having individual arguments would be too cumbersome) which are passed to the get_redoc_html and get_swagger_ui_html methods. I also propose adding some more arguments to those methods for custom CSS, fonts, or other HTML additions (perhaps a slot each for <head> and <body> after the rest of the content) if required.

Describe alternatives you've considered

Currently you could implement your own Redoc/Swagger UI endpoints instead of using FastAPI's ones and returning your own HTML, but I feel that sort of defeats the purpose of having these features.

These endpoints could even be converted to full-blown Jinja2 templates or similar, although this does seem a bit excessive to me.

Additional context

(note: what follows are a bunch of rambled related ideas I came up with in the 5 minutes I spent writing this issue, in hindsight these could have been separate issues)

Perhaps as part of this revamp, the get_redoc_html and get_swagger_ui_html methods could be closures, so that the static HTML is not recreated on every request (a separate issue, I know, and only a very minor performance bump as well)

Another related suggestion would be to allow rewriting all requests to /docs/* / /redoc/* to those URLs to enable use of HTML5 history mode instead of anchors, SPA-style (although I believe currently neither Swagger UI nor Redoc actually support these)

@retnikt retnikt added the feature New feature or request label Apr 27, 2020
@retnikt
Copy link
Contributor Author

retnikt commented Apr 28, 2020

I just found https://fastapi.tiangolo.com/advanced/extending-openapi/#serve-the-static-files, which has some implicit documentation on customisation, but the point still stands that it would be nice to have a kwargs dict passed to the automatic methods so we don't have to override methods.

@ycd
Copy link
Contributor

ycd commented Feb 25, 2021

it would be nice to have a kwargs dict passed to the automatic methods so we don't have to override methods.

#2568 does exactly this.

@RayBB
Copy link

RayBB commented Jan 18, 2022

@retnikt I think since #2568 is merged and released you can probably close this ticket!

@emirkmo
Copy link

emirkmo commented Dec 20, 2022

@retnikt #2568 does not fully address this I think. There is still literally hardcoded HTML header and favicon links, among others, which are not customizeable without overwriting the docs and serving your own from e.g. /static

@tiangolo tiangolo added question Question or problem reviewed and removed feature New feature or request labels Feb 24, 2023
@tiangolo tiangolo changed the title [FEATURE] Ability to customise Redoc and Swagger UI HTML Ability to customise Redoc and Swagger UI HTML Feb 24, 2023
Repository owner locked and limited conversation to collaborators Feb 28, 2023
@tiangolo tiangolo converted this issue into discussion #9055 Feb 28, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

5 participants