With the supporting groundwork of back-end technology and visual structure laid, it is time to move into the world of front-end technologies. As I've mentioned previously, since my last foray into front-end development there has been a lot of changes, some fundamental, many of them window dressing. Whatever the merits of the changes may be, I soon found myself swimming in a world of Webpack, NPM, ReactJS, and Jasmine.
How?
It begins with using React- once you start creating React components it quickly becomes clear that for any non-trivial application, it makes organizational sense to give each (or nearly each) React component its own separate file. However, doing this forces one to a) use JavaScript modules and b) thus needing lots of script tags to load all necessary files. Even further, I'm hosting and serving these files on a CouchDB instance as attachments and so I now need to re-upload all these files after every modification. This repetitive task practically bashes you over the head with the need for a script(s) and thus enters Node package manager (NPM) whose package.json files lend themselves to collecting and organizing scripts. So I modify my 'upload files to CouchDB' script to take a variety of CLI commands allowing me to upload one or more files to specific databases using their url. Then I create three separate NPM script labels which allow upload of:
1) all files using 'npm run updateAll'
2) one or more specific files to shared resources database with 'npm run update -- *...space separated filenames here...*
3) one or more specific files to a specific database path using 'npm run update_wp -- *...space separated filenames here...*
Works like a charm. But there's another problem: the more files in HTML script tags to load the worse the performance of a web page so it is natural to then group separate files into one single monolithic file. Here enters Webpack whose name says it all. Webpack's entire purpose is to take all the needed resources indicated by linked CSS, JavaScript, etc. tags in a working development project and output a singular block of files corresponding to the main parts of a web application (HTML, CSS, JS). Like NPM, Webpack also has a config file which allows one to indicate the paths for inputs and outputs along with other details such as how to handle the different file types within one's project-- e.g. art assets vs CSS vs JS etc.
I'm not running a Google software division here so it doesn't take long to get up to speed with Webpack so that it is tossing all of my React components into a single file. Truckin' right along.
This brings us to the last piece of jargon mentioned above, Jasmine. Unit testing is, of course, critical for any serious developer who'd like confidence in what they're developing and, as par for the course in the world of software and, especially, JavaScript, there's many different unit testing frameworks to choose from. However, I'm not interested in the latest fads for fads sake so I quickly hone in again* on the Jasmine framework as it has been around for quite some time and is still under active development. Further, Facebook's recommend unit testing platform for React, Jest, is built on top of Jasmine. After some research and a little experimentation, it turns out it is very straightforward to use vanilla Jasmine with React's test-utils module. Now that all of the key development infrastructure has been set up, we've hit cruise velocity.
*I already began using Jasmine with NodeJS server-side
What follows is the typical development process of writing big-picture skeleton code then filling in the details: lifting state, passing React props, limiting React props to pass, handling callbacks, managing promises, writing tests, isolating components properly, keeping mobile-first design in mind, deciding between CSS layout systems, properly documenting code, moving between React and the DOM, translating between DB model and output view, working with instead of against React's virtual DOM optimizations and, of course, debugging refactoring debugging refactoring...
All said and done, I'd say the most important takeaway when working with React is to aggressively lift and extract state as much as possible. This includes moving supporting functions out of components entirely; this forces you to compartmentalize functionality which is critical for testing, clarity and sanity.
Also I'd say I'm not satisfied with my current approach to testing React components from a "simulate user interaction" standpoint. My tests were/are too brittle in light of the fact that I made heavy adjustments to some React components about half-way through development. Not much cause for worry though since improvement and refinement is the name of the game in programming.
Anyway, once all of the major technical quirks, bugs and errors are ironed out it's natural to heave a sigh of relief and take a step back. But there in front of you awaits the continual re-realization that technical details, though vital to even having a product in the first place, don't matter much if the final end user experience looks and/or feels terrible. So it's time to return to the world of design to find out how all of this technical implementation translates into how this 2D commenting system feels.
Next.