This is now an actual, “working” website. Working is in quotes because A) it’s not a complete website, and B) nothing really works except the link to HOME and the link to LOGIN. Everything else is basically static with the idea that it’ll all get converted to unique components.

Compare this to the mockup…

…and we see that things look pretty darn spot-on. I didn’t go nuts with the content panel because I wasn’t sure what I might need for the content, and besides, I really need to get the authentication portion working first.

Registration

The first thing I need to do is figure out a way to register users. Long ago I used to make customer relation and content management (CRM) systems, but that was long before the age of Intense Security Needs. We’d encrypt our credentials and write session cookies to the user’s local store, but these days it seems like security is a riddle wrapped in an mystery wrapped in an enigma so that at no point can anyone — meaning hackers, presumably — figure out what the hell is going on. If I can let someone else do the heavy lifting of registering my users and keeping track of their credentials, I’m all for it.

Continuing with Firebase, I found a fantastic article on how to get started with Firebase Auth. Like Cloud Firestore, Auth is a Firebase-hosted data store, but specifically for user accounts. More importantly, it exposes a wealth of methods for registering and logging-in, from plain old email and password to the popular third-party providers like Google, Facebook, and Twitter. This results in an almost one click implementation. Almost. The Firebase documentation is fragmentary at best, which is why I was happy to find the above-linked blog post which walked me through the steps in setting up a registration form.

Aside from just straight up implementing user registration, the article illuminated some practical structuring within React, like the use of “higher-order components” which is a design pattern that allows for the encapsulation of other components as a means to reduce repetitive code and pass content down the component tree. I actually use HOC for the top nav bar, but hadn’t considered the pattern for the application of logic to the extent that the article demonstrated.

Like a lot of development paradigms, seeing HOCs in action is a great way towards understanding, but if I were expected to devise some of these patterns myself, I doubt I could. I am a “brute force programmer” meaning that I’ll lean towards the coding convention that requires the fewest files, the least amount of obfuscation, and the simplest overall approach. Sometimes I can get fancy and create components which are reusable or which reduce the overall amount of code, but after reading the how-to-article I feel that I at least know that more succinct yet direct approaches are available, and I am left to feel that I should sit down and contemplate my approaches before I start to actually Do The Code(tm).

Here’s a case where I’ve registered an account using an email address. Firebase has it down as an “email” provider. If I were to use the “Log in with Google” button, then I’d get a popup with the ubiquitous “choose your Google account” UI, and after selecting the appropriate value, would see another entry above, except with the Google icon in the provider column.

I have yet to add in the login portion, nor have I set up the actual use of the registered user information.