Main application settings

These are kept in a file named application.properties (or yml — from now on I’ll just use .properties` but keep in mind that you may use .yml): This file should reside inside the src\main\resources folder of your project and ideally contain all the settings your spring-boot application users. Some of these settings will be overriden by settings kept in the next source so they may have a default value or even be empty if they will be always overriden (or contain sensitive data like passwords), however I still prefer to list them all in this file even as placeholders to have a central source of all the settings that your Spring Boot application uses.

Profiles

A profile is a set of settings that can be configured to override settings from application.properties. Each profile is contained in a file named application-profilename.properties where profilename is the name of the profile. Now, a profile could configure anything you want, however for most projects I propose to have the following profiles:

• dev for your local development settings
• uat for your UAT server settings
• staging for your staging server settings
• prod for your production settings
• test for running your tests

(depending of course on what are your requirements, some projects may not need uat or staging but all projects should have a dev, a prod and a test profile). The configuration for these environemnts needs to be different for obvious reasons. For example when developing you may want to use a local database, when running tests an ephemeral in memory database and your production database when deploying to production. These profile configuration files will be stored inside your src\main\resources folder, right next to the application.properties, i.e you’ll have application-dev.properties, application-prod.properties, application-test.properties etc - and all these files will be kept in your VCS (and will also be jar-packaged since they will be contained in the resulting artifact).

How do you select which profile is active each time (i.e pick it when running the Spring Boot application under its corresponding environment)?

For tests, since they can be run by a different Main than the normal application, you should use the @ActiveProfiles annotation (for example @ActiveProfiles("test")) to make sure that the tests will run with the correct settings. So if the contents of your application-test.properties are config.value=Hello test! running this test should produce no errors:

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = SpringBootConfigApplication.class)
@ActiveProfiles("test")
public class SpringBootConfigApplicationTests {

    @Value("${config.value}")
    private String value;

    @Value("${spring.profiles.active}")
    private String profile;

    @Test
    public void contextLoads() {
        assertThat(value, is("Hello test!"));
        assertThat(profile, is("test"));
    }
}

To activate a different profile when running your Spring Boot applications you’ll need to use the spring.profiles.active setting, so if you set spring.profiles.active=prod in your application.properties and create the packaged jar (or war) then you’ll have the production settings when you run your application (i.e the contents of application-prod.properties will be used to override your application.properties). Of course, to deploy it to UAT, you’ll need to change spring.profiles.active to uat and re-create the packaged artifact — see some repetition and penal labour here? Definitely you don’t want to do re-create your artifacts for each of the environments you may want to deploy — we’ll see in the next sections how to improve this flow by overriding jar-packaged settings!

Overriding settings

All the above settings we’ve defined should be safely kept inside your VCS - however we wouldn’t like storing passwords or other sensitive data to a VCS! Sensitive settings should be empty (or have a default value) when saved to VCS and overriden by “local” settings.

Also, all the previous are jar-packaged and we definitely need a way to override them without messing with the artifacts (for example, we need to select the correct profile for running the application by overriding spring.profiles.active).

There two methods of overriding settings, and these are the last two methods of the four we discussed above:

A simple example

I’ve implemented a very simple redux example @ jsfiddle that increases and decreases a number using two buttons to support the above:

Its html is:

<div id='state_container'>0</div>
<button onclick='increase()'>+</button>
<button onclick='decrease()'>-</button>

while its javascript (es6) code is:

let reducer = (state=0, action) => {
  switch (action.type) {
    case 'INCREASE': return state+1
    case 'DECREASE': return state-1
    default: return state
  }
}
let store = Redux.createStore(reducer)
let unsubscribe = store.subscribe(() =>
  document.getElementById('state_container').innerHTML = store.getState()
)
window.increase = e => store.dispatch({
  type: 'INCREASE'
})

window.decrease = e => store.dispatch({
  type: 'DECREASE'
})

The HTML just displays a div which keeps the current number value and two buttons that call the increase and decrease functions.

Now, for the javascript, we create a reducer function that gets the previous state value (which initially is the number 0) and the action that is dispatched. When the reducer is called it will check if the action type is ‘INCREASE’ or ‘DECREASE’ and correspondigly increase or decreases the state, which is just that number. Normally, the state will be a (rather fat) object.

We then create a store which gets the reducer as its only parameter then and call its subscribe method passing a callback. This callback will be called whenever the state is changed - in our case, the callback just updates the div with the current number from the state. Finally, the increase and decrease methods that are called when the butts are clicked will just dispatch the corresponding action.

Please notice that in the above example I didn’t use action creators for simplicity. For completeness, the action creator for increase would be something like

const increaseCreator = () => {
  type: 'INCREASE'
}

i.e it would just return an INCREASE action and window.increase would be window.increase = e => store.dispatch(increaseCreator()). Notice that the increaseCreator is called (has ()) so that dispatch will receive the resulting action object as a parameter.

The flow of the data when the increase button is clicked is the following:

• button.onClick
• increase()
• increaseCreator() (if we used action creators - this a param to dispatch so it will be called first)
• store.dispatch({type: 'INCREASE' })
• reducer(current_state, {type: 'INCREASE'})
• Reducer returns the new state (state+1)
• callback()
• value is updated

Having one and only one store/state makes the flow of the data crystal and resolves some of the dillemas I had when using the original Flux architecture! Some people may argue that although a single reducer function is nice for the above simple demo, having a huge (spaghetti-like) switch statement in your reducer is not a very good practice - thankfully redux has a bunch of tools that will presented later and greatly help on this (seperating the reducing logic, using different modules for each module etc).

Interlude: So what’s a reducer?

I’d like to talk a bit about the “reducer”, mainly for people not familiar with functional programming (although people writing Javascript should be familiar with functional programming since Javascript has functional features) to clarify my statement above that the redux philosophy is close to functional programming.

One basic concept of functional programming is the concept of “map-reduce”. Mapping means calling a function (let’s call it mapper) for all elements of a list and creating a new list with the output of each individual call. So, a mapper gets only one parameter, the current value of the list. For example the “double” mapper, defined like let double = x => x*2 would “map” the list [1,2,3] to [2,4,6].

Reducing means calling a function (let’s call it reducer) for all elements of a list and creating a single value that accumulates the result of each individual call. This can be done because the reducer gets two parameters, the accumulated value of the list until this point and the current value of the list. Also, when doing a reduce we need to define a starting value for the accumulator. For example, the “sum” reducer, defined like let sum = (s=0, x) => s+x, (which has an initial value of 0), would “reduce” the list [1,2,3] to 6 by calling the sum reducer three times:

tmp1 = sum(0, 1); // tmp1 = 1
tmp2 = sum(tmp1, 2); // tmp2 = 3
result = sum(tmp2, 3); // result = 6

So, a redux reducer is actually a (rather complex) functional reducer, getting the current state (as the accumulated value) and each individual action as the value and returning the new state which is the result of applying this action to the state!

Three extra things to make sure about your redux reducers are that:

• they should have an initial value (with the initial state of the application) or know how to handle an undefined initial state
• they must not not mutate (change) the state object but instead create and return a new one (not allowing object mutations is a general practice in functional programming but in redux also helps to quickly apply the changes to the components)
• always return a valid state as a result (or else the application will have invalid state)

What about react-redux?

React-redux is a rather simple framework that offers two helpful utilities for integrating redux with React:

• A connect function that “connects” React components to the redux store. This function (among others) retrieves a callback parameter that defines properties that will be passed to that component and each one will be (magically) mapped to state properties.
• A Provider component. This is a parent component that can be used to (magically) pass the store properties to its children components.

Please notice that nothing actually magical happens when the store properties are passed to the children components through connect and Provider! this is accomplished through the react context feature that allows you to “pass data through the component tree without having to pass the props down manually at every level”. So connect``ed components used context to retrieve the store properties that have been passed to the context by the ``Provider.

How react-redux is used be made more clear with another jsfiddle that will convert the previous example to React and react-redux:

The html is just <div id='container'></div> since the components will be rendered through react, while the es6/jsx code is:

let reducer = (state=0, action) => {
  switch (action.type) {
    case 'INCREASE': return state+1
    case 'DECREASE': return state-1
    default: return state
  }
}

let store = Redux.createStore(reducer)

class RootComponent extends React.Component {
  render() {
    let {number, increase, decrease} = this.props
    return <div>
      <div>{number}</div>
      <button onClick={e=>increase()}>+</button>
      <button onClick={e=>decrease()}> - </button>
    </div>
  }
}

let mapStateToProps = state => ({
  number: state
})

let mapDispatchToProps = dispatch => ({
  increase: () => dispatch({type: 'INCREASE'}),
  decrease: () => dispatch({type: 'DECREASE'})
})

const ConnectedRootComponent = ReactRedux.connect(
    mapStateToProps, mapDispatchToProps
)(RootComponent)

ReactDOM.render(
  <ReactRedux.Provider store={store}>
    <ConnectedRootComponent />
  </ReactRedux.Provider>,
  document.getElementById('container')
)

As we can see, the reducer and store are the same as the non-react version. What is new here is that I’ve added a React RootComponent that has two properties, one named number and one named dispatch that can be used to dispatch an action through the store.

Using react-redux’s connect function we create a new component, ConnnectedRootComponent which is a new component with the redux-enabled functionality (i.e it will have access to store). The connect() function takes a bunch of optional arguments. I won’t go into much detail since its a little complex (the react-redux documentation is clear enough), however in our example we have defined two objects named mapStateToProps and mapDispatchToProps which are passed to connect and define how the state and the dispatch are mapped to the properties the connected component will have.

The mapStateToProps is a function that will be called whenever the store’s state changes and should return an object whose attributes will be passed to the connected component as properties. In our example, we return an object with a number attribute having the current state (which don’t forget that is just a number) as its value - that’s why we can extract the number attribute from this.props when rendering.

The mapDispatchToProps as we use it, once again returns an object whose attributes will be passed to the connected component and will dispatch actions when called.

Of course, in order for the ConnectedRootComponent to actually have these properties that we passed through connect, it must be enclosed in a <Provider> parent component (so that the correct react context will be initialized). Notice that this is recursive so if we had something

<Provider store={store}>
  <Component1>
    <Component2>
      <ConnectedComponent>
      </ConnectedComponent>
    </Component2>
  </Component1>
</Provider>

the <ConnectedComponent> would still get the props (dispatch + state slice) we mentioned above even if its parent components were not connected.

Although we could have avoided using react-redux by passing the store directly to <RootComponent> and subscibing to the store changes from the RootComponent‘s componentWillMount method, the added-value of react-redux is that using connect and Provider we could pass dispatch and state slices deep inside our component hierarchy without the need to explicitly pass the store to each individual component and also that react-redux will make optimizations so that the each connected component will be re-rendered only when needed (depending on the state slice it uses) and not for every state change. Please be warned that this does not mean that you should connect everything so that everything will have access to the global state and be able to dispatch actions. You should be very careful to connect only the components that really need to be connected (redux calls them container components) and pass dispatch and state as properties to their children (which are called presentational components). Also, each connected component should receive only the part of the global state it needs and not everything (so that each particular component will update only when needed and not for every state update). The above is absolutely necessary if you want to crate re-usable (DRY) and easily testable components. I’ll discuss this a little more when describing the sample project.

Finally, notice how easy it is to create reusable container components using mapStateToProps and mapDispatchToProps: Both the way the component gets its state and calls its actions are defined through these two objects so you can create as many connected objects as you want by passing different mapStateToProps and mapDispatchToProps - more on this later.

Other libraries used

React (and redux) have a big ecosystem of great libraries. Some of these have been used for this project and will also be discussed in this article:

• redux-thunk: This is a nice add-on for redux that generalizes action creators.
• redux-form: A better way to use forms with react and redux. Always use it if you have non-trivial forms.
• react-router: A library to create routes for single page applications with React.
• react-router-redux (ex redux-simple-router): This library will help integrating react-router with redux.
• history: This is used bt react-router to crete the page history (so that back forward etc work).
• react-notification: A simple react component to display notifications.

The triplet react-router, react-router-redux and history needs to be used for projects that enable client side routing. The redux-form is really useful if you have non-trivial forms in your projects - you may skip it if you don’t use forms or for example you use a form for searching/filtering with a single input. react-notification just displays notifications, you can easily exchange it with other similar components or create your own.

redux-thunk?

Now, about redux-thunk. I won’t go into much detail here, you can read more about it in this great SO answer, however I’d like to point out here that everything that can be done with redux-thunk can also be done without it so you may safely skip it if you feel that you don’t really need it in your project.

But what does it do? Well, redux-thunk allows you to create action creators that don’t only return action objects but can do various other things, like calling other actions or dispatching actions conditionally. When using redux-thunk, an action returns a function that can do any of the above mentioned things, something like this:

const thunkAction = () => {
  return (dispatch, getState) => {
    // here you may
    // dispatch other actions (more than one) using the provided dispatch() parameter
    // or
    // check the current state using the getState() parameter and do conditional dispatches
    // or
    // call functions asynchronously so that these will use the provided
    // dispatch function when they return
  }
}

Let’s say that we wanted to implement an asynchronous, ajax call. If we don’t want to use redux thunk, then we need to create a normal function that gets dispatch as an argument, something like this:

import {showLoadingAction, hideLoadingAction, showDataAction } from './actions'

const getData = (dispatch) => {
  dispatch(showLoadingAction())
  $.get(data_url, data => {
      dispatch(hideLoadingAction())
      dispatch(showDataAction(data))
  })
}

The main problem with this approach is that the getData functions is not called like a normal action creator (like showLoadingAction, hideLoadingAction and showDataAction) since it actually returns nothing (so nothing will be dispatched), so you’ll need to remember to call it directly and pass it the dispatch instead of passing its return value to dispatch!

If however we used thunk, then we’d have something like this:

const getDataThunk = () => {
  return (dispatch, getState) => {
    dispatch(showLoadingAction())
    $.get(data_url, data => {
        dispatch(hideLoadingAction())
        dispatch(showDataAction(data))
    })
  }
}

Now, the above can be used like a normal action (i.e it can be called using dispatch(getDataThunk())). That’s more or less the main advantage of redux-thunk: You are able to create thunk action creators that can be called like normal actions and can do more complex things than just returning action objects so you don’t have to remember how to call each function.

I have to repeat again that everything that you be done with thunk action creators, can also be done with normal functions that get dispatch as a paremeter - the advantage of thunk action creators is that you don’t need to remember if an action creator needs to be called through disaptch(actionCreator()) or actionCreator(dispatch).

In this tutorial you’ll see heavy use of redux-thunk. This is just my personal preference - you may use it less or not at all (however, if you’ve configured your project to use redux-thunk then I propose to go all the way and use it all the time for those more complex action creators).

main.js

This module is used as an entry point for browserify (i.e we call browserify with browserify main.js -o bundle.js ) and uses components defined elsewhere to create the basic structure of our application. Let’s take a look at the important part of it:

const About = () => {
    return <div>
        <h2>About</h2>
        <Link to="/">Home</Link>
    </div>
}

render((
    <Provider store={store}>
        <Router history={history}>
            <Route path="/" component={App}>
                <IndexRoute component={BookPanel}/>
                <Route path="/book_create/" component={BookForm} />
                <Route path="/book_update/:id" component={BookForm} />

                <Route path="/authors/" component={AuthorPanel} />
                <Route path="/author_create/" component={AuthorForm} />
                <Route path="/author_update/:id" component={AuthorForm} />

                <Route path="/about" component={About}/>
                <Route path="*" component={NoMatch}/>
            </Route>
        </Router>
    </Provider>
  ), document.getElementById('content')
)

We can see the well-known render function from ReactDOM that gets a component and a DOM element to mount it to. The domponent we provide to render is the Provider from react-redux we talked about before in order to enable all children components to use connect to have access to the store properties and dispatch. This is the usual approact with react-redux: The outer component will always be the “Provider“.

The Provider component gets one parameter which is the store that redux will use. We have initialized our store in a different module which I will present below.

Inside the Provider we are defining a Router from react-router. This should be the parent component inside which all client-side routes of our appliccation are defined. The Router gets a history parameter which is initialized elsewhere (stick with me for now, I will talk about it later).

Now, inside Router we are defining the actual routes of this application. As we can see, there’s a parent Route that is connnected to the App component which actually contains everything else. The parent route contains an IndexRoute whose corresponding component (BookPanel) is called when no route is defined and a bunch of normal Route components whose components are called when the url matches their part. Notice how we pass parameters to urls (e.g /book_update/:id) and the match-all route (<Route path="*" component={NoMatch}/>).

Finally as an example of a routed-to component, notice the About component which is rendered when the route is /about. This is just a normal react component that- will be rendered inside the App component - the Link is a react-router component that renders a link to a defined route.

store.js

The store.js module contains the definition of the global store of our application (which is passed to the Provider). Here, we also define the history object we passed to the parent Router.

import { reducer as formReducer } from 'redux-form';

import createHistory from 'history/lib/createHashHistory'

// Opt-out of persistent state, not recommended.
// https://github.com/reactjs/history/blob/master/docs/HashHistoryCaveats.md
export const history = createHistory({
    queryKey: false
});

First of all, we see that our history object is of type HashHistory (more info about history types) and I’ve also opted out of using queryKey. If I hadn’t used the queryKey: false configuration then there’d be a ?_k=ckuvup query parameter in the URL. Now, this parameter is actually useful (it stores location state not present in the URL for example POST form data) but I don’t need it for this example (and generally I prefer cleaner URLS) - but if you don’t like the behavior of your history without it then go ahead and add it.

Also, notice that I’ve used HashHistory which will append a # to the URL and the client-side URL will come after that, so all URLs will be under (for example) /index.html like /index.html#/authors. The react-router documentation recommends using BrowserHistory which uses normal (clean) urls — so instead of /index.html#/authors we’d see /authors if we’d used BrowserHistory.

The problem with BrowserHistory is that you’ll need to configure correctly your HTTP server so that it will translate every URL (/foo) to the same URL under /index.html (/index.html#/foo) - as can be understood, without that configuration the HTTP server doesn’t know anything about the client side urls so when the webserver sees /authors it will pass /authors to your server side framework (which will return a 404 error) - that’s why this translation is needed.

However, in my case, I don’t think that configuring your HTTP server to rewrite urls is worth the trouble and also I do really prefer using # for client-side urls! This is a common patter, recognised by everybody and even without the HTTP server-configuration part I’d still prefer HashHistory over BrowserHistory - of course this is just my opinion, feel free to use BrowserHistory if you don’t like the hash #!

The next block of code from the store module creates the most important thing of a redux application, its reducer along with the global store:

const reducer = combineReducers(Object.assign({}, {
        books,
        notification,
        ui,
        categories,
        authors,
    }, {
        routing: routeReducer
    }, {
        form: formReducer
    })
)

const reduxRouterMiddleware = syncHistory(history)

const store = createStore(reducer, applyMiddleware(
    thunk, reduxRouterMiddleware
));

export default store

Please notice above that the Object.assign method is used - I’ll talk about it later — however, another common ES6 idiom that I’ve used here is that when you define an object you can change { x: x } to { x } (so {books} means {'books': books}).

The combineReducers function is provided by redux and is a helper function that helps you in … combining reducers! As you see, I’ve combined the reducers defined in this application (books, notification, ui, categories, authors) with the reducers of react-router-redux and redux-form to create the reducer. We’ll talk a bit in the next interlude on what does combining reducers is.

The routeReducer and formReducer reducers are provided by react-router-redux and refux-form to properly handle the routing and form-related actions.

The remaining of the code generates the store: First of all, a middleware (please see next-next interlude for more) is created with syncHistory that allows actions to call history methods (so that when the URL is changed through actions they will be reflected to the history). Then, the createStoreWithMiddleware function is called to generate the store that will be passed to the Provider. This function takes the reducer as a parameter along with any store enchancers that we’d like to apply. A store enchancer is a function that modifies the store. The only store enchanccer that we use now is the output of the applyMiddleware function that combines the two middlewares we’ve defined (one is for redux thunk, the other is for syncHistory). I know, your head hurts but I’ll try to clear things out below.

{
  'data': {},
  'ui': {}
}

const combineReducers2 = o => {
  return (state={}, action) => {
      const mapped = Object.keys(o).map(k => (
          {
              key: k,
              slice: o[k](state[k], action) // call k sub-reducer and get result
          }
      ))
      const reduced = mapped.reduce((s, x)=>{
          s[x['key']]=x['slice']
          return s
      }, {})

      return reduced;
  }
}

const combineReducers3 = o => (state={}, action) => Object.keys(o).map(k => [
    k, o[k](state[k], action)
]).reduce((s, x) => Object.assign(s, {
    [x[0]]: x[1]
}), {})

(action) => reduxRouterMiddleware(thunk(dispatch(action)))

const middleware = store => next => action => {
  //
}

function thunkMiddleware({ dispatch, getState }) {
  return next => action =>
    typeof action === 'function' ?
      action(dispatch, getState) :
      next(action);
}

const logStateMiddleware = ({dispatch, getState}) => next => action => {
  // log the action type
  console.log(action.type, getState())
  // now we must call next(action) to propagate and finally dispatch the action object
  next(action)
}

reducers.js

This module contains the definition for our own defined sub-reducers that we combined in the previous paragraph (books, notification, ui, categories, authors) to create the global reducer of the application. I’ve put everything in a single file, however it is more common to create a reducers directory and put every sub-reducer inside it as a different module. Let’s start reviewing the code of the reducers.js module:

export const notification = (state={}, action) => {
    switch (action.type) {
        case 'SHOW_NOTIFICATION':
            let { notification_type, message } = action
            return Object.assign({}, state, {
                message,
                notification_type,
            })
        case 'CLEAR_NOTIFICATION':
            return {}
    }
    return state;
}


export const ui = (state={}, action) => {
    switch (action.type) {
        case 'IS_LOADING':
            return Object.assign({}, state, {
                isLoading: action.isLoading
            });
            break;
        case 'IS_SUBMITTING':
            return Object.assign({}, state, {
                isSubmitting: action.isSubmitting
            });
            break;
    }
    return state;
}

The notification and ui are two sub-reducers that control the state of the notification popup and if the application is loading / is submitting. I won’t go into much detail about them, they are really simple. However, notice that they both create a new state object for each of their actions. To achieve this, the Object.assign() method is used. This method is defined like this: Object.assign(target, ...sources). Its first parameter is an object (a new, empty object) while the rest parameters (sources) are other objects whose properties will be assigned target. The rightmost members of sources overwrite the previous ones if they have the same names. So, for example the code

Object.assign({}, state, {
    rows: action.books.results,
    count: action.books.count,
});

creates a new object which will have all the properties of the current state with the exception of the rows and count attributes which will get their values from the action. This is a common idiom in redux and you are going to see it all the time so please make sure that you grok it before continuing. Also, notice that the new state is a new, empty object in which all the attributes of the new state are copied - this is because the old state cannot be mutated.

Now we’ll see the reducer that handles books. Before understanding the actual reducer, I will present the initial value of the books state slice:

//http://stackoverflow.com/a/5158301/119071
function getParameterByName(name) {
    var match = RegExp('[?&]' + name + '=([^&]*)').exec(window.location.hash);
    return match && decodeURIComponent(match[1].replace(/\+/g, ' '));
}

const BOOKS_INITIAL = {
    rows: [],
    count: 0,
    page: 1,
    sorting: getParameterByName('sorting'),
    search: getParameterByName('search'),
    book: {},
}

As we see, the BOOK_INITIAL constant is used to setup an initial state for the books slice of the global state. The BOOKS_INITIAL attributs are:

• rows: The rows of the book table
• count: The number of rows that are displayed
• page: The current page we are on
• sorting: User-defined sorting
• search: User-search / filtering
• book: The data of the book to be edited/displayed

The BOOK_INITIAL constant gets the sorting and the search initial values from the URL to allow these parameters to be initialized from the URL (so that using a url like #?search=foo will show all books containing foo). To get the parameters from the URL I’m using the getParameterByName function. Now, the actual reducer is:

export const books = (state=BOOKS_INITIAL, action) => {
    let idx = 0;
    switch (action.type) {
        case 'SHOW_BOOKS':
            return Object.assign({}, state, {
                rows: action.books.results,
                count: action.books.count,
            });
            break;
        case 'SHOW_BOOK':
            return Object.assign({}, state, {
                book: action.book
            });
            break;
        case 'CHANGE_PAGE':
            return Object.assign({}, state, {
                page: action.page
            });
            break;
        case 'TOGGLE_SORTING':
            return Object.assign({}, state, {
                sorting: (state.sorting==action.sorting)?('-'+action.sorting):action.sorting
            });
            break;
        case 'CHANGE_SEARCH':
            return Object.assign({}, state, {
                search: action.search
            });
            break;
        case 'ADD_BOOK':
            return Object.assign({}, state, {
                book: action.book,
                count: state.count+1,
                rows: [
                    ...state.rows,
                    action.book,
                ]
            });
        case 'UPDATE_BOOK':
            idx = state.rows.findIndex( r => r.id === action.book.id)
            if(idx==-1) {
                return Object.assign({}, state, {
                    book: action.book
                });
            } else {
                return Object.assign({}, state, {
                    book: action.book,
                    rows: [
                        ...state.rows.slice(0, idx),
                        action.book,
                        ...state.rows.slice(idx+1),
                    ]
                });
            }
            break;
        case 'DELETE_BOOK':
            idx = state.rows.findIndex( r => r.id == action.id)
            if(idx==-1) {
                return Object.assign({}, state, {
                    book: undefined
                });
            } else {
                return Object.assign({}, state, {
                    book: undefined,
                    count: state.count-1,
                    rows: [
                        ...state.rows.slice(0, idx),
                        ...state.rows.slice(idx+1),
                    ]
                });
            }
            break;
    }
    return state;
}

The books subreducer handles the SHOW_BOOKS, SHOW_BOOK, CHANGE_PAGE, TOGGLE_SORTING and CHANGE_SEARCH actions by retrieving the paramaters of these actions and returning a new books-state-slice object with the correct parameters using Object.assign.

The ADD_BOOK action is a little more complicated: This action will be dispached when a new book is added with the data of that new book as a parameter (action.book). In order to make everything easier, I just append the new book to the end of the books that are displayed on the current page and increase the count number (I also set the new book to be the book attribute of the state). This means that the newly created book will not go to its correct place (based on the ordering) and that the visible items will be more than the ajax page coun (also notice that if you add another book then the visible items will also be increased by one more). This is not a problem (for me) since if the user changes page or does a search everything will fall back to its place. However, if you don’t like it there are two solutions, one easier and one more difficult:

• Easier solution: When adding a book just invalidate (make undefined) the books state attribute. This will result in an ajax call to reload the books and everything will be in place. However the user may not see the newly added book if it does not fall to the currently selected page (and there’d be an extra, unnecessary ajax call)
• Harder solution: Depending on the sorting you may check if the current books should be displayed or not on the current page and push it to its correct place (and remove the last item of rows so that count is not increased). Once again, the newly book may no be displayed at all if it does not belong to the visible page

The UPDATE_BOOK and DELETE_BOOK actions are even more complex. I’ll only explain update, delete is more or less the same (with the difference that update has the updated book as an action parameter while delete has only its id as an acton parameter): First of all we check if the updated book is currently displayed (if one of the books of rows has the same id as the updated book). If the book is not displayed then only the current edited book is set to the new state. However, if it is displayed then it would need to be updated because the rows array does not know anything about the updated values of the book!

So, inside the else branch, the idx variable will hold its current index and the rows attribute of the new state will get the following value:

[
    ...state.rows.slice(0, idx),
    action.book,
    ...state.rows.slice(idx+1),
]

The ... spread operator expands an array so, for example [ ...[1,2,3] ] would be like [1,2,3] and the slice method gets two parameters and returns a copy of the array elements between them. Using this knowledge, we can understand that the above code returns an array ([]) that contains the books of rows from the first to the updated one (not including the updated one), the updated book object (which we get from action) and the rest of the books of rows (after the updated one).

The code for the authors and categories sub-reducers does not have any surprises so I won’t go into detail about it.

const AUTHORS_INITIAL = {
    // ...
}
export const authors = (state=AUTHORS_INITIAL, action) => {
    // ...
}

const CATEGORIES_INITIAL = {
    // ...
}

export const categories = (state=CATEGORIES_INITIAL, action) => {
    // ...
}

{
  books: {},
  notification: {},
  ui: {},
  categories: {},
  authors: {},
  routing: {},
  form: {},
}

actions.js

The actions.js module should probably have been named action_creators.js since it actually contains redux action creators. Also, a common practice is create a folder named actions and put there individual modules that contain action creators for the sub-reducers (in our case, for example there would be books.js, authors.s etc).

In any case, for simplicity I chose to just use a module named actions.js and put everything there. One important thing to keep in mind is that actions.js contains both normal action creators (i.e functions that return actions and should be “dispatched”) and thunk action creators (i.e functions that not necessarily return actions but can be “dispatcher”) - please see the discussion about redux-thunk on a previous paragraph.

First of all, there’s a bunch of some simple action creators that just return the corresponding action object with the correct parameters. Notice that the action creators that end in *Result are called when an (async) ajax request returns, for example showBooksResult will be called when the book loading has returned and pass its result data to the reducer. The other action creators change various parts of the state object, for example loadingChanged will create an action that when dispatched it will set ui.isLoading attribute to the action parameter.

showBooksResult(books) for "SHOW_BOOKS",
showBookResult(book) for "SHOW_BOOK",
addBookResult(book) for "ADD_BOOK",
updateBookResult(book) for "UPDATE_BOOK",
deleteBookResult(id) for "DELETE_BOOK",

showAuthorsResult(authors) for "SHOW_AUTHORS",
showAuthorResult(author) for "SHOW_AUTHOR",
addAuthorResult(author) for "ADD_AUTHOR",
updateAuthorResult(author) for "UPDATE_AUTHOR",
deleteAuthorResult(id) "DELETE_AUTHOR",

showCategoriesResult(categories) for "SHOW_CATEGORIES",
showSubCategoriesResult(subcategories) for "SHOW_SUBCATEGORIES",
loadingChanged(isLoading) for "IS_LOADING",
submittingChanged(isSubmitting) for "IS_SUBMITTING",
toggleSorting(sorting) for "TOGGLE_SORTING",
changePage(page) for "CHANGE_PAGE",
changeSearch(search) for 'CHANGE_SEARCH',
showSuccessNotification(message) for 'SHOW_NOTIFICATION' (type: success),
showErrorNotification(message) for 'SHOW_NOTIFICATION', (type: error)
hideNotification() for 'CLEAR_NOTIFICATION'

The following two are thunk action creators that are called when either the user sorting or the search/filtering parameters of the displayed books are changed:

export function changeSearchAndLoadBooks(search) {
    return (dispatch, getState) => {
        dispatch(changeSearch(search))
        history.push( {
            search: formatUrl(getState().books)
        } )
        dispatch(loadBooks())
    }
}

export function toggleSortingAndLoadBooks(sorting) {
    return (dispatch, getState) => {
        dispatch(toggleSorting(sorting))
        history.push( {
            search: formatUrl(getState().books)
        } )
        dispatch(loadBooks())
    }
}

Notice that these are thunk action creators (they return a function) and the important thing that they do is that they call two other action creators (toggleSorting or changeSearch and loadBooks) and update the URL using history.push. The history object is the one we had created in the store.js and its push method changes the displayed URL. This method uses a location descriptor that contains an attribute for the path name and an attribute for the query parameters - in or case we just want to update the query parameters (i.e #/url/?search=query1&sorting=query2), so we pass an obect with only the search attribute. The formatUrl function, to which the books state slice is passsed, is a rather simple function that checks if either the sorting or the search should exist in th URL and returns the full URL. This function is contained in the util/formatters.s module.

The following thunk action creators are used for asynchronous, ajax queries:

export function loadBooks(page=1) {
    return (dispatch, getState) => {
        let state = getState();
        let { page, sorting, search } = state.books
        let url = `//127.0.0.1:8000/api/books/?format=json&page=${page}`;
        if(sorting) {
            url+=`&ordering=${sorting}`
        }
        if(search) {
            url+=`&search=${search}`
        }
        dispatch(loadingChanged(true));
        $.get(url, data => {
            setTimeout(() => {
                dispatch(showBooksResult(data));
                dispatch(loadingChanged(false));
            }, 1000);
        });
    }
}


