Let’s Build A Web App! Week 19 of my 30 week web dev journey
This week is week 19 of my 30 week journey, and I’m continuing to trundle away on the modules of my site, namely the reader module.
If you are unaware of what I’m talking about but find your curiosity piqued, check out the other posts in this series listed under my account! I am really lazy today and publishing from my phone, so bear with me if the text is not as rich as usual. 💦 (Don’t ask me about my process for doing this without WiFi as it’s hilarious but also scarily roundabout).
What did I aim to get done this week?
Continuing to follow Guillaume’s advice to focus on one module at time, my goal was to complete the reader module of my site in this week. Last week I’d set up my CDN and tried a few basic things out, so this week I’d have to set up the backend stuff for the actual view components for the module (i.e., the metadata models for the series, chapter, and page entitles in roy backend, and the respective GraphQL fields to query for those entities), add example metadata and corresponding assets to the database and CDN. and of course, write the view components themselves.
What did I get done this week?
I actually decided to start with the frontend side of things (writing the view components), which took up the week. I spent the first day implementing some basic functionality (dropdown lists that navigate to the series view and chapter view, respectively) and then the other 4 days refactoring. I’m almost done with wrapping up my pull request for the front end, after which I plan on moving to the backend tasks so that I can implement data queries (my reader views right now are working with mock data as opposed to data from my backend).
What didn’t I get done this week?
I didn’t create the metadata models for the series, chapter, and page entities in my backend, and the respective GraphQL fields to query for those entities. Likewise, I didn’t get to add example metadata and corresponding assets to the database and CDN.
On the frontend side, I didn’t write the queries through my Apollo client for series, chapter, and page metadata, and the subsequent asset retrievals from my CDN for each view component
What went well:
Dynamically rendering the routes for series and chapter views.
Showing up to school early every day and working a consistent amount.
What was difficult
I mentioned last week that I enjoy using npm packages that just do things for me, but I was aware that there might be scenarios where it wasn’t worth it. This week I think I discovered that scenario when I tried out a package that was written and stopped being maintained a while ago. I assumed it was the only alternative to me doing the work to implement an input dropdown myself; I also assumed that updating the code to be compatible with the current version of React was preferable to doing that work to implement the input dropdown form myself. Both of those assumptions were wrong, but I spent a number of hours slogging through the changes to update the code before I corrected my assumptions. Oh well, it was an instructive scenario and I’m happy with my react-select module now.
As I mentioned briefly above, I actually spent around 1 day to get the dropdown and view navigation logic done and 3–4 days on refactoring. This is leading me to realize that, as a perfectionist, I love refactoring, and I’m happy to spend 3/4 of my time getting code to a point where it feels “good” to me, as
opposed to sloppy. But the difficulty is sometimes you want to move (more) quickly with building out functionality, and if I indulge in my preferences, I’m moving that much more slowly. I feel ambiguous about how to handle these competing priorities (code quality, getting stuff done) and so far I think I’ve chosen to indulge myself.
On the other hand, I have a hard time slowing myself down to take the time to write tests and run tests (oh no, I know) and so far although it’s concerned me (it’s an important skill set that I keep choosing to not develop!) I haven’t second guessed myself because I had the sense that formally writing tests for view components would take more time than my informal testing with browser and console checks. (Of course you need tests when you build out a lot of functionality and manually checking things no longer covers enough possibilities, complicated interactions, or edges cases). Now, however, I’m encountering a scenario where things simply aren’t behaving the way I expect and as I spend time debugging the issue, I start thinking that maybe if I had some tests to cover basic expectations, I could count out a lot more possibilities at this point or realize much more quickly what’s causing the issue.
What I would do differently next time
If I’m thinking of using an npm package, check how long it’s been since it’s been maintained, check for telltale signs that the code is defunct, and if the package is stinky enough, spend a little more time checking to see if there are alternatives.
One cool thing I learned about
Apparently in the past you would have to declare all your view “routes” with React Router at the top-level, but now you can include a route in any child component being rendered, and that route will be added to the router ad hoc with no issues. If you need to render a route on certain conditions (other than the user clicking on a Link component), you can do so by pushing to the “history” objects, and any component rendered as a view component for a route can receive this history object as props.
