• Introduction
• Project Structure
• assets
  • css
    • loading-screen.css
    • main.css
  • images
    • favicon.png
    • logo.png
  • less
    • loading-screen.less
    • main.less
  • sass
    • loading-screen.scss
    • main.scss
• config
  • env
    • development.js
    • production.js
  • actions
  • auth
  • collections
  • connect
  • connections
  • local
  • models
  • react
  • reducers
  • redux
  • router
• initializers
  • .gitkeep
• src
  • actions
    • .gitkeep
  • collections
    • .gitkeep
  • components
    • Layout.js
    • Master.js
  • constants
    • ActionTypes.js
    • PayloadStates.js
  • decorators
    • UserIsAuthenticated.js
    • UserIsAuthorized.js
  • dialogs
    • .gitkeep
  • forms
    • .gitkeep
  • models
    • .gitkeep
  • reducers
    • .gitkeep
  • utils
    • auth.js
    • storageAvailable.js
• .babelrc
• .editorconfig
• .gitignore
• .lorerc
• db.json
• index.html
• index.js
• package.json
• package-lock.json
• postcss.config.js
• README.md
• routes.js
• webpack.config.js

constants/PayloadStates.js

This file is where you should store any custom PayloadStates required for your application. It is populated by default with the PayloadStates that Lore uses for the action and reducer blueprints.

PayloadStates are how you can tell what's happening to a resource within your application. For example, all data passed around a Lore app has the following format:

 const datum = {
   id: '1',
   cid: 'c1',
   state: [PayloadState],
   data: {
     title: 'Explain PayloadStates',
     isCompleted: false
   },
   error: {..some error object..}
 }

The state field always contains one of the PayloadState properties, like FETCHING or UPDATING.

This structure allows your components to be able to know and react to transitional states within your data. For example, if a component gets some data that has a state of FETCHING, it will know the data is currently being retrieved from the server and it should maybe show a spinner or some other kind of waiting message.

If the state is RESOLVED, the component will know the data is stable (nothing in flight) and if the state is UPDATING it would know that the application is currently waiting on confirmation from the server about a change to the data.

The ERROR_* states exist in case there's an error performing an operation on the server side and you want to articulate to the user what failed (Create, Update, Delete, etc.) and perhaps give them an opportunity to modify the request and try again.

Defaults

The default file included in new projects looks like this:

import { PayloadStates } from 'lore-utils';
import _ from 'lodash';

/*
 * The default payload states are listed below.
 */

export default _.defaults({
  // INITIAL_STATE: 'INITIAL_STATE',
  //
  // RESOLVED   : 'RESOLVED',
  // NOT_FOUND: 'NOT_FOUND',
  // DELETED: 'DELETED',
  //
  // CREATING: 'CREATING',
  // UPDATING: 'UPDATING',
  // DELETING: 'DELETING',
  // FETCHING: 'FETCHING',
  //
  // ERROR_CREATING: 'ERROR_CREATING',
  // ERROR_UPDATING: 'ERROR_UPDATING',
  // ERROR_DELETING: 'ERROR_DELETING',
  // ERROR_FETCHING: 'ERROR_FETCHING'
}, PayloadStates);