Using React for our Bluemix application
5 min read
Using React for our Bluemix application
Earlier this year, we were tasked with choosing the best technology to use for the build of the web UI portion of our Logistics Wizard sample application. A few years ago, this was as simple as pulling in jQuery, a CSS file, and jumping right into the code. Now? This landscape looks completely different.
This is one of the best posts I’ve read all year and precisely describes my feelings when I started.
By the experts in the field, I’m assured that all of this is worth it. I’m assured that once I get through the initial bootstrapping code and development environment, it’ll be worth it. All right, I’ll bite.
The learning curve for React and all the surrounding tools is steep and definitely not for everyone. If you’re looking to build a simple UI with a few components, then React is probably not for you. However, if your UI is composed of many components that all need to update real-time as events are triggered and data is updated, then React will enable you to build a scalable, super-fast UI. Think about the various components that are active when you visit Facebook. The news feed is composed of posts and advertisements, each with comments, likes and emoticons. The real time chat allows you to see your friend’s status and message them directly. All of these components are on the same page, each with their own lifecycle. Such a complex page requires a robust framework which explains why Facebook built React.
Our Logistics Wizard sample application required a dynamic UI.
On a single page, we wanted to show the user a map of all the retail locations, distribution centers, shipment trucks and weather data. The user should be able to click on any item to get more information without leaving the page. It should allow the user to simulate a weather storm which would trigger API calls in the backend and then have the rest of the UI update to reflect real-time events as they were happening. We also wanted unit tests to ensure code stability. Finally, our UI needed to be just a UI. There is no back-end code in the webui application. The back-end is handled in other applications (logistics-wizard-controller, logistics-wizard-erp, logistics-wizard-recommendation). These backend applications expose an API, and the UI will communicate to these over HTTP following the microservices architecture.
We don’t need any end-to-end application framework for our webui. There is no database, cache or server-side session management. Mostly, we just need to take the large amount of json data coming from the API’s and render it as attractively and efficiently as possible. If the user performs any action in the UI, it will likely result in an API call. Unlike other web frameworks, React is just a *view* library (think View in MVC). So React was designed for our use case!
Writing React apps is not as simple as just importing a single library. It’s an entire ecosystem of libraries and tools you can add to your application as you need them. Here is what we used in our application.
Redux is a state container, which can be used with React. Their documentation, along with a few videoshelped me understand it fairly quickly. For our use case, we used Redux to store all retrieved data from API’s in one single state object. When we need to update it, actions are emitted which describe what needs to happen. Then a reducer will pick up the work and merge the changes back into the state. We use redux-connect to cleanly pass all the data to all the components. See the code
The IDE of choice is Atom, hands down. It feels lightweight, fast and has several add-ons/plugins to make web development a breeze. The ecosystem is healthy and growing. The linter and linter-eslint add-ons helps you write clean, consistent, readable code by having the validation run directly in the editor. See the .eslintrc file for the rules that we used. Language-Babel provides support for ES2016 and JSX and provides things like indentation, syntax highlighting, autocomplete, and transpilation on save!
We used ava, a simple fast test framework that allows us to write atomic tests and have them run concurrently. Enzyme was used to test if the components are rendering properly and Nock for mocking HTTP requests. Finally, we used Coveralls to ensure that adequate amount of our code was being tested. While none of these are specific to React, it integrated quite well.
These are just a small subset of everything we used to build our UI. I tried to give a quick high-level summary of the major players. Personally, adapting to this new world of front end development hasn’t been easy, but I’m still having fun learning and keeping up with the rapidly evolving community.
Was it worth it? Yes. As we add more and more components to the UI, the complexity of the code doesn’t grow. When everything is separated into self-managed components, you don’t end up with spaghetti code. Redux helps you keep all the data gathering and API calls in one place.
To see everything we developed, view the source at:
Some key files you’ll want to checkout are the README (of course), package.json (dependencies), server/main.js (middleware), src/routes/Dashboard/modules/Dashboard.js (Redux actions and reducers)
Have fun and feel free to reach out for any questions you might have!