export function loadBookAction(id) {
    return (dispatch, getState) => {
        let url = `//127.0.0.1:8000/api/books/${id}/?format=json`;
        dispatch(loadingChanged(true));
        $.get(url, function(data) {
            dispatch(showBookResult(data));
            dispatch(loadingChanged(false));
            dispatch(loadSubCategories(data.category));
        });
    }
}

export function loadAuthors(page=1) {
    // similar to loadBooks
}


export function loadAuthor(id) {
    // similar to loadBook
}

export function loadCategories() {
    // similar to loadBooks
}

export function loadSubCategories(category) {
    return (dispatch, getState) => {

        if(!category) {
            dispatch(showSubCategoriesResult([]));
            return
        }
        let url = `//127.0.0.1:8000/api/subcategories/?format=json&category=${category}`;

        $.get(url, data => {
            dispatch(showSubCategoriesResult(data));
        });
    }
}

The loadBooks thunk action creator creates the URL parameters that should be passed to the REST API using the getState() method that returns the current state. It then dispatches the loadingChanged action so that the ui.isLoading will be changed to true. After that it asynchronously calls the load books REST API passing it the created url and returns. Since this is a thunk action there’s no problem that nothing is returned. When the ajax call returns it will dispatch the showBooksResult, passing the book data to change the state with the loaded book data and the loadingChanged to hide the loading spinner. Also, please notice that I’ve put the return of the ajax call inside a setTimeout to emulate a 1 second delay and be able to see the loading spinner.

