Image Image Image Image Image Image Image Image Image Image

Being Brunel |

Scroll to top

Top

No Comments

Building A Web App Part 5: Code Complete

Building A Web App Part 5: Code Complete

The only thing missing from our amazing prototype web application (to match built environment professionals to Slack channels by their interests), is some actual functionality. We’ve got to the point where we have a lovely static interface, but it doesn’t matter how hard you click to select any interests- nothing changes. In the final post of this mini-series we’re going to plug in that functionality.

Redux Modules

The only piece of the stack we haven’t used so far is Redux. Redux is responsible for the store. The store represents the data within our application. It will maintain a list of all the available interests and channels, listen for when a user clicks on an interest to de/select it and then update the list of relevant channels accordingly. And to make things easy, we’re going to do it all in one file, ./app/redux/channelFinder.js:

There’s a lot going on here. The very first thing we do is define our one any only action, the action of toggling an interest between selected and unselected. In the Redux pattern, every action is represented by a unique identifier (networkBe/channelfinder/TOOGLE_INTEREST). This identifier, along with any payload (in our case the interest that wants toggling), is wrapped up in something called a Flux Standard Action; a way of collecting together this information. I mentioned, when we were building the stack, that we’ll be using createAction from redux-actions to save us having to write a function that generates a Flux Standard Action.

As we’re going to be doing all the computation on the client (i.e. we’re not going to have a clever server), the next bit of the code outlines all the possible interests for the user to select from, and all the channels available. The channel definitions set out which interests trigger the channel to be selected. For example, selecting ‘diversity‘ will prompt a recommendation of the ‘#chat-diversity‘ and ‘#chat-health-wellbeing‘ channels. As the web app is developed some of this logic will be moved server side; but for now we’ll keep it simple and on the client.

The next section is what Redux calls a Reducer. It takes the state (the interests, selected interests, and channels) the application is currently in and an action to apply, and returns a new state with the action applied. So in the case of our single ‘toggle interest’ action: the interests available (which will never change), the selected interests (which need to be updated to include/remove an interest; depending on whether or not it’s already been selected), and the relevant channels (which need to be updated to match the newly selected interest). The handleActions section also takes responsibility for setting the initial state; nothing selected, no channels recommended.

Finally we define how the state and the actions are accessed by our ChannelFinder container. In our case our state exactly matches the parameter inputs into the container (interests, selected, channels), so we can just pass it along. We also need to pass in our toggleInterest action so that our ChannelFinder will be able to dispatch (the Redux term) the toggle action that will de/select interests. The react-redux library provides us with a connect() function, which we can setup and then export for use on the container (ChannelFinder) to wire it into the reducer.

  • Dux – a methodology for writing Redux modules.

Wiring In Containers

As promised, we need to update our current ‘dumb’ container code (./app/containers/channelFinder.js) to make it smart:

Note how we’ve dropped the defaultProps property, and instead wrapped our returned channelFinder component in the connect function we exported in our ./app/redux/channelFinder.js module. We no longer need the default properties to be set, because we’re actually passing data in now. The connect function developed in our module will take the state/dispatcher and transform it in the interests, selected, channels and toggleInterest parameters for us. This relatively modest change is all that was needed to make our ‘component’ into a true container.

Finally we need to add Redux into our bootstrap, so update ./app/app.js:

And ./app/index.js:

In index.js we now create the store from our channelFinder reducer (using Redux’s createStore function). We then pass that as a newly added parameter to our app.js root component. This has been updated to use the <Provider> component from react-redux, which is responsible for giving the connect function (used in our <ChannelFinder /> container) the correct store to connect to.

Finally we have a working application- run npm test and you’ll see that we pass our behaviour test. Once you’re satisfied, run npm start to start the server and browse to http://localhost:3000. Behold the finished product, now with working buttons. We’ve finally delivered our prototype.

 


This has been a whistle stop tour of a fairly large amount of functionality, and as I said at the beginning- I don’t really expect anyone to follow this all unless they already know it. But hopefully it’s given you an outline of the process of creating a web application, and introduced you to a solid stack for you to master. Throughout this mini-series I’ve been listing out resources- I now recommend you go back and get to grips with those bits of the stack, or aspects of the language, that you don’t know- now you have a feel for how they fit in to the whole process.

You can find the working prototype here:

https://github.com/thomasmichaelwallace/network-be

This post is part of a five post mini-series on building a web app: Part 1Part 2Part 3Part 4Part 5.

Submit a Comment

Leave a Reply