Plugins
A plugin is a function that returns an object - more specifically, the object may contain functions and components that augment and modify Swagger UI’s functionality.
Note: Semantic Versioning
Swagger UI’s internal APIs are not part of our public contract, which means that they can change without the major version change.
If your custom plugins wrap, extend, override, or consume any internal core APIs, we recommend specifying a specific minor version of Swagger UI to use in your application, because they will not change between patch versions.
If you’re installing Swagger UI via NPM, for example, you can do this by using a tilde:
Format
A plugin return value may contain any of these keys, where stateKey
is a name for a piece of state:
System is provided to plugins
Let’s assume we have a plugin, NormalPlugin
, that exposes a doStuff
action under the normal
state namespace.
As you can see, each plugin is passed a reference to the system
being built up. As long as NormalPlugin
is compiled before ExtendingPlugin
, this will work without any issues.
There is no dependency management built into the plugin system, so if you create a plugin that relies on another, it is your responsibility to make sure that the dependent plugin is loaded after the plugin being depended on.
Interfaces
Actions
Once an action has been defined, you can use it anywhere that you can get a system reference:
The Action interface enables the creation of new Redux action creators within a piece of state in the Swagger UI system.
This action creator function will be exposed to container components as exampleActions.updateFavoriteColor
. When this action creator is called, the return value (which should be a Flux Standard Action) will be passed to the example
reducer, which we’ll define in the next section.
For more information about the concept of actions in Redux, see the Redux Actions documentation.
Reducers
Reducers take a state (which is an Immutable.js map) and an action, then returns a new state.
Reducers must be provided to the system under the name of the action type that they handle, in this case, EXAMPLE_SET_FAV_COLOR
.
Selectors
Selectors reach into their namespace’s state to retrieve or derive data from the state.
They’re an easy way to keep logic in one place, and are preferred over passing state data directly into components.
You can also use the Reselect library to memoize your selectors, which is recommended for any selectors that will see heavy use, since Reselect automatically memoizes selector calls for you:
Once a selector has been defined, you can use it anywhere that you can get a system reference:
Components
You can provide a map of components to be integrated into the system.
Be mindful of the key names for the components you provide, as you’ll need to use those names to refer to the components elsewhere.
You can also “cancel out” any components that you don’t want by creating a stateless component that always returns null
:
You can use config.failSilently
if you don’t want a warning when a component doesn’t exist in the system.
Be mindful of getComponent
arguments order. In the example below, the boolean false
refers to presence of a container, and the 3rd argument is the config object used to suppress the missing component warning.
Wrap-Actions
Wrap Actions allow you to override the behavior of an action in the system.
They are function factories with the signature (oriAction, system) => (...args) => result
.
A Wrap Action’s first argument is oriAction
, which is the action being wrapped. It is your responsibility to call the oriAction
- if you don’t, the original action will not fire!
This mechanism is useful for conditionally overriding built-in behaviors, or listening to actions.
Wrap-Selectors
Wrap Selectors allow you to override the behavior of a selector in the system.
They are function factories with the signature (oriSelector, system) => (state, ...args) => result
.
This interface is useful for controlling what data flows into components. We use this in the core code to disable selectors based on the API definition’s version.
Wrap-Components
Wrap Components allow you to override a component registered within the system.
Wrap Components are function factories with the signature (OriginalComponent, system) => props => ReactElement
. If you’d prefer to provide a React component class, (OriginalComponent, system) => ReactClass
works as well.
Here’s another example that includes a code sample of a component that will be wrapped:
rootInjects
The rootInjects
interface allows you to inject values at the top level of the system.
This interface takes an object, which will be merged in with the top-level system object at runtime.
afterLoad
The afterLoad
plugin method allows you to get a reference to the system after your plugin has been registered.
This interface is used in the core code to attach methods that are driven by bound selectors or actions. You can also use it to execute logic that requires your plugin to already be ready, for example fetching initial data from a remote endpoint and passing it to an action your plugin creates.
The plugin context, which is bound to this
, is undocumented, but below is an example of how to attach a bound action as a top-level method:
fn
The fn interface allows you to add helper functions to the system for use elsewhere.