Up and Running

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.

We’ll Do It Live

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.Screen Shot 2018-10-15 at 5.17.51 PM.png

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.