I may have used setTimeout in some other places to make sure to be able to emulate server-side delays so please don’t forget to remove these “setTimeout“s from your code!

The loadBook is more or less the same - however here only a single book’s data will be loaded. When this book is loaded the loadSubCategories action will also be dispatched, passing it the loaded book’s category (so that the correct subcategories based on the category will be displayed to the form).

I won’t go into any detail about the other thunk action creators, they are simpler than those we’ve already described, except loadSubCategories: This one, checks if there’s a category and if not it will just set the displayed subcategories to and empty list (by dispatching showSubCategoriesResult([])). If the category is not empty, it will retrieve asynchronously the subcategories of the passed category.

components/app.js

We’ll now start explaining the actual react components (modified to be used through redux of course). The parent of all other components is the App which, as we’ve already seen in main.js is connected with the parent route:

class App extends React.Component {

    render() {
        const { isLoading } = this.props.ui;
        return <div>

            {this.props.children}

            <NotificationContainer />
            <LoadingContainer isLoading={isLoading} />

            <br />

            <StatPanel bookLength={this.props.books.count} authorLength={this.props.authors.rows.length} />
            <Link className='button' to="/">Books</Link>
            <Link className='button' to="/authors/">Authors</Link>

        </div>
    }

    componentDidMount() {
        let { loadBooks, loadAuthors } = this.props;

        if(this.props.books.rows.length==0) {
            loadBooks();
        }
        if(this.props.authors.rows.length==0) {
            loadAuthors();
        }
    }
}

