Nearly everything which is seen by the consumer of an Accelerator story (with the notable exception of content injected by plugins through `beforeRender` methods) was generated through a passage renderer. The passage renderer must match the signature of `IPassageRenderer`, and should ideally extend the abstract class `AbstractPassageRenderer`, which implements all methods but `render`.

The renderer has several primary objectives:

* Implement a `render` method which producse a rendered passage element as a pure function of the state represented in the `context` and `configuration` properties.
* Render one (and only one) `SkipToContentLinkDestination` destination above the present passage so as to allow disabled or otherwise non-pointer-using readers to skip to the newest content from the top of the document.
* (By default) Render one or more `PassageContainer` components, passing relevant state and functions to the component(s).

Note that *pure* as referenced above refers to the render method not mutating application state or otherwise causing side effects in the application. This is not checked (and probably cannot be exhaustively checked) statically or at runtime, but it is an important concern to maintain when implementing a renderer. One easy-ish method to avoid this is to set default story state on component construction and not on rendering.

There are two renderers which are included with Accelerator. The first, and default, is the `SinglePassageRenderer`. This renderer shows the current passage, much like a typical Twine story does. When you navigate to a new passage, the old passage disappears and the new passage appears in its place. The other is the `ScrollRenderer`. This is closer in behavior (and default appearance) to an Ink story, or a story using the `Jonah` story format for Twine 1, and shows the previously-seen passages like a scroll unfurled above the current passage. The latter is currently unstable and under development.