Merge pull request #132 from bhamodi/master

General Documentation Cleanup

CHANGELOG.md

@@ -8,15 +8,15 @@
 
 #### `Reactor#serialize()`
 
-Returns a plain javascript object representing the application state.  By defualt this maps over all stores and returns `toJS(storeState)`.
+Returns a plain JavaScript object representing the application state.  By default this maps over all stores and returns `toJS(storeState)`.
 
 ```js
 reactor.loadState(reactor.serialize())
 ```
 
 #### `Reactor#loadState( state )`
 
-Takes a plain javascript object and merges into the reactor state, using `store.deserialize`
+Takes a plain JavaScript object and merges into the reactor state, using `store.deserialize`
 
 This can be useful if you need to load data already on the page.
 
@@ -29,7 +29,7 @@ reactor.loadState({
 
 #### `Store#serialize`
 
-Serialization method for the store's data, by default its implemented as `Nuclear.toJS' which converts ImmutableJS objects to plain javascript.
+Serialization method for the store's data, by default its implemented as `Nuclear.toJS' which converts ImmutableJS objects to plain JavaScript.
 This is overridable for your specific data needs.
 
 ```js
@@ -48,7 +48,7 @@ Nuclear.Store({
 
 #### `Store#deserialize`
 
-Serialization method for the store's data, by default its implemented as `Nuclear.toImmutable' which converts plain javascript objects to ImmutableJS data structures.
+Serialization method for the store's data, by default its implemented as `Nuclear.toImmutable' which converts plain JavaScript objects to ImmutableJS data structures.
 This is overridable for your specific data needs.
 
 ```js
@@ -79,7 +79,7 @@ Nuclear.Store({
 
 ## 1.0.1 (April 27, 2015)
 
-- **[NEW]** Expose `createReactMixin` functionality on Nuclear singleton.
+- **[NEW]** Expose `createReactMixin` functionality on NuclearJS singleton.
 - **[FIXED]** Fix `new Store()` from throwing error when not passed a config object.
 
 ## 1.0.0 (April 25, 2015)

docs/README.md

@@ -1,14 +1,14 @@
 # NuclearJS Docs
 
-Doc site statically generated using `React` + `NuclearJS`.
+Documentation site statically generated using `React` + `NuclearJS`.
 
-##### For development
+### For development
 
 ```sh
 grunt dev
 ```
 
-##### To deploy to gh-pages
+### To deploy to gh-pages
 
 ```sh
 grunt publish

docs/TODO.md

@@ -1,4 +1,4 @@
-# Documentation site todo
+# Documentation site TODO List
 
 - [x] links to docs, API, github
 - [x] build pipeline for docs from MD files
@@ -8,3 +8,4 @@
 - [ ] scaffold design patterns/examples area
 - [ ] mobile side navbar
 - [ ] build pipeline for examples, create example component, possibly with code editing
+- [ ] add active state to Docs side bar. (currently doesn't show which tab is active/selected)

docs/grunt/build-site.js

@@ -112,9 +112,7 @@ function parseDocs(globPattern, opts, cb) {
   })
 }
 
-
 // Util Functions
-
 function filenameOnly(filepath) {
   return path.basename(filepath, path.extname(filepath))
 }

docs/src/components/doc-sidebar.js

@@ -4,8 +4,6 @@ import { BASE_URL } from '../globals'
 export default React.createClass({
   //propTypes: {
     //navStructure: React.PropTypes.objectOf(React.PropTypes.shape({
-
-
     //}))
   //},
 

docs/src/components/usage-example.js

@@ -102,7 +102,7 @@ var item0Price = reactor.evaluate(['items', 0, 'price'])
 // Evaluate by getter
 var filteredItems = reactor.evaluate(filteredItemsGetter)
 
-// Evaluate and coerce to plain javascript
+// Evaluate and coerce to plain JavaScript
 var itemsPOJO = reactor.evaluateToJS(filteredItemsGetter)
 
 // Observation
@@ -140,7 +140,7 @@ export default React.createClass({
             </p>
 
             <p>
-              <code>initialize()</code> - Sets up any action handlers, by specifying the action type and a function that transforms 
+              <code>initialize()</code> - Sets up any action handlers, by specifying the action type and a function that transforms
               <pre><code>(storeState, action) => (newStoreState)</code></pre>
             </p>
           </div>
@@ -213,15 +213,15 @@ export default React.createClass({
             </h3>
 
             <p>
-              Nuclear maintains a very non-magical approach to dispatching actions.  Simply call <code>reactor.dispatch</code> with the <code>actionType</code> and <code>payload</code>.
+              NuclearJS maintains a very non-magical approach to dispatching actions.  Simply call <code>reactor.dispatch</code> with the <code>actionType</code> and <code>payload</code>.
             </p>
 
             <p>
-              All action handling is done synchronously, leaving the state of the system very predicatable after every action.
+              All action handling is done synchronously, leaving the state of the system very predictable after every action.
             </p>
 
             <p>
-              Because actions are simply functions, it is very easy to compose actions together using plain javascript.
+              Because actions are simply functions, it is very easy to compose actions together using plain JavaScript.
             </p>
           </div>
         </div>
@@ -239,7 +239,7 @@ export default React.createClass({
             </h3>
 
             <p>
-              Nuclear also provides imperative mechanisms for evaluating and observing state.
+              NuclearJS also provides imperative mechanisms for evaluating and observing state.
             </p>
 
             <p>

docs/src/docs/01-getting-started.md

@@ -17,7 +17,7 @@ npm install --save nuclear-js
 
 ## Overview
 
-In this tutorial we'll create a Nuclear flux system to show a list of products and add them to a shopping cart.  Here's the plan:
+In this tutorial we'll create a NuclearJS flux system to show a list of products and add them to a shopping cart.  Here's the plan:
 
 1. Create a **Reactor**
 
@@ -33,19 +33,19 @@ In this tutorial we'll create a Nuclear flux system to show a list of products a
 
 1. Although the example code is written using ES6, this is totally optional.  NuclearJS fully supports ES5 out of the box.
 
-2. Nuclear stores work best when using ImmutableJS data structures.  You will see `toImmutable` quite often, this is simply sugar
+2. NuclearJS stores work best when using ImmutableJS data structures.  You will see `toImmutable` quite often, this is simply sugar
 to convert plain JavaScript arrays into [`Immutable.List`](https://facebook.github.io/immutable-js/docs/#/List) and objects to
 [`Immutable.Map`](https://facebook.github.io/immutable-js/docs/#/Map).  The use of `toImmutable` is optional, you are free to use
 any ImmutableJS data structure with no penalty.
 
 
 ## Creating a `Reactor`
 
-To get started, we'll create a Nuclear `Reactor`.  In Nuclear, the `Reactor` is the brains of the system and in some ways analogous
+To get started, we'll create a NuclearJS `Reactor`.  In Nuclear, the `Reactor` is the brains of the system and in some ways analogous
 to the traditional Flux `dispatcher` (though it works differently under the hood and provides a few extra features, which we'll
 cover later).
 
-Generally you'll only have one reactor for your application, however they are instanceable for server-side rendering.
+Generally you'll only have one reactor for your application, however they are instance-able for server-side rendering.
 
 The reactor has two main jobs:
 
@@ -67,7 +67,7 @@ export default reactor
 ```
 
 _* If you pass a `debug: true` option when instantiating a reactor, you'll get great debugging tools that print to your browser console.
-This is completely optional, but very useful for keeping tracking of dispatched actions and subsequest changes in state._
+This is completely optional, but very useful for keeping tracking of dispatched actions and subsequent changes in state._
 
 Now that we have our reactor, let's create some actions.
 

docs/src/docs/02-creating-actions.md

@@ -60,7 +60,7 @@ We've now created two actions that we can use to send data into the system.
 
 While synchronous actions are great, often you'll need to perform an asynchronous operation before dispatching an action. Nuclear
 fully supports creating actions asynchronously, as we're doing in `fetchProducts`.  This is a common pattern you'll use as your application grows,
-and Nuclear has no opinion on how you perform your operations: callbacks, Promises, Generators, ES7 async functions — they'll all work just fine!
+and NuclearJS has no opinion on how you perform your operations: callbacks, Promises, Generators, ES7 async functions — they'll all work just fine!
 
 If you'd like to jump ahead, you can read more about [async actions](./04-async-actions-and-optimistic-updates.html).
 

docs/src/docs/03-creating-stores.md

@@ -9,7 +9,7 @@ In Flux, stores are used for managing application state, but they don't represen
 
 More than simply managing ORM-style objects, **stores manage the state for a particular domain within the application**.
 
-Unlike many other Flux libraries, Nuclear stores hold no state. Instead, they provide a collection of functions that transform current state into new state.
+Unlike many other Flux libraries, NuclearJS stores hold no state. Instead, they provide a collection of functions that transform current state into new state.
 
 Stores provide a `getInitialState` method, which returns the initial state value that a store will manage, and an `initialize` hook, which is used to define what
 actions a store will respond to by attaching handlers.
@@ -23,7 +23,7 @@ handler(currentState: any, payload: any)
 
 In Nuclear, state can only be an ImmutableJS data type, such as an `Immutable.Map` or an `Immutable.List`, or a JavaScript primitive.
 
-Because stores in Nuclear don't hold state — they simply receive state, transform it, and return new state — there is no need to worry about stores knowing
+Because stores in NuclearJS don't hold state — they simply receive state, transform it, and return new state — there is no need to worry about stores knowing
 about other stores. That means no confusing `store.waitsFor` and no cross-pollution of data.  In Nuclear, the sole responsibility of a store is to return a portion
 of existing or transformed application state.  The responsibility of reading application state falls on **Getters**, which we'll cover later.
 
@@ -224,7 +224,7 @@ However, if stores are limited in scope, how can you read substantive data from
 
 It's actually quite simple: **composition**.
 
-Nuclear allows you to combine data from stores in a non-destructive manner, check it out:
+NuclearJS allows you to combine data from stores in a non-destructive manner, check it out:
 
 ```javascript
 reactor.evaluate([

docs/src/docs/05-hooking-up-to-react.md

@@ -7,13 +7,13 @@ section: "Guide"
 
 ### Binding application state to components
 
-Every Nuclear Reactor comes with `reactor.ReactMixin` to easily create an always-in-sync binding between any KeyPath or Getter value
+Every NuclearJS Reactor comes with `reactor.ReactMixin` to easily create an always-in-sync binding between any KeyPath or Getter value
 and a React component's state.
 
 The ability to observe any piece of composite data is immensely powerful and trivializes a lot of what other frameworks work hard to solve.
 
 To use simply include the `reactor.ReactMixin` and implement the `getDataBindings()` function that returns an object of state properties
-to `KeyPath` or `Getter`.  Nuclear will take care of the initial sync, observation and destroying the subscription when on `componentWillUnmount`.
+to `KeyPath` or `Getter`.  NuclearJS will take care of the initial sync, observation and destroying the subscription when on `componentWillUnmount`.
 
 **First let's expand our main file to initiate the fetch for products.**
 
@@ -140,9 +140,9 @@ export default React.createClass({
 
 ## Recap
 
-Once you have a functioning Nuclear Reactor, hooking it up to a React application is very easy using the `reactor.ReactMixin` + `getDataBindings()` method.
+Once you have a functioning NuclearJS Reactor, hooking it up to a React application is very easy using the `reactor.ReactMixin` + `getDataBindings()` method.
 
-Nuclear will automatically sync the value of a getter to your component via `this.setState` whenever the underlying getter value changes.  Meaning you never
+NuclearJS will automatically sync the value of a getter to your component via `this.setState` whenever the underlying getter value changes.  Meaning you never
 have to explicitly call `this.setState` to re-render a component.
 
 In the next section we will cover hooking up actions to our react components.

docs/src/docs/06-async-actions-and-optimistic-updates.md

@@ -163,7 +163,7 @@ This ends our getting started example, for a more in depth look all of the above
 For additional documentation and resources checkout the following:
 
 - [API Documentation](./07-api.html)
-- [Flux Chat Example](https://github.com/optimizely/nuclear-js/tree/master/examples/flux-chat) - classic facebook flux chat example written in NuclearJS
-- [Rest API Example](https://github.com/optimizely/nuclear-js/tree/master/examples/rest-api) - shows how to deal with fetching data from an API using NuclearJS conventions
+- [Flux Chat Example](https://github.com/optimizely/nuclear-js/tree/master/examples/flux-chat) - A classic Facebook flux chat example written in NuclearJS.
+- [Rest API Example](https://github.com/optimizely/nuclear-js/tree/master/examples/rest-api) - Shows how to deal with fetching data from an API using NuclearJS conventions.
 
 More coming soon...

docs/src/docs/07-api.md

@@ -89,7 +89,7 @@ reactor.observe([
 
 _added in 1.1_
 
-Returns a plain javascript object representing the application state.  By defualt this maps over all stores and returns `toJS(storeState)`.
+Returns a plain JavaScript object representing the application state.  By default this maps over all stores and returns `toJS(storeState)`.
 
 ```javascript
 reactor.loadState(reactor.serialize())
@@ -99,7 +99,7 @@ reactor.loadState(reactor.serialize())
 
 _added in 1.1_
 
-Takes a plain javascript object and merges into the reactor state, using `store.deserialize`
+Takes a plain JavaScript object and merges into the reactor state, using `store.deserialize`
 
 This can be useful if you need to load data already on the page.
 
@@ -201,7 +201,7 @@ Responsible for setting up action handlers for the store using `this.on(actionTy
 
 _added in 1.1_
 
-Serialization method for the store's data, by default its implemented as `Nuclear.toJS' which converts ImmutableJS objects to plain javascript.
+Serialization method for the store's data, by default its implemented as `Nuclear.toJS' which converts ImmutableJS objects to plain JavaScript.
 This is overridable for your specific data needs.
 
 ```javascript
@@ -222,7 +222,7 @@ Nuclear.Store({
 
 _added in 1.1_
 
-Serialization method for the store's data, by default its implemented as `Nuclear.toImmutable' which converts plain javascript objects to ImmutableJS data structures.
+Serialization method for the store's data, by default its implemented as `Nuclear.toImmutable' which converts plain JavaScript objects to ImmutableJS data structures.
 This is overridable for your specific data needs.
 
 ```javascript

docs/src/docs/99-core-concepts.md

@@ -5,11 +5,11 @@ section: "Guide"
 
 ## Core Concepts
 
-The easiest way to think about how NuclearJS is modelling the state of your system is to imagine it all as a single map (or JavaScript object).  If you are familiar with Om then the concept of a singular App State is very familiar already.
+The easiest way to think about how NuclearJS is modeling the state of your system is to imagine it all as a single map (or JavaScript object).  If you are familiar with Om then the concept of a singular App State is very familiar already.
 
 Each entry in this top level map contains a portion of the entire app state for a specific domain and are managed by **stores**.
 
-Imagine modelling a shopping cart.  Our app state would look like:
+Imagine modeling a shopping cart.  Our app state would look like:
 
 ```javascript
 {
@@ -31,7 +31,7 @@ live in our app state because those are all examples of **computable state**, an
 
 #### Reactor
 
-In Nuclear a Reactor is the container that holds your app state, it's where you register stores, dispatch actions and read the current state of your system.  Reactor's are the only stateful part of Nuclear and have only 3 API methods you REALLY need to know: `dispatch`, `get`, and `observe`. Don't worry, extensive API docs will be provided for all of these methods.
+In NuclearJS a Reactor is the container that holds your app state, it's where you register stores, dispatch actions and read the current state of your system.  Reactor's are the only stateful part of NuclearJS and have only 3 API methods you REALLY need to know: `dispatch`, `get`, and `observe`. Don't worry, extensive API docs will be provided for all of these methods.
 
 #### Stores
 
@@ -80,9 +80,9 @@ var totalGetter = [
 ]
 ```
 
-Notice that you can use getters as dependencies to other getters.  This is an extremely powerful abstraction, and one that you'll undoubtedly want to become familiar with in your nuclear journey.
+Notice that you can use getters as dependencies to other getters.  This is an extremely powerful abstraction, and one that you'll undoubtedly want to become familiar with in your NuclearJS journey.
 
-But you need to know one thing about getter transform functions - they MUST be pure functions (that is, a given set input values results in a [deterministic](https://en.wikipedia.org/wiki/Deterministic_algorithm) output). By making the transform functions pure, you can test Getters easier, compose them easier, and nuclear can [memoize](https://en.wikipedia.org/wiki/Memoization) calls to them, making Getter dependency resolution very performant.
+But you need to know one thing about getter transform functions - they MUST be pure functions (that is, a given set input values results in a [deterministic](https://en.wikipedia.org/wiki/Deterministic_algorithm) output). By making the transform functions pure, you can test Getters easier, compose them easier, and NuclearJS can [memoize](https://en.wikipedia.org/wiki/Memoization) calls to them, making Getter dependency resolution very efficient.
 
 __For the astute reader__ - You probably already noticed if you have experience in functional languages, but because Getters
 are simply arrays full of strings and pure functions, they are serializable. Since JS can stringify pure functions, your getters are nothing more than data that could be stored, sent over the wire, etc.
@@ -260,7 +260,7 @@ var ShoppingCart = React.createClass({
   mixins: [reactor.ReactMixin],
 
   // simply implement this function to keep a component's state
-  // in sync with a Nuclear Reactor
+  // in sync with a NuclearJS Reactor
   getDataBindings() {
     return {
       // can reference a reactor KeyPath

docs/src/pages/index.js

@@ -42,7 +42,7 @@ export default React.createClass({
                 </p>
 
                 <h3 className="tour-section--bullet-title">
-                  Powerful functional dataflow 
+                  Powerful functional dataflow
                 </h3>
                 <p className="tour-section--bullet-item">
                   Compose and transform your data together statelessly and efficiently using a functional lens concept called <strong>Getters</strong>.
@@ -58,7 +58,7 @@ export default React.createClass({
                   Any Getter can be observed by a view to be notified whenever its derived value changes.
                 </p>
                 <p className="tour-section--bullet-item">
-                  Nuclear includes tools to integrate with libraries such as React and VueJS out of the box.
+                  NuclearJS includes tools to integrate with libraries such as React and VueJS out of the box.
                 </p>
 
                 <h3 className="tour-section--bullet-title">
@@ -68,7 +68,7 @@ export default React.createClass({
                   Thanks to immutable data, change detection can be efficiently performed at any level of granularity by a constant time reference equality <code>(===)</code> check.
                 </p>
                 <p className="tour-section--bullet-item">
-                  Since Getters use pure functions, Nuclear utilizes memoization to only recompute parts of the dataflow that might change.
+                  Since Getters use pure functions, NuclearJS utilizes memoization to only recompute parts of the dataflow that might change.
                 </p>
               </div>
             </div>