As I’ve been building websites, I’ve also been realizing that a lot of my ideas for original sites would actually be better as mobile apps. React Native, I’ve heard, is close enough to React that I should be able to cobble together some straightforward apps. So that’s what I’m going to do…

Over the past couple days, I watched the first two videos of Harvard’s CS50 Mobile App Development series on edX.

What an idiotic waste of time.

Watching the videos took at least three hours. I learned a few interesting tidbits and refreshed some JavaScript fundamentals, but did I learn anything essential to actually building anything in React Native? Did I write a single line of code? Of course not. And while I wouldn’t go so far as to say that video tutorials are worthless, they are absolutely not worth the time it takes to complete them.

After sinking those three hours into those videos, I stuck a Post-it Note on the wall just above my laptop screen that reads: No more videos! Build! So I got started…

And immediately overwhelmed myself. I decided to search for some reusable components first to see which existing libraries could help me jump out of the gate. Before I knew it, I had 10 tabs open to different articles suggesting various repositories for pre-made components of uncertain quality. Calm down, killer. Start from the beginning.

At the very start of the React Native docs, it says, “Expo is the easiest way to start building a new React Native application.” Cue my 10-minute search to learn what the hell Expo is, and if there are any alternatives that I may be more familiar with. There aren’t, really, so I eventually decided to just go with it.

I installed Expo from my Terminal, started a new project, opened up the App.js file in Atom… and saw a bunch of code that I don’t understand! Cool, cool, cool…

I try to run the code anyway on a local host, and get a bunch of errors about a simulator not being installed. It tells me I’ll need to download Xcode. I do, but hope I’m not limited to it. I’d like to keep writing in Atom.

After more errors, downloads and licensing agreements, I finally got an iPhone simulator on my screen. I clicked “settings” to see if even the on-screen apps were simulated (they are), but I don’t have an iPhone X (the model used in the on-screen demo), and without a Home button, I couldn’t figure out how to get back!

I played around with it for a bit, and came to a screen on the phone that said, “Get started by opening screens/HomeScreen.js” and change the text. I did that in Atom, and with hot reloading, the text was changed by the time I got back to it.

Finally. Time to build.

I couldn’t go to bed on Monday without trying to solve some of the problems I had left myself for Tuesday. Knowing that my site was live, but that one of my apps was showing only a blank page on Safari and Chrome was too frustrating to ignore.

I did some Googling and found a solution in the Q&A section of a Udemy course I took. I implemented that, and the Client Panel showed a login page. Since I hope to show this to future employers who don’t have login credentials, what I needed to show was the register page.

I went back into the code, looked at the default settings in my store.js file, and set allowRegistration to true. I rebuilt and redeployed, but it was still showing Login, with no option to register in the navigation bar. I decided to log in. From there, I went into the settings, changed Allow Registration with the checkbox, logged back out, and then Register became an option in the navbar.

I tried this on Chrome on my phone, but the hamburger drop-down menu wouldn’t open to show either login or register as options. It just sat there. So I shrank my browser window on my computer to match the width of a phone screen, but there the hamburger menu worked. I’m still not sure why. Also, I didn’t know how long the data would persist that changed the registration option.

The next morning, Register was still an option. I asked my wife to try the Client Panel on her phone, and she showed me that the drop-down menu showed both options there. I asked a few friends, and it worked on their phones as well, so I guess I just won’t mess with it!

Yesterday, I spent some time reviewing ES6 on freeCodeCamp.org. I had completed that section months ago, but now that I’m feeling good about using React, I wanted to get that practice back, because using spread operators and destructuring outside of tutorials was giving me some issues. I finished that section feeling a lot better about ES6. Finally. The first time I tried to learn React, I didn’t know ES6 at all, and looking at the almost completely foreign syntax really screwed me up.

Next, I’m working on building a social media site in the MERN stack. I set up mLab and installed some dependencies, including some that I’ve used before, like body-parser, passport, and mongoose, as well as nodemon (is it “no demon” or “node mon”?) as a dev dependency, and also installed some that I’m unfamiliar with at this point, including jsonwebtoken, bcryptjs, and validator. I’ll be cruising those docs now to see what I can do with them.

Today, I decided to take my portfolio live. It’s not perfect, and just looking at it, there are several things I’d like to change. But I need to start moving faster. Perfect being the enemy of good, it was time to just let this one out the door and start working on other things.

I had run the site in local environments several times, so I was fairly confident that pushing the site live would be fairly painless. As with most things in web development, this seemingly simple task was much easier said than done.

I used Gatsby to build my portfolio website, so I checked those docs to see how to deploy. The docs recommended, in the “Preparing to Go Live” section, running a LightHouse Audit, found in the Google DevTools. I ran the audit, and got the following results:

• Performance: 64%
• PWA: 50%
• Accessibility: 52%
• Best Practices: 80%
• SEO: 100%

To boost some of these low numbers, the Gatsby docs have several recommendations, including adding a web manifest. I did that from the Terminal, updated my gatsby-config.js file accordingly (making sure to change the route to my preferred image) and let ‘er rip.

Errors. Errors like I had never seen. Scrolling up and up through the Terminal, all I saw was a sea of red. When I reached the top, the error message was indecipherable. I copied it into Google, but had no luck. This was going to take me down an unnecessary rabbit hole. The single most important thing to me was going live, as soon as possible. Cleanup can be done later.

I deleted the web manifest doc from my node_modules folder, removed the plugin from gatsby-config, and re-saved. From the Terminal, I ran build and serve commands, and everything went back to normal. I decided to go back through the Gatsby docs, but without worrying about optimized performance.

This led me to Surge: “Static web publishing for Front-End Developers”. I had previously installed the CLI, so I jumped right in. I had previously owned my domain name from years ago, and had purchased it from GoDaddy.com back when, as far as I knew, they were the only game in town.

I added a CNAME to my DNS according to the docs on Surge’s website, followed the rest of the docs, and deployed! We were live!

But something wasn’t adding up. My site would be live on Safari one minute, but would redirect to GoDaddy on Firefox, and show a blank white page on Chrome. No good. I played around with this for hours, testing frequently in a variety of browsers, and often getting a variety of inconsistent results. I was losing my mind.

I checked the Gatsby docs for deploying alternatives, and looked into GitHub Pages, Heroku, and Netlify. After noodling around with all three, Netlify seemed to be the clear winner. It was simple, clear, and direct. I followed their prompts, and everything deployed without a hitch.

After we were up and running, I noticed that every link worked, except for the live demo of my Client Panel app. While it works in Firefox, it gives me nothing in Chrome and Safari. But at this point, that’s tomorrow’s problem.