Single-Page Web App Development, Part 1: Setting the Stage
by Dan Parks, on Dec 11, 2018 3:18:20 PM
A client recently came to us with a request to build an application unlike anything we had built in the past. Arriving at the best solution for them would challenge our thinking and our usual approach to software design and construction, but we (and the client) are quite happy with how it all worked out.
We didn’t want to spend hours on configuration for this client. Instead, we wanted to be delivering usable, valuable and functioning software to them as soon as possible. After discussing their needs and gathering the requisite documentation of the “business rules” of their yet-to-be-created software, we went through an internal discussion of what form a solution to their problem would take and what tools and technologies we’d need to use to solve it.
For this project, a single-page app made perfect sense. The client’s users would enter minimal but essential information. The software should then evaluate the data and output a response to the user in line with the business rules being executed and followed. The application needed to have visual appeal and a smooth workflow embodied in the user interface -- no time for back-and-forth server trips and web page transitions. Furthermore, the data was transitory in nature, and didn’t need to be persisted from session to session, so an architecture with a back end would have been inappropriate.
On the development side of things, we needed to work with tooling that would let us:
- Implement and execute the client’s business rules
- Design, lay out, and construct a smoothly-functioning UI of moderate complexity
- Use stylesheets and graphical design elements in a consistent fashion from screen to screen
- Bundle all these elements up into a package suitable for deploying on the open Internet
Selected Tools And Rationale For Their Selection
Second, given the complex and dynamic nature of the UI that the system required, using a flexible but powerful web framework would work to our benefit. We chose React for this, and were able to make good use of its declarative nature and the straightforward mapping of visual elements on the screen to React “components”. Closely related to this decision was the choice of Redux to help manage application state. Though the system wouldn’t deal with volumes of data, the process of entering and evaluating the data would happen in several steps as the user worked his or her way through the application, and a library like Redux helps to ensure that there is only one “single source of truth” for the application’s data.
Thirdly, we like managing our styles with SASS. We like how easy (nearly foolproof) it makes maintaining consistent styles – think color palette, spacing/grid/gutters, fonts, etc. We’ve also found that if your modularize at least some of your stylesheets similarly to how you factor out visual elements and components on the screen, it is really easy to keep track of what files need to be updated if you want to change some aspect of the design.
Conclusion of Part I
Finally, check out the demo site: http://weather-rock.aws.leandog.com/
... and you can find the sample code here: https://github.com/leandog/weather-rock-spa