const mapStateToProps = state => ({
    books:state.books,
    authors:state.authors,
    ui:state.ui,
})

const mapDispatchToProps = dispatch => bindActionCreators({
    loadBooks, loadAuthors
}, dispatch)

export default connect(mapStateToProps, mapDispatchToProps)(App);

As we can see, there’s an internal component (named App) but we export the connect``ed component. One interesting thing to notice is that ``App is an ES6 class based react component (i.e it extends React.Component — I’ll talk a bit about these components while taking a look at the BookSearchPanel which has some more interesting features).

Concerning the exported, connected component, it uses mapStateToProps for defining the state attributes that should be passed as properties to the componnt (state.{books, authors, ui}) and mapDispatchToProps for defining the props methods that will dispatch actions. To make mapDispatchToProps more compact I’ve used the bindActionCreators method from redux. This method gets an object whose values are action creators and the dispatch (from store) and returns an object whose values are the dispatch-enabled corresponding action creators. So, in our case the returned object would be something like:

{
    loadBooks: () => dispatch(loadBooks()),
    loadAuthors: () => dispatch(loadAuthors()),
}

This object of course could be created by hand, however bindActionCreators would be really useful if we wanted to dispatch lots of actions in a component (or if we had seperated our action creators to different modules) — we could for example do something like this:

