Change Swagger-UI -> Swagger UI in docs (#5479)

* Change Swagger-UI -> Swagger UI in docs

* Changed back to SwaggerUI in places that refer to JS construct
This commit is contained in:
Helen Kosova
2019-07-19 18:22:45 +03:00
committed by Ron
parent be5e057bfa
commit 8822a7229a
15 changed files with 77 additions and 77 deletions

View File

@@ -1,8 +1,8 @@
# Creating a custom layout
**Layouts** are a special type of component that Swagger-UI uses as the root component for the entire application. You can define custom layouts in order to have high-level control over what ends up on the page.
**Layouts** are a special type of component that Swagger UI uses as the root component for the entire application. You can define custom layouts in order to have high-level control over what ends up on the page.
By default, Swagger-UI uses `BaseLayout`, which is built into the application. You can specify a different layout to be used by passing the layout's name as the `layout` parameter to Swagger-UI. Be sure to provide your custom layout as a component to Swagger-UI.
By default, Swagger UI uses `BaseLayout`, which is built into the application. You can specify a different layout to be used by passing the layout's name as the `layout` parameter to Swagger UI. Be sure to provide your custom layout as a component to Swagger UI.
<br>

View File

@@ -2,7 +2,7 @@
### Prior art
Swagger-UI leans heavily on concepts and patterns found in React and Redux.
Swagger UI leans heavily on concepts and patterns found in React and Redux.
If you aren't already familiar, here's some suggested reading:
@@ -17,7 +17,7 @@ In the following documentation, we won't take the time to define the fundamental
### The System
The _system_ is the heart of the Swagger-UI application. At runtime, it's a JavaScript object that holds many things:
The _system_ is the heart of the Swagger UI application. At runtime, it's a JavaScript object that holds many things:
- React components
- Bound Redux actions and reducers
@@ -27,11 +27,11 @@ The _system_ is the heart of the Swagger-UI application. At runtime, it's a Java
- References to the React and Immutable.js libraries (`system.React`, `system.Im`)
- User-defined helper functions
The system is built up when Swagger-UI is called by iterating through ("compiling") each plugin that Swagger-UI has been given, through the `presets` and `plugins` configuration options.
The system is built up when Swagger UI is called by iterating through ("compiling") each plugin that Swagger UI has been given, through the `presets` and `plugins` configuration options.
### Presets
Presets are arrays of plugins, which are provided to Swagger-UI through the `presets` configuration option. All plugins within presets are compiled before any plugins provided via the `plugins` configuration option. Consider the following example:
Presets are arrays of plugins, which are provided to Swagger UI through the `presets` configuration option. All plugins within presets are compiled before any plugins provided via the `plugins` configuration option. Consider the following example:
```javascript
const MyPreset = [FirstPlugin, SecondPlugin, ThirdPlugin]
@@ -43,7 +43,7 @@ SwaggerUI({
})
```
By default, Swagger-UI includes the internal `ApisPreset`, which contains a set of plugins that provide baseline functionality for Swagger-UI. If you specify your own `presets` option, you need to add the ApisPreset manually, like so:
By default, Swagger UI includes the internal `ApisPreset`, which contains a set of plugins that provide baseline functionality for Swagger UI. If you specify your own `presets` option, you need to add the ApisPreset manually, like so:
```javascript
SwaggerUI({
@@ -54,7 +54,7 @@ SwaggerUI({
})
```
The need to provide the `apis` preset when adding other presets is an artifact of Swagger-UI's original design, and will likely be removed in the next major version.
The need to provide the `apis` preset when adding other presets is an artifact of Swagger UI's original design, and will likely be removed in the next major version.
### getComponent
@@ -62,7 +62,7 @@ The need to provide the `apis` preset when adding other presets is an artifact o
All components should be loaded through `getComponent`, since it allows other plugins to modify the component. It is preferred over a conventional `import` statement.
Container components in Swagger-UI can be loaded by passing `true` as the second argument to `getComponent`, like so:
Container components in Swagger UI can be loaded by passing `true` as the second argument to `getComponent`, like so:
```javascript
getComponent("ContainerComponentName", true)

View File

@@ -1,16 +1,16 @@
# Plug points
Swagger-UI exposes most of its internal logic through the plugin system.
Swagger UI exposes most of its internal logic through the plugin system.
Often, it is beneficial to override the core internals to achieve custom behavior.
### 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 changing.
Swagger UI's internal APIs are _not_ part of our public contract, which means that they can change without the major version changing.
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 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:
If you're installing Swagger UI via NPM, for example, you can do this by using a tilde:
```js
{

View File

@@ -1,14 +1,14 @@
# 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.
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 changing.
Swagger UI's internal APIs are _not_ part of our public contract, which means that they can change without the major version changing.
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 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:
If you're installing Swagger UI via NPM, for example, you can do this by using a tilde:
```js
{
@@ -96,7 +96,7 @@ Once an action has been defined, you can use it anywhere that you can get a syst
system.exampleActions.updateFavoriteColor("blue")
```
The Action interface enables the creation of new Redux action creators within a piece of state in the Swagger-UI system.
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](https://github.com/acdlite/flux-standard-action)) will be passed to the `example` reducer, which we'll define in the next section.
@@ -225,7 +225,7 @@ A Wrap Action's first argument is `oriAction`, which is the action being wrapped
This mechanism is useful for conditionally overriding built-in behaviors, or listening to actions.
```javascript
// FYI: in an actual Swagger-UI, `updateSpec` is already defined in the core code
// FYI: in an actual Swagger UI, `updateSpec` is already defined in the core code
// it's just here for clarity on what's behind the scenes
const MySpecPlugin = function(system) {
return {
@@ -251,9 +251,9 @@ const MyWrapActionPlugin = function(system) {
spec: {
wrapActions: {
updateSpec: (oriAction, system) => (str) => {
// here, you can hand the value to some function that exists outside of Swagger-UI
// here, you can hand the value to some function that exists outside of Swagger UI
console.log("Here is my API definition", str)
return oriAction(str) // don't forget! otherwise, Swagger-UI won't update
return oriAction(str) // don't forget! otherwise, Swagger UI won't update
}
}
}
@@ -273,7 +273,7 @@ This interface is useful for controlling what data flows into components. We use
```javascript
import { createSelector } from 'reselect'
// FYI: in an actual Swagger-UI, the `url` spec selector is already defined
// FYI: in an actual Swagger UI, the `url` spec selector is already defined
// it's just here for clarity on what's behind the scenes
const MySpecPlugin = function(system) {
return {