Support for extending markdown interpreter

[liamdawson]

Q	A
Bug or feature request?	Feature request
Which Swagger/OpenAPI version?	-
Which Swagger-UI version?	3.13.0
How did you install Swagger-UI?	git clone
Which browser & version?	-
Which operating system?	-

Expected Behavior

I'd like to be able to extend Remarkable with custom configuration/plugins (https://github.com/jonschlinkert/remarkable/blob/master/docs/plugins.md).

Current Behavior

Remarkable is completely instantiated and consumed within the context of the Markdown provider, without passing in any configuration sources.

Possible Solution

Allow configuration options to be passed to Remarkable via a property of the Swagger UI configuration object.

Context

I'm attempting to use a plugin to render specific code-fenced blocks using an external library, instead of rendering them as per standard. As they are rendered within the Markdown flow (and rendered to escaped HTML before I can intercept), I am unable to do so.

[liamdawson]

I'd be happy to solve this myself, the approach I've considered is adding a configuration element to the main configuration object, and accessing it in the Markdown element. The main complication I seem to have with this approach is that getConfigs seems to require being recursively passed down, and I believe there are ~32 instances of the element being used (some of these consuming elements don't have a getConfigs prop themselves). Is there a way to DI the configuration or similar, or do we need to pass down the configuration recursively in every case?

[shockey]

Hey @liamdawson, just circling back on this and noticed you had unaddressed questions.

Is there a way to DI the configuration or similar, or do we need to pass down the configuration recursively in every case

We don't currently have any avenues for dependency injection. React does have a Context API, but React 15's implementation comes with a bunch of scare quotes about it... though it may still be usable. React 16's implementation looks better, but moving Swagger-UI to React 16 is a nontrivial thing (see #3955, #3714, #3970, #3934).

We could extend our plugin system to achieve dependency injection (I touched on this for the getComponent helper specifically in #3912, but it's equally relevant to getConfigs), but I'd be wary of a performance impact.

All this being said, I agree with you, handing around a prop in 32 different places just to get one thing working is not a great solution. I invite you (or anyone reading!) to explore the options I mentioned further and propose a solution 😄