import * as actions from '../actions'

const mapDispatchToProps = dispatch => bindActionCreators(actions, dispatch)

The import * statemenet will create an object named item that will have all the exported actions and then bindActionCreators will return an object that dispatches these actions — passing this mapDispatchToProps to connect will allow your component to call every action and automatically dispatch it.

The internal component returns a <div /> containing, among others {this.props.children} - this will be provided by rendering the child routes. It also renders a NotificationContainer to render the notifications, a LoadingContainer to display a css “loading” spinner and a StatPanel to display some stats about books and authors. It also renders two Links one for the books table and one for the authors table.

Beyond these, when the component is mounted it checks if the authors and books have been loaded and if not, it dispatches the loadBooks and loadAuthors actions (remember, because we used mapDispatchToProps by calling these methods from props they’ll be automatically dspatched when called).

Let’s take a quick look at the three small components that are contained in App

const NotificationContainer = (props) => {
    let { message, notification_type } = props.notification;
    let { onHide } = props;
    let isActive = message?true:false;
    let color;

    switch(notification_type) {
        case 'SUCCESS':
            color = colors.success
            break;
        case 'ERROR':
            color = colors.danger
            break;
        case 'INFO':
            color = colors.info
            break;
    }

    return <Notification
        isActive={isActive}
        message={message?message:''}
        dismissAfter={5000}
        onDismiss={ ()=>onHide() }
        action='X'
        onClick={ ()=>onHide() }
        style={{
            bar: {
                background: color,
                color: 'black',
                fontSize: '2rem',
            },
            active: {
                left: '3rem',
            },
            action: {
                color: '#FFCCBC',
                fontSize: '3rem',
                border: '1 pt solid black'
            }
        }}
    />
}

