Rename stores to domains

README.md

@@ -32,36 +32,37 @@ npm install --save microcosm
 
 Microcosm is a variant of [Flux](https://facebook.github.io/flux/)
 that makes it easier to control and modify state in a pure,
-centralized way. It thinks of stores and actions as stateless
-collections of pure functions, keeping all data encapsulated in a
-specific instance of Microcosm.
+centralized way. It thinks of stores (called domains in Microcosm) and
+actions as stateless collections of pure functions, keeping all data
+encapsulated in a specific instance of Microcosm.
 
 ### Stateless stores
 
-Stores hold no state; instead they are responsible for writing state
-to the repository owned by a Microcosm instance.
+Microcosm stores hold no state. They are responsible for writing state
+to the repository owned by a Microcosm instance. To further make this
+distinction from traditional flux, we call them _domains_.
 
-This allows stores to be simple collections of pure functions that
+This allows domains to be simple collections of pure functions that
 transform old data into new data. The `register` hook tells Microcosm
-what actions a store should respond to:
+what actions a domain should respond to:
 
 ```javascript
 const Planets = {
-  // Tells a Microcosm how a store should respond to actions
+  // Tells a Microcosm how a domain should respond to actions
   register() {
     return {
       [addPlanet] : this.add
     }
   },
-  // Store handlers are pure functions that take an old state and
+  // Domain handlers are pure functions that take an old state and
   // transform it into a new state
   add(planets, props) {
     return planets.concat(props)
   }
 }
 ```
 
-Visit [the API documentation for stores](./docs/api/stores.md) to
+Visit [the API documentation for domains](./docs/api/domains.md) to
 read more.
 
 ### No action constants
@@ -71,15 +72,15 @@ referential identity of the action and the current state of its
 lifecycle.
 
 An action can be in several states: `open`, `loading`, `done`,
-`error`, and `cancelled`. Stores can subscribe to each of these
+`error`, and `cancelled`. Domains can subscribe to each of these
 states through the use of a `register` function:
 
 ```javascript
 function createPlanet (params) {
   return ajax.post('/planets', params)
 }
 
-repo.addStore('planets', {
+repo.addDomain('planets', {
   getInitialState() {
     return { records: [], loading: false }
   },
@@ -99,7 +100,7 @@ repo.addStore('planets', {
 })
 
 
-// Creates a action of type "createPlanet" that dispatches to stores
+// Creates a action of type "createPlanet" that dispatches to domains
 repo.push(createPlanet, params)
 ```
 
@@ -162,7 +163,7 @@ const page2 = repo.push(search, { term: 'cats', page: 2 })
 ```
 
 Cancelled actions are put into a `cancelled` state, which can be
-subscribed to in stores.
+subscribed to in domains.
 
 ## Action history
 
@@ -176,9 +177,9 @@ Internally, Microcosm calculates state by rolling forward through a historical a
 
 1. Action CONSTANTS are automatically generated by assigning
    each Action function a unique `toString` signature under the hood.
-2. Actions handle all asynchronous operations. Stores are
+2. Actions handle all asynchronous operations. Domains are
    synchronous.
-3. Stores do not contain data, they _transform_ it.
+3. Domains do not contain data, they _transform_ it.
 
 ## What is it trying to solve?
 

bench/dispatch-performance.js

@@ -28,7 +28,7 @@ var results = SIZES.map(function (SIZE) {
   var action = function test () {}
   action.toString = function () { return 'test' }
 
-  var Store = {
+  var Domain = {
     getInitialState: () => 0,
     register() {
       return {
@@ -38,15 +38,15 @@ var results = SIZES.map(function (SIZE) {
   }
 
   /**
-   * Add the store at multiple keys. This is a better simulation of actual
+   * Add the domain at multiple keys. This is a better simulation of actual
    * applications. Otherwise, efficiencies are obtained enumerating over
    * very few keys. This is never the case in real-world applications.
    */
-  repo.addStore('one',   Store)
-  repo.addStore('two',   Store)
-  repo.addStore('three', Store)
-  repo.addStore('four',  Store)
-  repo.addStore('five',  Store)
+  repo.addDomain('one',   Domain)
+  repo.addDomain('two',   Domain)
+  repo.addDomain('three', Domain)
+  repo.addDomain('four',  Domain)
+  repo.addDomain('five',  Domain)
 
   /**
    * Append a given number of actions into history. We use this method

bench/push-performance.js

@@ -22,7 +22,7 @@ var results = SIZES.map(function (SIZE) {
   var action = function test () {}
   action.toString = function () { return 'test' }
 
-  var Store = {
+  var Domain = {
     getInitialState: () => 0,
     register() {
       return {
@@ -32,15 +32,15 @@ var results = SIZES.map(function (SIZE) {
   }
 
   /**
-   * Add the store at multiple keys. This is a better simulation of actual
+   * Add the domain at multiple keys. This is a better simulation of actual
    * applications. Otherwise, efficiencies are obtained enumerating over
    * very few keys. This is never the case in real-world applications.
    */
-  repo.addStore('one',   Store)
-  repo.addStore('two',   Store)
-  repo.addStore('three', Store)
-  repo.addStore('four',  Store)
-  repo.addStore('five',  Store)
+  repo.addDomain('one',   Domain)
+  repo.addDomain('two',   Domain)
+  repo.addDomain('three', Domain)
+  repo.addDomain('four',  Domain)
+  repo.addDomain('five',  Domain)
 
   var then = time.now()
 

docs/README.md

@@ -6,7 +6,7 @@ start. Beyond that, check out [the example apps](../examples).
 ## Guides
 
 1. [Overview](guides/01-overview.md)
-2. [Stores](guides/02-stores.md)
+2. [Domains](guides/02-domains.md)
 3. [Actions](guides/03-actions.md)
 
 ## Recipes
@@ -18,7 +18,7 @@ start. Beyond that, check out [the example apps](../examples).
 ## API
 
 1. [Microcosm](api/microcosm.md)
-2. [Stores](api/stores.md)
+2. [Domains](api/domains.md)
 3. [Actions](api/actions.md)
 
 ## Addons

docs/api/actions.md

@@ -2,7 +2,7 @@
 
 1. [Overview](#overview)
 2. [Writing action creators](#writing-action-creators)
-3. [Dispatching to Stores](#dispatching-to-stores)
+3. [Dispatching to Domains](#dispatching-to-domains)
 4. [How this works](#how-this-works)
 5. [API](#api)
 
@@ -42,7 +42,7 @@ repo.push(addPlanet, { name: 'Saturn' })
 
 Action creators that return a promise move through several states:
 
-1. `open`: The action is opened immediately. This allows stores to
+1. `open`: The action is opened immediately. This allows domains to
    handle a loading state.
 2. `done`: The action completes when the Promise resolves
 3. `error`: The action fails when the Promise is rejected
@@ -87,19 +87,19 @@ function readPlanets () {
 repo.push(readPlanets)
 ```
 
-## Dispatching to Stores
+## Dispatching to Domains
 
 One of the differences between Microcosm and other Flux
-implementations is the dispatch process. Sending actions to stores is
+implementations is the dispatch process. Sending actions to domains is
 handled by Microcosm. Instead of dispatching `ACTION_LOADING` or
 `ACTION_FAILED`, actions go through various states as they
-resolve. You can subscribe to these states within stores like:
+resolve. You can subscribe to these states within domains like:
 
 ```javascript
-// A sample store that subscribes to every action state
+// A sample domain that subscribes to every action state
 const SolarSystem = {
 
-  // ... Other store methods
+  // ... Other domain methods
 
   register() {
     return {
@@ -183,29 +183,29 @@ repo.push(promiseAction).then(success, failure)
 ### `open([payload])`
 
 Elevate an action into the `open` state and optional update the
-payload. Stores registered to `action.open` will pick up on an action
+payload. Domains registered to `action.open` will pick up on an action
 within this state.
 
 ### `send([payload])`
 
 Send a progress update. This will move an action into the `loading`
-state and optional update the payload. Stores registered to
+state and optional update the payload. Domains registered to
 `action.loading` will pick up on an action within this state.
 
 ### `reject([payload])`
 
 Reject an action. This will move an action into the `error` state and
-optional update the payload. Stores registered to `action.error` will
+optional update the payload. Domains registered to `action.error` will
 pick up on an action within this state.
 
 ### `close([payload])`
 
 Resolve an action. This will move an action into the `done` state and
-optional update the payload. Stores registered to `action` or `action.done`
+optional update the payload. Domains registered to `action` or `action.done`
 will pick up on an action within this state.
 
 ### `cancel()`
 
 Cancel an action. This is useful for handling cases such as aborting
-ajax requests. Moves an action into the `cancelled`. Stores registered
+ajax requests. Moves an action into the `cancelled`. Domains registered
 to `action.cancelled` will pick up on an action within this state.

docs/api/stores.md → docs/api/domains.md

@@ -1,37 +1,37 @@
-# Stores
+# Domains
 
 1. [Overview](#overview)
 2. [Subscribing to different action states](#subscribing-to-different-action-states)
 3. [API](#api)
 
 ## Overview
 
-Stores define the rules in which resolved actions are converted into
-new state. They are added to a Microcosm instance using `addStore`:
+Domains define the rules in which resolved actions are converted into
+new state. They are added to a Microcosm instance using `addDomain`:
 
 ```javascript
-// Mount a store that operates on a specific key in repo state.
-// Any operations the store handles are recorded at `repo.state.key`:
-repo.addStore('key', Store)
+// Mount a domain that operates on a specific key in repo state.
+// Any operations the domain handles are recorded at `repo.state.key`:
+repo.addDomain('key', Domain)
 
-// Mount a store that operates on all repo state, handlers will
+// Mount a domain that operates on all repo state, handlers will
 // write directly to `repo.state` itself:
-repo.addStore(Store)
+repo.addDomain(Domain)
 ```
 
-Stores do not enforce any particular structure. However specific
-methods can be defined on stores to configure behavior at key points
+Domains do not enforce any particular structure. However specific
+methods can be defined on domains to configure behavior at key points
 in a Microcosm's lifecycle.
 
 ## Subscribing to different action states
 
-Stores can provide a `register` method to dictate what actions they
+Domains can provide a `register` method to dictate what actions they
 listen to:
 
 ```javascript
-const Store = {
+const Domain = {
 
-  // ... Other store methods
+  // ... Other domain methods
 
   register() {
     return {
@@ -52,8 +52,8 @@ const Store = {
 
 ### `getInitialState()`
 
-Generate the starting value for the particular state this store is
-managing. This will be called by the Microcosm using this store when
+Generate the starting value for the particular state this domain is
+managing. This will be called by the Microcosm using this domain when
 it is started.
 
 ```javascript
@@ -66,13 +66,13 @@ var Planets = {
 
 ### `setup()`
 
-Setup runs right after a store is added to a Microcosm, but before it runs
+Setup runs right after a domain is added to a Microcosm, but before it runs
 getInitialState. This is useful for one-time setup instructions.
 
 ### `serialize(state)`
 
-Allows a store to transform data before it leaves the system. It gives
-the store the opportunity to reduce non-primitive values into
+Allows a domain to transform data before it leaves the system. It gives
+the domain the opportunity to reduce non-primitive values into
 JSON.
 
 For example, if using
@@ -112,8 +112,8 @@ const Planets = {
 
 ### `register()`
 
-Returns an object mapping actions to methods on the store. This is the
-communication point between a store and the rest of the system.
+Returns an object mapping actions to methods on the domain. This is the
+communication point between a domain and the rest of the system.
 
 ```javascript
 import { addPlanet } from '../actions/planets'
@@ -135,7 +135,7 @@ repo.push(Actions.add, { name: 'earth' }) // this will add Earth
 
 ### `commit(next)`
 
-How should a store actually write to `repo.state`? This is useful for serializing a complex data structure, such as a `Map`, into form easier for public consumption:
+How should a domain actually write to `repo.state`? This is useful for serializing a complex data structure, such as a `Map`, into form easier for public consumption:
 
 ```javascript
 import Immutable from 'immutable'

docs/api/form.md

@@ -23,7 +23,7 @@ const repo = new Microcosm()
 
 const increaseCount = n => n
 
-repo.addStore('count', {
+repo.addDomain('count', {
   getInitialState() {
     return 0
   },