Skip to content

Commit

Permalink
Update Events documentation with a 64 character line length.
Browse files Browse the repository at this point in the history
  • Loading branch information
nicksay committed Feb 7, 2015
1 parent 1e736ee commit 6b33992
Showing 1 changed file with 42 additions and 36 deletions.
78 changes: 42 additions & 36 deletions web/documentation/events.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,14 +4,15 @@ description: Handle SPF events and the navigation life cycle.
---


SPF is designed to give developers enough flexibility during navigation to
both control application logic and provide UI updates for things like progress
bars.
SPF is designed to give developers enough flexibility during
navigation to both control application logic and provide UI
updates for things like progress bars.


## Navigation Life Cycle

A basic event flow diagram follows and a more detailed explanation is below:
A basic event flow diagram follows and a more detailed
explanation is below:


Navigation Life Cycle Event Dispatched
Expand Down Expand Up @@ -64,56 +65,61 @@ A basic event flow diagram follows and a more detailed explanation is below:

## Event Descriptions

All events in the [API][api] are defined as [spf.Event][] objects. A list of
the events and their descriptions follows:
All events in the [API][] are defined as [spf.Event][] objects.
A list of the events and their descriptions follows:

**`spfclick`**
Fired when handling a click on a valid link (e.g. one with a valid `spf-link`
class or parent element). Use as an early indication that navigation will
happen or to provide element-level UI feedback.
Fired when handling a click on a valid link (e.g. one with a
valid `spf-link` class or parent element). Use as an early
indication that navigation will happen or to provide element-
level UI feedback.

**`spfhistory`**
Fired when handling a `popstate` history event, indicating the user has gone
backward or forward; similar to `spfclick`.
Fired when handling a `popstate` history event, indicating the
user has gone backward or forward; similar to `spfclick`.

**`spfrequest`**
Fired before a request for navigation is sent. Use to handle the beginning of
navigation and provide global-level UI feedback (i.e. start a progress bar).
This event is fired before a request is sent for all types of navigation:
clicks, back/forward, and API calls. (Note that this event is fired even if a
response is fetched from cache and no actual network request is made.)
Fired before a request for navigation is sent. Use to handle
the beginning of navigation and provide global-level UI feedback
(i.e. start a progress bar). This event is fired before a
request is sent for all types of navigation: clicks,
back/forward, and API calls. (Note that this event is fired
even if a response is fetched from cache and no actual network
request is made.)

**`spfprocess`**
Fired when a response has been received, either from the network or from
cache, before it is processed. Use to update UI feedback (i.e. advance a
progress bar) and dispose event listeners before content is updated.
Fired when a response has been received, either from the network
or from cache, before it is processed. Use to update UI
feedback (i.e. advance a progress bar) and dispose event
listeners before content is updated.

**`spfdone`**
Fired after response processing is done. Use to finalize UI feedback (i.e.
complete a progress bar) and initialize event listeners after content is
updated.
Fired after response processing is done. Use to finalize UI
feedback (i.e. complete a progress bar) and initialize event
listeners after content is updated.


## Callbacks and Cancellations

If manually starting navigation with [spf.navigate][], then instead of
handling events you may pass callbacks in an object that conforms to the
[spf.RequestOptions][] interface. Almost all events and callbacks can be
canceled by calling `preventDefault` or returning `false`, respectively. A
list of the events, their corresponding callbacks, and their cancel action
follows:
If manually starting navigation with [spf.navigate][], then
instead of handling events you may pass callbacks in an object
that conforms to the [spf.RequestOptions][] interface. Almost
all events and callbacks can be canceled by calling
`preventDefault` or returning `false`, respectively. A list of
the events, their corresponding callbacks, and their cancel
action follows:

| Event | Callback | State | Cancel |
|:-------------|:------------|:-------------------------------------|:-------|
| `spfclick` | | Link Clicked | Ignore |
| `spfhistory` | | Back/Forward Clicked | Ignore |
| `spfrequest` | `onRequest` | Started; Sending Request | Reload |
| `spfprocess` | `onProcess` | Processing; Response Received | Reload |
| `spfdone` | `onDone` | Done | |
| Event | Callback | State | Cancel |
|:-------------|:------------|:------------------------------|:-------|
| `spfclick` | | Link Clicked | Ignore |
| `spfhistory` | | Back/Forward Clicked | Ignore |
| `spfrequest` | `onRequest` | Started; Sending Request | Reload |
| `spfprocess` | `onProcess` | Processing; Response Received | Reload |
| `spfdone` | `onDone` | Done | |



[api]: ../../api/
[API]: ../../api/
[spf.Event]: ../../api/#spf.event
[spf.navigate]: ../../api/#spf.navigate
[spf.RequestOptions]: ../../api/#spf.requestoptions

0 comments on commit 6b33992

Please sign in to comment.