let mapStateToProps = state => ({
    notification: state.notification
})

let mapDispatchToProps = dispatch => ({
    onHide: () => {
        dispatch(hideNotification())
    }
})

export default connect(mapStateToProps, mapDispatchToProps)(NotificationContainer);

export default ({isLoading}) => <div>
    {isLoading?<div className="loading">Loading&#8230;</div>:null}
</div>

components/BookPanel.js

Continuing our top-down approach on exploring the project, we’ll now talk about the BookPanel component which is displayed by the IndexRoute. Before talking about the actual component, I’d like to present the getCols function that is used to create an array of the columns that will be displayed by the Table we render in this panel.

As we can see, the getCols gets one parameter which is the sort method — this method gets a string and uses it to toggle sorting by this string. We use a function to create the columns instead of a constant because that sort_function needs to dispatch an action — dispatch is available from the props that the functional BookPanel component receives so the function will be called from inside that functional component.

Each column, has up to four parameters:

• A key which is the attribute of the row object to display
• A title which is the column title
• A format (optional) which may be used to display the value of that column and
• A sorting (optional) which is a function that will be called when the column title is clicked (so that the sorting is changed ) - this attribute is created using the sort_method

We’ll see how these attributes are used by the Table in the corresponding section. Five columns have been defined: id (which, when clicked will update the book that’s where format is used), title, category_name, publish_date and author_name:

const getCols = sort_method => [
    {
        key: 'id',
        label: 'ID',
        format: x=><Link to={`/book_update/${x.id}/`}>{x.id}</Link>,
        sorting: sort_method('id')
    },
    {key: 'title', label: 'Title', sorting: sort_method('title')},
    {key: 'category_name', label: 'Category', sorting: sort_method('subcategory__name')},
    {key: 'publish_date', label: 'Publish date', sorting: sort_method('publish_date')},
    {key: 'author_name', label: 'Author', sorting: sort_method('author__last_name')},
]

The actual (exported) BookPanel is a connected component - we need to use connect because we can’t actually pass properties or dispatch to this component since it is rendered through a route (and not as a child of another component), so it must be connected to the store through connect to be able to receive state attributes and dispatch. We pass the books state slice as a property using mapStateToProps and use the same techique as before in App with bindActionCreators to create auto-dispatchable actions.

As we can see, after retrieving the needed properties from the books state slice and the actions to dispatch, we define an onSearchChanged function that will be passed to the BookSearchPanel to be called when the search query is changed.

Next, the sort_method is defined. This is a function that gets a key parameter and returns another function that dispatches toggleSortingAndLoadBooks passing it that key. This is the parameter that is passed to getCols. So, for example for the id, the result of the sort_method would be the following function: () => toggleSortingAndLoadBooks('id').

Finally, the BookPanel renders the following:

• A BookSearchPanel passing it the search property and the onSearchChanged action
• A Link to create a new book
• A Table passing it the sorting and rows parameters and the cols constant we just defined
• A PagingPanel passing it the total number of books (count), the current page (page) and two methods onNextPage and onPreviousPage that will be called when switch to the next or previous page.

As we can see, the onNextPage and onPreviousPage functions dispach the changePage action passing it the page to change to and reload the books by dispatch loadBooks. Instead of this we could create a changePageAndLoadBooks thunk action creator that would call these two methods when dispatched (similarly to how changeSearchAndLoadBooks and toggleSortingAndLoadBooks have been implemented) - I’m leaving it like this to show all possibilities:

const BookPanel = (props) => {
    const { rows, count, page, sorting, search } = props.books;
    const { loadBooks, changePage, toggleSortingAndLoadBooks, changeSearchAndLoadBooks  } = props;

    const onSearchChanged = query => changeSearchAndLoadBooks(query)
    const sort_method = key => () => toggleSortingAndLoadBooks(key)
    const cols = getCols(sort_method)

    return <div>
        <BookSearchPanel search={search} onSearchChanged={onSearchChanged} />
        <div className="row">
            <div className="twelve columns">
                <h3>Book list <Link className='button button-primary' style={{fontSize:'1em'}} to="/book_create/">+</Link></h3>
                <Table sorting={sorting} cols={cols} rows={rows} />
            </div>
        </div>
        <PagingPanel count={count} page={page} onNextPage={() => {
            changePage(page+1);
            loadBooks()
        }} onPreviousPage={ () => {
            changePage(page-1);
            loadBooks()
        }} />
    </div>
}

const mapStateToProps = state => ({
    books:state.books,
})

const mapDispatchToProps = dispatch => bindActionCreators({
    loadBooks, changePage, toggleSortingAndLoadBooks, changeSearchAndLoadBooks
}, dispatch)

export default connect(mapStateToProps, mapDispatchToProps)(BookPanel);

export default class SearchPanel extends React.Component {
    constructor() {
        super()
        this.onSearchChange = this.onSearchChange.bind(this)
        this.onClearSearch = this.onClearSearch.bind(this)
        this.state = {}
    }

    render() {
        return (
            <div className="row">
                <div className="one-fourth column">
                    Filter: &nbsp;
                    <input ref='search' name='search' type='text' defaultValue={this.props.search} value={this.state.search} onChange={this.onSearchChange } />
                    {(this.state.search||this.props.search)?<button onClick={this.onClearSearch} >x</button>:''}
                </div>
            </div>
        )
    }

    onSearchChange() {
        let query = ReactDOM.findDOMNode(this.refs.search).value;
        if (this.promise) {
            clearInterval(this.promise)
        }
        this.setState({
            search: query
        });
        this.promise = setTimeout(() => this.props.onSearchChanged(query), 400);
    }

    onClearSearch() {
        this.setState({
            search: ''
        });
        this.props.onSearchChanged(undefined)
    }
}

<input ref='search' name='search' type='text' defaultValue={this.props.search} value={this.state.search} onChange={this.onSearchChange } />

const formatHeader = ({key, label}, sorting) => (sorting==key)?('+'+label):(
    (sorting=='-'+key)?('-'+label):label
)

export default (props) => {
    const headers = props.cols.map(col => <th key={col.key}>
        {col.sorting?<a href='#' onClick={e => {
            e.preventDefault();
            col.sorting()
        }}>
            {formatHeader(col, props.sorting)}
        </a>:col.label
        }
    </th>)
    const rows = props.rows.map(row => <tr key={row.id}>
        {
            props.cols.map(col => <td key={col.key}>
                {(col.format?col.format(row):row[col.key])}
            </td>)
        }
    </tr>)

    return <table>
        <thead>
            <tr>
                {headers}
            </tr>
        </thead>
        <tbody>
            {rows}
        </tbody>
    </table>
}

export default ({page=1, page_size=5, count, onNextPage, onPreviousPage, ...props}) => {
    const total_pages = Math.ceil(count / page_size);

    return <div className="row">
        {page==1?null:<button onClick={e => {
            e.preventDefault();
            onPreviousPage();
        }}>&lt;</button>}
        &nbsp; Page {page} of {total_pages} &nbsp;
        {page==total_pages?null:<button onClick={e => {
            e.preventDefault();
            onNextPage();
        }}>&gt;</button>}
    </div>
}

{% with simple=a.complex|calculation %}
    In here I can just use {{ simple }} instead of {{ a.complex|calculation }}!
{% endwith %}

export default ({page=1, page_size=5, count, onNextPage, onPreviousPage, ...props}) => (
    total_pages => <div className="row">
        {page==1?null:<button onClick={e => { /* ... */ }}>&lt;</button>}
        &nbsp; Page {page} of {total_pages} &nbsp;
        {page==total_pages?null:<button onClick={e => { /* ... */ }}>&gt;</button>}
    </div>
)(Math.ceil(count / page_size))

components/BookForm

The last book-related component is BookForm. This component is used to both create and update a book. It also has a delete button for removing books. To decide if this is a create or an update form, it relies on the parameter passed from the route - remember how the two routes have been defined in main.js:

<Route path="/book_create/" component={BookForm} />
<Route path="/book_update/:id" component={BookForm} />

So, although create and update render the same component, their difference is that update will contain the id of the book to be updated in the url. This (along with any other url parameters) is passed by react-router as a property through an object named params to the BookForm component, so, when updating a book the props.params.id of BookForm should have a value.

The BookForm is a connected component (because it needs access to the state slice and dispatch and is rendered through a route), however because it is also a redux-form, a special method (reduxForm) is used to connect the component and pass the form-related props to the component:

const mapStateToProps = (state, props) => {
    let initial = {}
    const { book } = state.books

    if(props.params.id && book) {
        initial = book
    }

    return {
        book: state.books.book,
        categories: state.categories,
        authors: state.authors,
        ui: state.ui,
        initialValues: initial,
    }
};

export default reduxForm({
    form: 'bookForm',
    fields: ['title', 'category', 'subcategory', 'publish_date', 'author' ],
    validate
}, mapStateToProps)(BookForm);

The mapStateToProps contains a bunch of required things from the state (we need the current book that is edited, the categories to select from, the authors to also select from and the ui to find out if submitting has finished and render the buttons as enabled/disabled). Beyond these, we see that there’s an initialValues attribute to the object returned from mapStateToProps. This attribute is used to initialize the form fields. So if our form has fields named title and category, if the initial object had title and category attributes the form fields would be initialized by them. In our case, we just check if the props.params.id method is defined and the to-be-updated book has been loaded to the state and just assign the to-be-updated book to initialValues.

The reduxForm method is used to connect the form component: Beyond the usual mapStateToProps and mapDispatchToProps (we don’t actually use mapDispatchToProps here because I feel that just getting dispatch is more clear), it needs a required parameter which is the object used to initialize the redux-form form: This object should have

• A form attribute with the name of the form. This must be unique among all forms in your application and will be used as a parameter to the actions that redux-form will dispatch
• A fields string array with the names of the form fields. For each one of them a field will be passed to the props.fields array in the form component
• A optional validate attribute that is a function that will be called when the form fields are changed

The validate function gets an object with the field names with their corresponding values as attributes and should return another object with the field names that have an error and the error message. In our case, we want the title to be required and the date to be valid (if exists), so the validate is:

const validate = values => {
    const errors = {};
    if (!values.title) {
        errors.title = 'Required';
    }
    if(values.publish_date) {
        const re = /^\d{4}-\d{2}-\d{2}$/;
        if(!re.exec(values.publish_date)) {
            errors.publish_date = 'Invalid';
        }
    }
    return errors;
}

I just used a very simple regular expression to check the validity of the date (it must be in the format YYYY-MM-DD) - this is just to make a point, for normal date rendered you should use moment.js.

This validate function is called whenever a form field is changed so, depending on the implementation of course, the error messages will be shown and hidden as the user types in the fields. Please notice that when the user starts typing in a field in an empty form, this field may be valid but all other fields will be empty - to avoid displaying an error message for fields that the user has not been yet been able to modify, we can use the touched property of each field — only display the field’s error message if this field has been touched. When the form is submitted all fields are changed to touched so all error messages will be displayed.

The internal BookForm is an ES6 class based component that needs to do some things when the componentDidMount method is called:

• Check if the categories have been loaded - if not dispatch the loadCategories action
• Check if the this is an update and if yes, check to see if the to-be-updated book needs to be loaded and, if it needs dispatch loadBook with the book’s id

class BookForm extends React.Component {

    componentDidMount() {
        if(this.props.categories.categories.length==0) {
            this.props.dispatch(loadCategories());
        }

        if (this.props.params.id) {
            if(!this.props.book || this.props.book.id != this.props.params.id) {
                this.props.dispatch(loadBook(this.props.params.id));
            }
        } else {
            // New book
        }
    }

    render() {
        const {fields: {
            title, category, subcategory, publish_date, author
        }, handleSubmit, dispatch } = this.props;
        const { id } = this.props.params;
        const { isSubmitting } = this.props.ui;
        const { categories, subcategories } = this.props.categories;
        const authors = this.props.authors.rows;

        const tsubmit = submit.bind(undefined,id);
        const dsubmit = del.bind(undefined,id, dispatch);

        return <form onSubmit={handleSubmit(tsubmit)}>
            <div className='row'>
                <div className='six columns'>
                    <Input label='Title' field={title} />
                </div>
            </div>
            <div className='row'>
                <div className='six columns'>
                    <Select label='Category' field={category} options={categories} onChange={ event => {
                        category.onChange(event);
                        dispatch(loadSubCategories(event.target.value))
                    }}/>
                </div>
                <div className='six columns'>
                    <Select label='Subcategory' field={subcategory} options={subcategories} />
                </div>
            </div>
            <div className='row'>
                <div className='six columns'>
                    <DatePicker className="u-full-width" label='Publish Date' field={publish_date} />
                </div>
                <div className='six columns'>
                    <Select label='Author' field={author} options={
                        authors.map(a => ({'id': a.id, 'name': `${a.first_name} ${a.last_name}`}))
                    } />
                </div>
            </div>
            <button disabled={isSubmitting} className='button button-primary' onClick={handleSubmit(tsubmit)}>
                Save
            </button>
            {id?<button disabled={isSubmitting} type='button' className='button button-primary' style={{backgroundColor: danger}} onClick={dsubmit}>
                Delete
            </button>:null}
        </form>
    }
};

The render method of BookForm defines (for convenience) a bunch of constants which are attributes of props:

• The fields object contains the field attributes of the form which have been defined through the reduxForm function.
• The handleSubmit is also provided by reduxForm and is used to submit the form - I’ll explain it a bit later
• The dispatch is provided by connect (remember, reduxForm is a special connect). If you don’t use mapDispatchToProps then connect will provide dispatch to props to use it as you like
• The id is from the route - it will have value when updating and will be undefined when creating a new book
• The isSubmitting, categories, subcategories and authors are provided from the state attributes through mapStateToProps
• The tsubmit and dsubmit are used when the form is submitted or the Delete button is clicked. As we’ll see the tsubmit is passed as an argument to handleSubmit while the dsubmit` is used as it is.

Beyond fields and handleSubmit a reduxForm enabled form component has various other properties that you can use, like active, dirty, error, pristine etc. Each field provided from reduxForm also has a bunch of properties, like active, checked, dirty, error, onBlur, onChange, onFocus, pristine, touched, valid, value, visited. I won’t use most of these here however please make sure that you are familiar with these when using redux-form.

After defining the constants, the render method returns the actual component. Here we are using a bunch of child components we’ve defined to render the input fields, like Input, DatePicker and Select which will be explained later. For each one of these components we pass the corresponding field property along with the label we want to show. There are some interesting things in the parameters we pass to these input components:

All fields except category use their own onChange. For the category field we pass a custom onChange function that will override the field onChange in order to dispatch loadSubCategories when the category is changed (notice that in the custom onChange I actually call the category.onChange first and then use event.target.value to get the current value of the dropdown to pass it to the dispatched loadSubCategories).

The Select fields get an options parameter which should be an array with id/name objects. For authors we create that array on the fly using map (since an author object has a first_name and last_name).

The submit and delete buttons will be enabled or disabled depending on the isSubmitting flag, and will call handleClick(tsubmit) or dsubmit correspondingly. Also, the Delete button will be hidden if no id is provided.

The handleSubmit method provided by reduxForm will run the validate function passing it the values from the form (notice that this is synchronous validation, we could also do asynchronous - on the server- validation for example to immediately check if a username is already used), and if the validation does not return any errors, it will submit the form. Submitting the form means that handleSubmit will either call this.props.onSubmit or will call the argument of handleSubmit (that’s what we’ve done here), passing it the data of the form.

In our case, we want to pass the id of the book to be updated (or undefined when the form is used to create a book) to the submit function, that’s why I am assigning submit.bind(undefined,id) to tsubmit (which is what is passed to handleSubmit) - this will return a new function with the id as its first argument. The handleSubmit also passes the values of the form as an object along with the dispatch function, so submit is a function with three arguments:

const submit = (id, values, dispatch) => {
    let url = '//127.0.0.1:8000/api/books/'
    let type = 'POST'

    if(id) {
        url = `//127.0.0.1:8000/api/books/${id}/`
        type = 'PUT'
    }

    dispatch(submittingChanged(true))

    $.ajax({
        type,
        url,
        data: values,
        success: (d) => {
            dispatch(submittingChanged(false))
            dispatch(showSuccessNotification('Success!'))
            if(id) {
                dispatch(updateBookResult(d))
            } else {
                dispatch(addBookResult(d))
            }
            dispatch(routeActions.push('/'));

        },
        error: (d) => {
            dispatch(submittingChanged(false))
            console.log(d);
            dispatch(showErrorNotification(`Error (${d.status} - ${d.statusText}) while saving: ${d.responseText}` ))
        }
    });
};

