Live Blogging the Development of a New Feature: via ReactJS and .NET Core. Part 1.

Today’s coding session has been kicked off by Pandora Shuffle streaming the Beatles’ “Revolution” into my ears. Which feels inspirational.

(And, yes, I still listen to Pandora. It’s logged over a decade’s worth of my preferences. So, Pandora knows me with embarrassing levels of intimacy.

Also, I’m an old. 👴)

Preparing to begin coding this feature, my first thought is that my interest in the challenge of building the backend aspects of this project- basically, the .NET Web API controller- exceeds my excitement for building the client-side UI.

So, naturally, we’ll build the UI first. Lol. Or, its foundation at least.

Before we code anything, however, we need to make sure we are leveraging git, our tool for version control, so that it can allow us to avoid project doom when we inevitably make mistakes.

So, in our terminal, we’ll use the command, git checkout -b <featureName>.

“-b” directs git to create a new branch off our master codebase. We replace <featureName> with a name for the branch appropriate for the item we’re building. Inexplicably, I named the new branch, “imageLoader”, which- let’s be real- is an awful branch name. But will adequately serve our purposes.

Recall from part one, that our design for the UI component directs that the user should see two columns, centered in the bottom third of the main window of BoGoodSki.com. The left column will be the home of our runner unicode symbol. The right column will be split into two stacked rows. So, basically, in the end, we have our running icon trailed by two lines of text (actually, one line of text and a button underneath).

A picture says a thousand words, so I’ve called on inspiration from my favorite master artists, Titian and el Greco to sketch out my vision:

For the layout in the project, I’m implementing Flexbox via CSS. For theming purposes, we are using the Material-UI library; specifically, the library’s “withStyles” Higher Order Component. Material-UI makes available for us another helper library, called “Grid”, that we could utilize to set breakpoints to format our feature’s layout. But that should be unnecessary. Flexbox alone should be sufficient for this feature’s modest needs.

The simple act of centering items is notoriously challenging with CSS. More exactly, it’s not the centering that is difficult, as it is difficult to ensure that all centered elements remain centered when resized dynamically, and that the child elements behave consistently on all diverse screen sizes and resolutions.

I can’t lie: it took a bit of tinkering but, eventually, I worked my way toward a solution. For the parent-most (is that a word?) element — our project’s “container”, or root, element — we came up with this CSS code:

Inexcusable lack of consistency in single and double quotes (AND A SUPERFLUOUS TRAILING COMMA!) — need to clean that up, son!

I now realize that I’ve shared a lie: that the code above is CSS when, actually, it’s CSS-in-JS, or “Cascading Style Sheets in JavaScript”.

Discussion of CSS-in-JS could digress into an entire sidebar about one of the chief complaints that some folks have with ReactJS (and that CSS-in-JS could, in a way, contribute): ReactJS drives the developer to write code in a way that isn’t always consistent with the age-old philosophy of “separation of concerns” from the halcyon days of Object Oriented Programming (I kid! I love SOLID, and the days of OOP are still very much with us!).

But, again, we’re not getting into that here :)

We can just settle on the understanding that, for our project’s present needs, CSS-in-JS is convenient for most of our styling requirements (and works consistently with the Material-UI “withStyles” Higher Order Component).

To organize our columns and rows, I created two sets of <div> elements. The first div gives us a hook to implement a Flexbox command that tells it to align the two columns next to each other horizontally (in a Flexbox term, in a “row”). The second div allows us to command the right column to stack its two rows vertically or, in a Flexbox term, in a “column”. Pretty simple.

A quick note: Generally speaking, I always try to build for “mobile first”. The next observation is shared anecdotally (because I’m way too lazy to find the empirical statistic), but I know it to be fact: most users will view your web app on a mobile device. Not on their desktop. So, we should build initially for our primary audience — mobile users — but ensure that the design remains consistent when expanded to larger screen sizes and resolutions.

So, repeat it, make it your mantra, even consider getting it tattooed prominently: “Mobile First”.

Before moving on, I want to address the CSS layout for just one more second to give two shout-outs: 1. First, a shout-out to Flexbox, itself, because I’m a huge fan, and 2. A shout-out to CSS-Tricks.com because they provide the single best, one-page Flexbox cheatsheet that I’ve ever come across (and reference regularly). You can check it out HERE.

Alright. And, now, before closing up shop on today’s chapter, let’s review two other tools that will help improve the aesthetic appeal of our project:

1. Google Fonts. Pretty self-explanatory, I’d think. Here is a gif of me scrolling through the repository of fonts. For you non-developers out there, this is footage of the real gritty, blue-collar, in the weeds work by which we practitioners toil:

2. Material Design Color Tool. “Material” design is actually a thing. And, once you are aware of its existence as a “thing”, you’ll quickly discover that it is ubiquitous (and contributes to why many things on the internet look similar to each other). Material is a design philosophy based on research of human factors that has determined which colors, fonts, spacing, and other design details create the experience most acceptable by users. There’s a reason why buttons on your YouTube app are exactly where you anticipate that they should be: because people smarter than me have studied exactly where those buttons should be placed, how they should behave, the font they should use, etc.

The Material Design Color Tool linked here helps non-artistically-gifted producers -such as this blog’s author — make color choices consistent with those that Material Design indicates users respond well.

So, where did we end up today?

Do any of you like 90’s rap? “Run with Me” has Hail Mary by Makaveli in my head. Though, in the lyrics, I think Tupac actually raps, “Come with me / Run quick / See”. But, I digress.

It’s not perfect, but it’s sufficient as a base. We can come back to this later and clean it up.

I find that the insistence on persistently tweaking code actually has diminishing returns; at least during any single coding session. That is to say that I think there is value in walking away, working on something else, and then returning back to the original work with fresh eyes. It’s real easy with coding to lose track of the forest because of the trees. I can’t tell you how many times I’ve struggled to implement a really complicated solution and then realized, after gaining some space from the project, that there was an easier way all along that should have been obvious, but I missed because I was just too deep into it.

So, we’ll come back to the UI segment of the project in the coming days. For now, we move on to building the Web API POST method which, truly, is the aspect of this project that I’m most excited about developing. Mostly because I have less experience with .NET than I do with ReactJS. I find that every time that I code (every SINGLE time), I learn something new — that’s why I ❤ code. But, with .NET specifically, because of my inexperience, those new things are always substantial. For a nerd like me, that sincerely is thrilling!

(Click HERE for part two in this series.)

Thanks.

-BoGoodSki.