React Adventures Part 2 – Recapping the Initial Headache

I wanted, for many reasons, to build a jukebox app that works on a web browser. I figured this is a good excuse to try out React. (I still feel like there are some good reasons to ignore React and its accompanying gaggle of technologies completely, but that’s another post.)

I was and still am working with a SQLite db that was left behind by Swinsian, a really wonderful jukebox app for Mac that I can’t say enough good things about. Later on I’ll worry about creating and managing my own db, but for now I’d just like to have an iPad in our living room that can do cool tricks with my Swinsian library.

I made a first attempt at this in PHP, and got as far as connecting to the SQLite db, displaying album art, listing artists in alphabetical order (including weird characters), and playing the mp3s themselves. But asynchronous programming was and still is kind of a mystery to me, so I was left with loading some SQL queries once I load the page, and then… then what?

React, Take One

My first try at dipping my toes into the React pool lasted a few days to a week. I’m so-so at Javascript to begin with, but I’m a strong autodidact, so I learn to read new things pretty quick. I also had to learn the roles of node and npm, which I’d used before at work, but only in the context of having tech leads say to me, “Here, use this to set up your dev environment.” What Node and npm really did, beyond making my work-sites load on my machine, was kind of a mystery to me.

Nevertheless, I worked through the official React tutorial (the tic tac toe game), understood it only halfway, and went ahead with trying to turn that knowledge into a jukebox app.

So, after a couple days of searching and copying and pasting and searching again, I figured “learning React” (what does that even mean at this stage?? I was learning like ten things at once) might be biting off more than I could chew. I should start with some lower level stuff.

OK Fine, wtf is Node

I started with trying to figure out how to build a site “the node way.” Some things I remember learning here:

  • Building a web site with Node means, instead of including a <script> tag for JQuery and Bootstrap in the footer of your HTML, you open up a terminal, cd into your site’s base directory, and run a command telling it to download JQuery and Bootstrap into a folder (/node_modules) in your site. From there, there’s some magic code that you put somewhere, which tells your site to actually use the code you downloaded. Where and what this magic code is varies depending on how you’re building your site.
  • I realized that I’m gonna need to use some kind of frameworks or tools or whatever in order to build a basic site using node that queries a database. After more searching, I settled on Express. This introduced another group of confusing and new technologies (or were some of them tools?) — JSX, EJS, routing, I dunno, some other stuff too. It was weird.

But, I got it working, and I even got it talking to the database! I was pulling the names of all artists / album-artists, sorting them correctly even with accented or otherwise non-alphanumeric ASCII characters, removing duplicates, etc. Cool.

Then I got distracted with some other projects and life-stuff, and shelved the project for a time.

Dusting it Off

I came back to it some months later, dusting everything off and collecting my thoughts on it. I still needed to figure out the AJAX / asynchronous programming issue. But I figured I’d start with something easier, which I’d already accomplished in PHP: Displaying a grid of album covers from a particular band.

This was very hard. In PHP it’s like 3-5 lines of code (once you’d got it talking to the db already) to just display the image. I found out that, I guess, PHP gets access to a computer’s filesystem for free (meaning it can look in a folder and see if cover.jpg is there or not), whereas this seems to be hard for JS.

More searching, more copying, more pasting, more errors. OK, I figured that this, in concert with the looming AJAX / asynch question, meant I should back up again.

React Again Huh

I don’t know why “backing up” translated to “trying React again” but for some reason it did. I was looking at React Boilerplate, and figured I’d try just following the installation instructions to see if they would work out of the box. They did! And also I could suddenly search a user’s GitHub repos using this boilerplate app I’d installed on my machine. Huh, ok, cool.

I’ve always learned to code by getting examples working on my machine and then picking them apart, so I figured maybe this could be the right track.

I spent maybe 6-8 hours learning some combination of the general concepts of routing & components & CSS in JS & The React Way of doing things, and specific methods and whatever-other-things that are baked into the React Boilerplate — all the while not being totally sure which was which, and comparing them to the tic tac toe game along the way, where I could.

I got a little farther, but kept hitting weird dead ends and finding some basic things to be very difficult. Also the whole idea of linting and testing was (and still is) too far off for me, and React Boilerplate had all this built in linting stuff that would prevent me from checking code in if I so much as looked at my app wrong. Too much too soon.

Third Time’s a Charm?

After more searching and reading, I made a new branch in my project’s repo, cleared everything out, and tried out Create React App to see if I would have better luck with it. I did!

I figured I’d slow down a little bit and work on some things that I knew React would do first. I wanted to have a <select> element in a sidebar that, when selected, would display the option that was selected on another part of the page. (Really getting back to basics here.)

It took another 5-8 hours of reading & trying stuff out to figure this out, but I got it, and I felt like I solved my AJAX / asynch questions in the process.

In React (and I guess in frontend development in 2019) you just call this stuff “state management.” Who knew!

State / Components / Tree Metaphor

There were two big concepts that I learned in this process: state and components. I made sense of them by thinking of the parts of my site like leaves on a tree, talking to each other.

  • Each leaf is a component.
  • Sometimes parts of a web site need to send messages to other parts (i.e. click on an artist’s name, see their albums displayed next to the thing you clicked). Meaning, sometimes leaves need to communicate with each other.
  • The old way (I used to use JQuery for this, it’s still a good method for some sites honestly) is where you assign an ID and/or a class to each leaf (AKA component, FKA JQuery object, FKA HTML element [jeez]), then you tie a little string from one leaf to the other, telling the leaves what to do.
  • Obviously these strings can get tangled pretty quickly. I think of the new way (using React / components / state) like going through the branches instead.

One thing about the tree metaphor: It has to do with a thing called “lifting state,” which requires that, in the metaphor, you flip the tree upside down. Sorry.

So, a component (AKA leaf) has a “state”. I guess this shows up as like, a property of the HTML element, or a value or it, or whatever. When the component needs to talk to something else, you manually pass this “state” up the branches, until you find a branch that it shares with the component it needs to talk to. (Sometimes the state has to go all the way to the trunk for this.) Once a component has passed state up to a parent element, now the parent element owns the state, and the original component calls it a property instead.

So, you have a parent or grandparent element that owns the state, which then sends it down to children and grandchildren as a property (AKA prop).

Another analogy that works here is the snitch (component), who tells an authority figure (another component, higher up) that someone else (a third component) is doing something bad (the message). The authority figure then tells the person being snitched on that they’re in trouble (passing the message), and probably throws them in jail or something, because authority figures are usually shitty people like that. (PSA: Never call the cops.)

OK Now What?

Now I’m trying to make the list of artists that’s on the sidebar of my app pull from the aforementioned SQLite database. It’s pretty hard. I’m realizing that everything I’ve been doing up ’till now has been called “frontend development” and now even this most basic database call is called “backend development.”

Conceptually, I understand that there will need to be another piece of technology in between my frontend code and the database — an API or something. The first one on my list to try is GraphQL. We’ll see. I have two tutorials bookmarked right now: one for connecting SQLite to GraphQL, and one for connecting GraphQL to React.

Man this shit is complicated. I can’t wait until the JS community settles all this stuff down into something more manageable.

Leave a Reply

Your email address will not be published. Required fields are marked *