As we can see it just checks if the id has a value and creates the url and the HTTP method for the update (either a POST when creatign a new book or a PUT when updating an existing one). It will then dispatch the submittingChanged action to change the UI (disable the buttons) and do the ajax call. When the call returns, if everything was ok it will dispatch the submittingChanged (with false as a parameter), the showSuccessNotification (with success as parameter), either updateBookResult or addBookResult with the retrieved data as paramater (depending if there was an id) and finally it will change the URL to / to display the books table. If there was an error it will once again dispatch the submittingChanged action to turn off the submit flag of the state and showErrorNotification with information on the error. The url won’t change so that the user will be able to fix the error and retry submitting.

The del function is a little different. We bind not only with id but also with dispatch because we don’t call it through handleSubmit (since when deleting no validation is actually needed) but directly as the onclick handler of the delete button (so we must pass dispatch manually):

const del = (id, dispatch) => {
    const url = `//127.0.0.1:8000/api/books/${id}/`
    const type='DELETE';
    $.ajax({
        type,
        url,
        success: (d) => {
            dispatch(showSuccessNotification('Success!'))
            dispatch(deleteBookResult(id))
            dispatch(routeActions.push('/'));
        },
        error: (d) => {
            dispatch(showErrorNotification(`Error (${d.status} - ${d.statusText}) while saving: ${d.responseText}` ))
        }
    });
};

This function sends a DELETE method to the correct url and, if everything was ok dispatches the showSuccessNotification, deleteBookResult and routeActions.push, similarly with submit.

One thing that I’d like to discuss here is the nature of the submit and del functions: These function do dispatch other actions but they are not implemented as thunks so, in order to be able to actually dispatch something they need to retrieve dispatch as a parameter (please remember the discussion on the redux-thunk section and the difference between dispatch(actionCreator) and actionCreator(dispatch) ). The submit function receives dispatch from handleSubmit while we pass dispatch directly (using bind) to the del function.

I could have implemented them as thunks (and put them to the actions module) however I feel that leaving them here will make the API of the application more compact (since if these functions had been put in the actions module they would need to be exported so they’d be a part of the public API of this application - however these two are only called from BookForm) and also their purpose and integration with handleSubmit is more clear if we leave them as plain functions. This is just my personal opinion - if for example you wanted to allow deleting a book not only from the BookForm but also from the BookPanel (by adding a delete button to each book row) then you’d definitely need to export del as an action creator (preferably as a thunk action creator to be consistent with the others).

export default ({field, label}) => <div>
    <label forHtml={field.name}>{label}</label>
    <input type='text' className="u-full-width" {...field} />
    {field.touched && field.error && <div style={{color: 'white', backgroundColor: danger}}>{field.error}</div>}
</div>

<input ... name=field.name onChange=field.onChange value=field.value onBlur=field.OnBlur etc />