Forem: Lee Warrick

Understanding Unix Permissions, chmod, and ls -la

Lee Warrick — Sat, 25 Apr 2020 14:56:44 +0000

Whoa! Lee, Why are you writing about terminal commands? I thought this was a front-end blog?

Listen. I contain multitudes. Plus, you’re gonna run across a permissions issue at some point regardless of where you hang out in the stack, so why not learn a little about what’s going on here?

Cool? Cool. Let’s roll.

Why can’t I run this script!?

Let’s say you’re wanting to run a certain script on your computer. Maybe you downloaded it from somewhere or copied it over from stack overflow. Maybe you wrote your own script, who knows? Let’s say you have a cool script like this one:

#!/bin/bash

echo "Have a great day!"

So you jump into your terminal and run ./my-script.sh and you’re greeted with:

$ ./my-script.sh
permission denied: ./my-script.sh

So you jump onto stack overflow, search ‘run script permission denied’ or something, and you get a terse answer in the way of chmod 744 <filename>. So you copy that into your terminal and run it, not really worrying about the mysteries of Unix:

$ chmod 744 ./my-script.sh
$ ./my-script.sh
Have a nice day!

Satisfied, you go about your business, feeling appropriately greeted by your terminal.

However, deep in the back of your subconscious, you’ve unknowingly unleashed a tiny code demon. This tiny demon waits until you’re showering or about to fall asleep—basically when you’re finally finding that peaceful zen state that’s so hard to channel—and it whispers a question into your brain: “What does that command do?”

For a moment, you wonder why you’re not more familiar with Unix, doubt yourself and your abilities, and then pack those feelings back down into pandora’s box and go about your day.

Where did my dotfiles go?

If you’ve been programming for a minute, you’re probably worked with dotfiles. Maybe your project has a .env file for API keys, or maybe you colossally destroyed a git history and decided that obliterating the .git folder in your project is the last option you’ve got left.

In any case, you jump into your terminal and run your trusty ls command.

$ ls
work stuff morestuff not_file_you_want.js

Fiddlesticks! Where’s my file? It shows up in vscode, why isn’t it here!?

One more trip to stack overflow and you get ls -la as your green checked answer, which gives you this:

$ ls -la
drwxr-xr-x 15 you you 4096 Apr 24 11:16 .
drwxr-xr-x 3 root root 4096 Mar 30 12:09 ..
-rw-r--r-- 1 you you 38 Apr 24 11:04 .mydotfile
drwxr-xr-x 9 you you 4096 Apr 16 09:50 work
drwxr-xr-x 9 you you 4096 Apr 13 09:50 stuff
drwxr-xr-x 9 you you 4096 Apr 11 09:50 morestuff
-rw-r--r-- 1 you you 38 Apr 24 11:04 not_file_you_want.js

Success! There’s my dot file that’s appropriately named .mydotfile. But that little demon in your mind chimes in… ”What are all those letters and dashes at the beginning?”

ARGH! Impostor syndrome! Doubt! Fear! The dark side!

You ask yourself, Why am I so bad at using computers!?

Learn Unix permissions and banish your doubt demons!

Let’s first talk about that weird little string of letters and dashes.

-rw-r--r-- 1 you you 38 Apr 24 11:04 .mydotfile

That string of -rw-r-r--r-- is a list of permissions for that file! More on the meaning of that in a second.

The other information from left to right is the number of links to that file (1), owner, group owner, file size (38), date/time last modified, and the file name.

Now, what about that letter/dash nonsense?

-rw-r--r--

This is actually a grouping of 4 subsets of information.

type | owner | group | everyone else
------------------------------------
-    | rw-   | r--   | r--

For the type, the dash signifies that this is just a regular ol’ file. You’ll see d to signify directories and l for links, and might even see different colors in your terminal to highlight those types of files.

The rest of the columns have three more bits of info, which are specific permissions for each subset of users on the system. ‘Owner’ is the creator of the file, ‘group’ is the group of users that owner belongs to, and the last section is every other user on the system.

As for the letters themselves, they signify (r)ead (w)rite and e(x)ecute. So for the example above we have:

type | owner | group | everyone else
------------------------------------
-    | rw-   | r--   | r--
file | read/ | read  | read
       write

This means you (the owner) can read and write to the file, but other users can only read the file.

Here’s another set of permissions you’ll often see on directories:

type      | owner   | group   | everyone else
------------------------------------------
d         | rwx     | r-x     | r-x
directory | read/   | read/   | read/
            write/    execute   execute
            execute

This means you (again, the owner) can do it all, but others can read and cd into the directory.

Changing Permissions

Great! So now you know what all those crazy letters mean. But how about changing them?

Let’s look at our example directory from above when we ran ls -la:

$ ls -la
drwxr-xr-x 15 you you 4096 Apr 24 11:16 .
drwxr-xr-x 3 root root 4096 Mar 30 12:09 ..
-rw-r--r-- 1 you you 38 Apr 24 11:04 .mydotfile
drwxr-xr-x 9 you you 4096 Apr 16 09:50 work
drwxr-xr-x 9 you you 4096 Apr 13 09:50 stuff
drwxr-xr-x 9 you you 4096 Apr 11 09:50 morestuff
-rw-r--r-- 1 you you 38 Apr 24 11:04 not_file_you_want.js

Let’s say we wanted to change the permissions of the not_file_you_want.js file and add execute permissions for the owner.

To do this, we’ll use the chmod command:

$ chmod u+x not_file_you_want.js

Here the u+x part may trip you up, but take another look. It’s saying (u)ser + e(x)ecute, or add execute permissions to the user.

What about more granular permissions? What if we wanted to remove all permissions from any other users?

We can be ultra specific with chmod:

$ chmod u=rwx,g-rwx,o-rwx not_file_you_want.js

So this command says (u)ser permissions should equal (r)ead, (w)rite, and e(x)ecute. Remove all permissions from the group, and remove all permissions from all other users.

Binary Shortcuts

So now you can explicitly set whatever file permissions you want. But that little brain demon might still be screaming about our first stack overflow answer.

$ chmod 744 ./my-script.sh

What the heck does 744 mean?

This is actually shorthand for -rwxr--r--. Each number represents a user subset. The first number (7) is user, the middle is group, and the last is all other users, just like we showed in our breakdown earlier: rwx | r-- | r--.

Each number is actually a binary representation of the three permissions combined. Let’s look at just the user permissions:

2^2  | 2^1   | 2^0
read | write | execute
---------------------------
1    | 1     | 1

Here we’re indicating we want all three permissions (rwx), so we add 2^2, 2^1, 2^0 together to get 7.

For the other groups:

2^2  | 2^1   | 2^0
read | write | execute
---------------------------
1    | 0     | 0

We only count 2^2 which is equal to 4 for the group and others permissions, which combined with our 7 gives us 744.

Here’s some other common permission examples:

777 = 111 111 111 = rwxrwxrwx
666 = 110 110 110 = rw-rw-rw-
644 = 110 100 100 = rw-r--r--
600 = 110 000 000 = rw-------

Pretty wild right?

So now when you see this command:

$ chmod 700 my-file.sh

You know that means you’re giving the user all permissions and removing all permissions from everyone else. Look at you go, you little Linux Guru 😎.

Parting Thoughts

Special Thanks to my colleague Clay Benson for explaining this to me on a conference call. I have stared at those little strings of rwx for years without bothering to look up what they signify, just chalking it up to terminal magic and resiging myself to ignorance. I was actually stunned at how logical the design of Unix file permissions actually is, and the byte math absolutely floored me when I learned it and inspired me to write this post.

The next time you do some stack overflow linux wizardry, do a little research and you might surprise yourself with how much you learn. I know I will.

How much can a Front-end Developer learn about Machine Learning using only JavaScript?

Lee Warrick — Thu, 13 Feb 2020 16:00:00 +0000

Machine Learning and Artificial Intelligence have been huge buzzwords in the Tech industry for quite some time. Hearing them might make you picture self-driving cars or chat bots in your head and leave you wondering what kind of programming goes into those projects. AI, in particular, has been the stuff of science fiction for so long that it’s hard not to be curious about it now that we’re seeing real-life projects surface in the news.

But what do those terms really mean? A cursory search of any of them will undoubtedly leave you separating science from marketing before you get to any valuable information. I’ve spent the past few months learning and researching Machine Learning and the Data Science field, so I know how difficult it can be to drill through the buzz and hype. This article is about that experience and how far I was able to get as a humble JavaScript developer.

Before we get started though, I want to kick things off with my favorite quote about Machine Learning and AI:

Difference between machine learning and AI:

If it is written in Python, it’s probably machine learning

If it is written in PowerPoint, it’s probably AI

—Matt Velloso on Twitter

I thought Machine Learning was only for geniuses (and I’m no genius)

I first started working with Machine Learning (ML) early on in my career when working with a team that was doing text-recognition work. My job was to create a front-end application that let users send documents to the backend for parsing.

Python is the main squeeze when it comes to ML/AI work for a lot of reasons, so I thought I wouldn’t get much exposure to any ML work as a front-end developer. However, I ended up tangling with ML quite a bit. Text Recognition models are pretty picky about input, so I ended up using JavaScript implementations of Python libraries to pre-process documents in the browser to match the backend. Through this, I also found JavaScript versions of Machine Learning frameworks as well. Not only could you use trained models to predict data in the browser, but you could create and train models there too.

While it was awesome to see that JavaScript can really do all the things, Machine Learning is a specialized field that has massive foundations in calculus and statistics. So while I felt competent in my JavaScript abilities, I felt incompetent when it comes to the kind of higher level math involved in ML. In short, I thought the whole data science field was beyond me as a lowly front-end developer.

After moving on from that work project, I didn’t touch Machine Learning for months.

You don’t need to be a Mathematician to try your hand at Machine Learning

(Pictured: What I thought all Data Scientists looked like before this journey.)

Even though I gave up on ML, I still wanted to learn Python. I run a meetup, so I decided to get some workshops together to teach the community (and myself) Python. I reached out to the local Python User Group. Its organizer, Michael DuPont, and I got together and planned out a series of talks and workshops where Michael would teach, and I would book the venues.

The workshops were awesome, and we were also able to record them for YouTube. That experience taught me a lot about Python and its ecosystem, but also some interesting lessons about Machine Learning.

At the end of the intro talk, Michael introduced TPOT—an automated ML tool—and used it to train a model to predict housing prices in Boston. This was fascinating to me because what TPOT does is take data and figure out how to make a model and train it on its own. It essentially cut out all the math and statistics for you. This planted the seed in my head that maybe, just maybe, being a developer is enough to get your feet wet with ML.

Using JavaScript for Machine Learning

I also run a podcast, and through that, I ended up meeting Gant Laborde, a JavaScript developer with a passion for data science. We interviewed Gant about Machine Learning in JavaScript, and really dug into how to get started with ML.

Gant also revealed that he was working on a JavaScript Machine Learning course. This piqued my interest because almost all ML tutorials focus exclusively on Python. After we were finished recording, I offered myself up as a guinea pig for Gant’s course, and he graciously sent my co-host and I copies of the course to try out ourselves.

Shortly after, Gant released a free intro to Machine Learning course. Naturally, I signed up for that too.

The main course is meant to take 3 weeks, and the intro course is meant to be a 5-day course.

…It took me about 3 months to work through both courses.

My completion time ballooned past the projected 4 weeks for both courses because of my busy schedule, but also because I truly wanted to grasp the material and give myself every chance to learn everything that Gant had poured into the course.

So I took my time ⏳, drank many cups of coffee ☕, and wrote a lot of code 👨‍💻.

Let’s talk about what I’ve learned 🧙‍♂️.

Machine Learning is really about prediction 🔮

The general intro course was a fantastic intro to Machine learning. It taught me that ML is really about boiling a data set down to numbers, analyzing a huge group of those numbers, and then being able to predict outcomes when given data it hasn’t seen before. It also taught me about the types of Machine Learning and their applications in real life.

The Machine Learning and Data Science that we deal with are more about Artificial Narrow Intelligence (ANI) than Artificial General Intelligence (AGN). AGN is the stuff of science fiction: robots that can function like humans and make decisions for themselves, SkyNet, etc. ANI is about focusing on a specific problem or question. Some examples of ANI include figuring out if a picture is of a cat or a dog, predicting sales numbers based on historical data, or detecting when a person’s eyes are open from a video feed.

But how does an algorithm learn to answer those questions?

In the example of the Boston Housing data, the data set has a bunch of features like location, crime rate, proximity to schools, etc. that the computer analyzes alongside the price of the home. An ML algorithm will read thousands of those data points to be able to approximate a home price based on those features.

Think about a line from your middle school math classes. There’s a formula that will tell you what x and y coordinates will fall on that line with 100% accuracy. Let’s say our line has a formula of y = x. Using that formula, we could very easily figure out if a set of coordinates are on that line, right? If you have points (0, 0), (1, 1) and (2, 2), you know that as long as they’re equal, they live on the line.

But how would Machine Learning approach this problem? Imagine you didn’t have a formula that could tell you with 100% accuracy whether a point was on the line or not. How could ML help?

To solve this with ML, you would feed your model thousands of coordinates that are labeled as on or off the specified line. After doing a lot of math and burning a lot of processing time, you’d have a model that could tell you with a certain confidence (a percentage) how likely any given point is to exist on that line.

In a nutshell, Machine Learning is just a computer clumsily learning through trial and error.

This joke tweet really encapsulates the core concept of Machine Learning:

Machine Learning Job Interview:

Me: I’m an expert in machine learning

Interviewer: What’s 9 + 10?

Me: It’s 3.

Interviewer: Not even close. It’s 19.

Me: It’s 16.

Interviewer: Wrong. Its still 19

Me: It’s 18.

Interviewer: No, it’s 19.

Me: It’s 19.

Interviewer: You’re hired.

What kind of coding is involved in Machine Learning?

Thankfully, the inner-workings (calculus and linear algebra 💀) of training a model are abstracted away from us by ML frameworks like TensorFlow. So we don’t have to construct the actual algorithms used to process data and train models.

However, there’s still a level of math that you have to grapple with when dabbling in Machine Learning. You need to first be able to process data to pass into ML algorithms and models. You also need to have some knowledge of ML framework settings and configuration.

Preparing Data

Most of the work done by data scientists is involved in preparing the data. When we interviewed Data Scientist Amelia Bennett on our podcast, she described herself as a high-paid data janitor and described data science itself as a “21st century dirty job”.

If you’ve ever wondered how a computer can learn to parse images, sounds, and language, the answer is math. Anything that can be described mathematically can be translated to numbers and fed into ML models. The job of the data scientist is to not only select the data, but convert it. In computer vision for example, this means converting images to arrays of pixels (RGB and location) that the algorithm can use for training. Natural language processing involves describing soundwaves using math—taking frequency and pitch numbers over time to identify spoken words.

Fortunately, there are tools to help you convert non-number data to numbers out there. Tensorflow has a lot of utilities dedicated to helping you process images for instance. Still, you need to be able to use those tools and know which ones to reach for.

Training Configuration

Machine Learning frameworks abstract away most of the math, but you’re still stuck needing to know how different algorithms affect training. So you won’t be solving any problems on paper, but you’re still going to be reading about mathematical concepts with scary names like softmax, sigmoid, and ReLu.

There’s also something to be said about the amount of terms like those activation function names I mentioned above. When using tensorflow specifically, you might feel like you’ve got more knobs to twist and turn than you really know what to do with. The TensorFlow API is massive , and it’s hard to imagine someone mastering all of it.

Note: You may remember that there are autoML frameworks like TPOT that I mentioned above. These don’t require a ton of configuration, but also give you less control over the outputted result. While these tools are useful, you’ll likely find yourself using something TensorFlow or something similar the further you get into ML.

Guess Work

I personally found the amount of configuration at my fingertips to be completely overwhelming. I am the type of person that loves to know exactly what I’m doing and why. However, this left me at odds with a data scientist’s typical workflow.

Machine Learning requires a lot of experimentation. I used to think that data scientists trained models in one go, but in reality they may train models over and over again before getting desirable results. When training models, there’s many various settings to tweak, and selecting the right ones is more of a matter of trial and error than anything else. I had to let go of my need to understand and comprehend everything before I could embrace the experimentation required to solve ML problems.

To put it another way, data scientists are a bit like fictional mad scientists haphazardly mixing chemicals in a lab—except data scientists are mixing mathematical functions together instead of fluid-filled beakers of various colors.

Examples of Machine Learning with JavaScript

I got a solid foundation in the basics of how Machine Learning works, but what projects have I been able to build with it? Before we get to the code, let’s talk about how to employ ML as a developer.

There’s really two main types of projects when you’re working with Machine Learning: using a pre-trained model , or building and training your own model. I’ve included examples of both below.

Note: These demos were all made from concepts and lessons learned from Gant Laborde’s AI course.

Pre-trained Model Examples:

These are super fun apps to make, and require almost no ML knowledge to pull off. I recommend trying some of these yourself! You can quickly make some impressive ML projects by utilizing browser APIs and web technology.

Image API + MobileNet Example

In this demo, I pulled images from the lorem picsum API and used React to hook them up to MobileNet, which is a pre-trained model that can classify images.

Lorem Picsum is mostly random artsy still-life and landscape photos from Unsplash, so you get some interesting results from MobileNet’s classifications.

Webcam + MobileNet Example

This app connects MobileNet up to the webcam browser API so that you can point your phone/camera at an object and classify it.

(If you’re wondering about some of the crazy results, you should know that MobileNet wasn’t trained recognize humans.)

Browser-based Model Training Examples:

Now we get into the heavy stuff. Beware running these on low-end phones and devices.

These examples take data sets and use them to train models directly in your web browser using JavaScript!

Solving FizzBuzz with TensorFlow

This example feeds a model thousands of numbers (100 through 3100) that have been solved (labeled) using a simple fizzbuzz algorithm. Then it tries to guess whether numbers 1-100 should be fizz, buzz, or fizzbuzz.

Cat/Dog image recognition with TensorFlow

This app uses Gant Laborde’s dogs-n-cats npm package to train a model to recognize random dogs or cats.

Click here to check out the demo on codesandbox. Be warned though, it’s a bit memory/resource intensive to train a model using 2000 images in the browser.

The dogs-n-cats package does most of the prep work for you behind the scenes by pre-processing and pre-packaging all 2000 dog/cat images into tensors for you. All I had to do was feed the images directly into a model for training.

Other Types of Machine Learning

The examples above all involve supervised learning, meaning we are telling the algorithm what to look for and giving it labeled examples to learn from. Supervised learning is fairly simple to wrap your head around, but there’s more methods and applications of ML out there.

Two examples of different ML methods are unsupervised and reinforcement learning. In unsupervised learning, you give the algorithm a data set that’s unlabeled and let it discover and classify things on its own. With reinforcement learning, where the algorithm learns how to accomplish tasks through good or bad outcomes. Think of a computer learning to beat a mario level as an example.

I’d love to dip my toes into these other types of ML at some point, but believe me when I say that getting this far with supervised learning was a huge milestone all on its own!

Are you a Data Scientist now?

Let’s get this out of the way: I am definitely not a data scientist after spending a little time with Machine Learning.

That said, I have learned a lot about what is actually involved in Machine Learning and how Data Scientists have been able to pull off some of the incredible advances we’ve seen in the field. I have a solid understanding of the magic (read: math) that’s behind computer vision, natural language processing, and other miracle technologies.

I also understand the limitations of Machine Learning and know that there’s still quite a lot of work to be done in the field. I’m excited to see what happens as more data sets and better, more accessible ML frameworks become ubiquitous.

As far as training models, I definitely feel like I’m still a novice. There’s so much nuance and intuition involved in selecting proper activation functions, filters, epochs, etc. that I hardly feel qualified to do anything more than guess at how to properly train a model.

I’m also well aware of the massive shortcuts in data preparation I employed. I feel confident that I could train a model from spreadsheet data, but when it comes to preparing and labeling images for training, I still have a long way to go.

Parting Thoughts

Data Science and Machine Learning are really cool things to dip your toes into if you can stomach the mathematics and trial-and-error that’s involved. It’s a challenging area of technology and something that businesses have begun to heavily invest in, so even having a basic understanding of the data science field is invaluable as a developer.

I definitely recommend Gant’s free intro course to ML/AI concepts. If you complete that course and feel like you want to pursue the subject further, I recommend checking out Gant’s paid beginner course on AI/ML in JavaScript as well. Gant worked very hard to make the concepts within approachable and it shows.

I hope to keep advancing my own Machine Learning skills in the future. If you have ideas on where I should go from here, or questions about this post, hit me up on Twitter! I’d love to hear from you.

Just what is JAMstack, anyway?

Lee Warrick — Sat, 18 Jan 2020 16:00:00 +0000

JAMstack is one of those buzzwords that leaves the listener confused whenever it’s uttered (see also PWAs, blockchain, and serverless). Despite the name, JAMstack is a fantastic choice for front-end web applications, and definitely worth your time as a front-end developer.

However, defining “JAMstack” is a tricky thing, and the community knows it. There’s why there’s sites like jamstack.wtf and jamstack.org devoted to explaining just what it is.

Unfortunately, you have to have a solid understanding of web development technologies before explanations of JAMstack start to make sense. So let’s start with the basics.

Let’s Review

When I started out as a developer, I had some knowledge of the front-end ecosystem I was entering. There was of course JavaScript, HTML, and CSS, plus single page application (SPA) frameworks like React, Angular, and Vue. I understood two potential options for making web apps with this tooling.

The first is the old-school server-rendered route: build your pages in HTML/CSS/JS ahead of time and let the server serve those. Or you could have the server build those pages with a templating language (handlebars, EJS, jinja, etc) as requests came in. The downside here was that either your content was static (that’s no fun), or your server was doing a lot of work. Plus, each time the user requested a new page they would see a white screen as the server built/found the page and sent it to the user’s browser.

The more modern method uses client-side rendering. You write an SPA, and send a big payload of JavaScript to your user upfront when they visit your site. This is the buy-once, cry-once method. The user waits while all the JavaScript downloads, then again while it renders the requested page. After that initial hit, the app is buttery smooth and provides a great experience, because each page change after that is rendered with JavaScript running in the user’s browser. Still, that initial page-load is the important one. Users are impatient, and a long initial load time means you’re losing traffic.

This always made me think of those signs you see in restaurants and mechanic shops. You know the one:

We offer three kinds of Services:

GOOD - FAST - CHEAP

…but you can only pick two.

The Chimera Option

It turns out there’s another option. This is where things start to get sticky, though. Single page applications are already difficult to think about, and typically we like to think about them as using client-side, on-demand rendering only. However it’s now possible to mix and match dynamic and static content on both the client and server.

There’s two main camps using this hybrid methodology to web app rendering and delivery. The first is server-rendered single page applications, and the second is JAMstack.

Server-Rendered SPAs

With a server-rendered SPA, you have to maintain your own server. On initial hit the server pre-renders the page the user requested in HTML/CSS and sends it down to the user. This means the users gets to see a dynamically-rendered page relatively quickly. The server also sends a mess of JavaScript that loads in the background. Now when the user navigates to the next page, the app functions like an SPA and uses that mess of JavaScript to render the new page, instead of asking the server for it. The app only asks the server for data (typically JSON) after that initial page-load.

Some examples of this technology are NextJS, NuxtJS and Angular Universal. For what it’s worth, I’ve used both NextJS and NuxtJS, and they are both fantastic.

The only problem with this method is that, again, you need to maintain your own server. Running your own server is much more costly than a static hosting solution (using someone else’s server). There’s also some potential security liability involved.

Pre-Rendered SPAs

You’re probably thinking this is a bit silly. The whole point of an SPA is to have a dynamic, on-the-fly rendering of your application at any given point, right? If you pre-render everything, what are you left with?

The answer is a lot, actually. When we build a single page app, we often have various routes or views baked in that don’t change. You may have a “home” page, an “about” page, and then your “main” content. Those home and about changes don’t really require dynamic data to render anything, but with a traditional SPA they’re rendered dynamically all the same. Even the “main” stuff probably lives on a route in some kind of wrapper component, right?

With a pre-rendered SPA, when we “build” the application (bundle with Webpack) we designate what can be safely pre-rendered and what needs to be left alone to render on the client’s machine at runtime. Then our bundler pre-renders as much of the application as possible (all the routes), and leaves the rest to be rendered with JavaScript at runtime.

Instead of a single HTML page in your build folder as an entrypoint to your app, you’ll have multiple. So when the user asks to visit the “about” page instead of the home page, that “about” page HTML file is ready before the request comes in. After that initial page-load, the JavaScript takes over and handles the page transitions and dynamic portions of the application.

The result is an SPA that has a fast initial load, instead of a long initial load, meaning a great user experience without the cost and maintenance of a server.

Some examples of this technology are GatsbyJS, Gridsome, NextJS, and NuxtJS.

Gatsby and Gridsome are more purpose-built for “static”-site generation, while Next and Nuxt are swiss army knife tools that allow you to do both server-rendering and static-site generation.

Note : There’s a lot of confusion about Static-Site Generators (SSG). A traditional SSG (Hugo, Jekyll, etc) takes your templated code and generates static HTML files from it. Gatsby and Gridsome are actually a lot more than SSGs. They allow you to smartly pre-build and template content in a lot of various ways.

For example, this blog is built from markdown files, and at build time, Gatsby compiles the markdown files into a React application. You could also query an API or CMS like Wordpress to get your data dynamically at build time. However you’re still free to make API calls at runtime too. You’re still building a React app. You’re just pre-rendering some of it.

Are you going to talk about JAMstack or not?

Yes! Now we can talk about what is and isn’t JAMstack. JAMstack stands for JavaScript, APIs, and markup. I find that definition entirely unhelpful, hence the lengthy lead-in for this segment.

JAMstack is really about making awesome websites without running your own server, or at least decoupling your “static” front-end from your back-end data sources. The front-end app should be composed of static files only and be its own codebase. That means no server-rendered content.

This sounds a little restrictive, but trust me, you can build a lot of dynamic content following these rules. Just about anything you can build with create-react-app or an SPA can be a JAMstack site. You can build Blogs, e-commerce sites, marketing pages, and full on web apps all with JAMstack methods.

Clear as mud, right?

JAMstack FAQ:

I had a lot of questions on my journey to understanding JAMstack. Let’s try to address some of those points of confusion.

If it’s pre-rendered, how do I update it?

You have to rebuild the site/app everytime you update something that is pre-rendered. So if I make a new blog post, I have to rebuild the site and redeploy it.

However, that doesn’t mean you have to redeploy everytime your app needs to make an API call. Remember that your site can still run JavaScript on the front-end.

If I have to redeploy to update the site, how do my users make updates?

Ah yes, consider the scenario where you make a blog for someone else. They probably don’t want to write posts in markdown and push code to github, right? That’s OK! You can automate your build step. If they make a new post, all you need to do is trigger a build to happen.

Netlify CMS is based around this idea. The user makes their edits on a dashboard (also an SPA), and when they “save”, they’re really committing the code with git, which then triggers a rebuild.

I don’t want my users touching git. Ever. I’d rather use Wordpress.

Ah, but you can do that too! You’d have to host your own Wordpress server somewhere, but Wordpress has a JSON API. When your user makes a new post, you simply have to trigger your static site to build somehow. If you’re using Gatsby or Gridsome, the build step queries your Wordpress API (or any other CMS, really) for all the available posts and builds the site.

What about user comments on blog posts?

That’s OK! You can still do all the things we just talked about, and just make a API calls for comments on the fly at runtime. You could build your own comment microservice, or use a premium service FaunaDB to store comments for you.

What are the advantages to JAMstack?

Typically, you can have faster page loads and a much better user experience using JAMstack methods. Also, because your front-end is detached from the server, security issues are greatly diminished. Plus, it’s mostly free or at least very cheap to host a static site.

When wouldn’t I use JAMstack for a site then?

If all of your front-end content needs to be generated on the fly, JAMstack is not a great choice. For example, if you need dynamic routes, that makes it very difficult to build a static front-end app. Similarly, if you’re building a server anyway, maybe it makes more sense to serve the front-end as well.

Can you show me some examples of JAMstack sites?

Sure! I’ve built a whole mess of them.

My blog - Built with Gatsby, hosted on Github Pages
The Tech JR Podcast site - Built with Gridsome, hosted on Netlify and mp3s stored on AWS S3
Babelfish, a translation app - Built with Gatsby and Google’s translation API, hosted on Github pages
Goaler, a todo app - Built with Create-React-App and Firebase, hosted on Github Pages
This Pokedex App - Built with the Vue CLI and the Poke-API, hosted on Github Pages

Parting thoughts

JAMstack, like most great technological trends, is a pretty awesome solution with a crummy name. It’s not a perfect solution by any stretch, but it empowers front-end developers to build all kinds of sites and applications using their exisiting skills.

So what are you waiting for? Get out there and build something!

The Problem with React's Context API

Lee Warrick — Thu, 28 Nov 2019 16:00:00 +0000

Originally published at leewarrick.com/blog

React’s context API is awesome. As someone that looked at Redux as a junior developer and instantly felt defeated, learning about context was a relief. I used it in my apps, quickly forgot about Redux, and never looked back.

That is, until I heard about the supposed performance problems with the Context API. Now, the big names in the React community will tell you not to worry about performance unless you start seeing issues. And yet, I keep hearing about context problems from other developers. One fellow even mentioned his boss banning the use of Context on their project.

Let’s review the Context API in case you’re unfamiliar before we talk about its problems.

Why use the context API?

The Context API is useful for sharing state between components that you can’t easily share with props. Here’s an example of a button component that needs to set the state of a distant ancestor:

(Note: To see live versions of these snippets, please go to the original post)

const { useState } = React

function CountDisplay({ count }) {
  return <h2>The Count is: {count}</h2>
}

function CountButton({ setCount }) {
  return (
    <button onClick={() => setCount(count => count + 1)}>
      Increment
    </button>
  )
}

const OuterWrapper = ({setCount}) => <InnerWrapper setCount={setCount}/>
const InnerWrapper = ({setCount}) => <CountButton setCount={setCount}/>

function App() {
  const [count, setCount] = useState(0)
  return (
    <div>
      <CountDisplay count={count} />
      <OuterWrapper setCount={setCount}/>
    </div>
  )
}

render(App)

The button component is within a few other components further down the tree, but still needs to access state from higher up in the app. So we have to pass setCount down to each component to finally get it to our CountButton component. This is affectionately known as “prop-drilling”, and used to be a huge pain point in React.

The Context API makes short work of situations like this, thankfully.

How to use the Context API

Kent C. Dodds has a fantastic blog post that I refer to whenever I implement the Context API. If you don’t have time to read that, here’s the short version: Context is a way to share state between unrelated or distant components. All you have to do is wrap your components in a Context.Provider and then call useContext(Context) inside that component to access your state and helper functions.

Here’s our counter example with context:

const {useContext, useState, createContext} = React

const AppContext = createContext()

function AppProvider(props) {
  const [count, setCount] = useState(0)
  const value = { count, setCount }
  return (
    <AppContext.Provider value={value}>
      {props.children}
    </AppContext.Provider>
  )
}

function CountDisplay() {
  const { count } = useContext(AppContext)
  return <h2>The Count is: {count}</h2>
}

function CountButton() {
  const { setCount } = useContext(AppContext)
  return (
    <button onClick={() => setCount(count => count + 1)}>
      Increment
    </button>
  )
}

const OuterWrapper = () => <InnerWrapper />

const InnerWrapper = () => <CountButton />

function App() {
  return (
    <div>
      <AppProvider>
        <CountDisplay/>
        <OuterWrapper/>
      </AppProvider>
    </div>
  )
}

render(App)

Here we have CountDisplay and CountButton components that both need to interact with the higher-level count state in our context. We start by making a context with createContext, then a provider component in AppProvider to wrap our dependent components, and finally call useContext in each component to pull out the values we need. It doesn’t matter how far apart the components are as long as they’re wrapped in a provider.

Pretty great right?

Kent C. Dodd’s Optimizations 📈

We can improve on this a little bit by implementing some stuff that Kent has in his article on state management. Let’s take a look:

const {useContext, useState, createContext, useMemo} = React
const AppContext = createContext()

// instead of calling useContext directly in our components,
// we make our own hook that throws an error if we try to
// access context outside of the provider
function useAppContext() {
  const context = useContext(AppContext)
  if (!context)
    throw new Error('AppContext must be used with AppProvider!')
  return context
}

function AppProvider(props) {
  const [count, setCount] = useState(0)
  // here we use useMemo for... reasons.
  // this says don't give back a new count/setCount unless count changes
  const value = useMemo(() => ({ count, setCount }), [count])
  return <AppContext.Provider value={value} {...props} />
}

function CountDisplay() {
  const { count } = useAppContext()
  return <h2>The Count is: {count}</h2>
}

function CountButton() {
  const { setCount } = useAppContext()
  return (
    <button onClick={() => setCount(count => count + 1)}>
      Increment
    </button>
  )
}

const OuterWrapper = () => <InnerWrapper />

const InnerWrapper = () => <CountButton />

function App() {
  return (
    <div>
      <AppProvider>
        <CountDisplay />
        <OuterWrapper />
      </AppProvider>
    </div>
  )
}

render(App)

The first thing we do is throw an error if we try to access the context outside of our provider. This is a great idea to improve the developer experience of your app (aka: make the console scream at you when you forget how context works).

The second thing is to memoize our context value to only re-render if the count changes. Now, useMemo is a difficult thing to wrap your head around, but the basic gist is that when you memoize something, you’re saying that you won’t return that value again unless your specified value changes. Kent has a great article on that too if you want to read more.

I can’t discern a difference between using useMemo and not using it, but I would venture that if you’re doing some heavy lifting in your Context Provider, it might be beneficial to apply memoization. If you read Kent’s article on useMemo and useCallback he cautions against using them unless you start to see performance hits. (Full Disclosure: I’ve never needed to use either one.)

Kent also spreads his props on the provider instead of using props.children, which is a neat trick, so I included that as well.

The Context API’s Dirty Little Secret 🤫

Boy, the Context API sure is great. It’s super easy to use compared to Redux and requires a lot less code, so why wouldn’t you use it?

The problem with context is simple: Everything that consumes a context re-renders everytime that context’s state changes.

That means that if you’re consuming your context all over the place in your app, or worse, using one context for your entire app’s state, you’re causing a ton of re-renders all over the place!

Let’s visualize this with a simple app. Let’s make a context with a counter and a message. The message will never change, but be consumed by three components that display the message in a random color on each render. The count will be consumed by one component, and be the only value that changes.

That sounds like a middle school math problem, but if you look at this code and the resulting app, the problem becomes blatantly obvious:

const {useContext, useState, createContext} = React
const AppContext = createContext()

function useAppContext() {
  const context = useContext(AppContext)
  if (!context)
    throw new Error('useAppContext must be used within AppProvider!')
  return context
}

function AppProvider(props) {
  // the count for our counter component
  const [count, setCount] = useState(0)
  // this message never changes!
  const [message, setMessage] = useState('Hello from Context!')
  const value = {
    count,
    setCount,
    message,
    setMessage
  }
  return <AppContext.Provider value={value} {...props}/>
}

function Message() {
  const { message } = useAppContext()
  // the text will render to a random color for
  // each instance of the Message component
  const getColor = () => (Math.floor(Math.random() * 255))
  const style = {
    color: `rgb(${getColor()},${getColor()},${getColor()})`
  }
  return (
    <div>
      <h4 style={style}>{message}</h4>
    </div>
  )
}

function Count() {
  const {count, setCount} = useAppContext()
  return (
    <div>
      <h3>Current count from context: {count}</h3>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  )
}

function App() {
  return (
    <div>
      <AppProvider>
        <h2>Re-renders! 😩</h2>
        <Message />
        <Message />
        <Message />
        <Count />
      </AppProvider>
    </div>
  )
}
render(App)

Everything re-renders when we click increment 😱.

The message components don’t even use the count from our context, but they re-render anyway. Yikes!

What about memoization?

Maybe we just forgot to use useMemo like Kent did in his example. Let’s memoize our context and see what happens:

const {useContext, useState, createContext, useMemo} = React
const AppContext = createContext()

function useAppContext() {
  const context = useContext(AppContext)
  if (!context) throw new Error('useAppContext must be used within AppProvider!')
  return context
}

function AppProvider(props) {
  const [count, setCount] = useState(0)
  const [message, setMessage] = useState('Hello from Context!')
  // here we pass our value to useMemo,
  // and tell useMemo to only give us new values
  // when count or message change
  const value = useMemo(() => ({
    count,
    setCount,
    message,
    setMessage
  }), [count, message])
  return <AppContext.Provider value={value} {...props}/>
}

function Message() {
  const { message } = useAppContext()
  const getColor = () => (Math.floor(Math.random() * 255))
  const style = {
    color: `rgb(${getColor()},${getColor()},${getColor()})`
  }
  return (
    <div>
      <h4 style={style}>{message}</h4>
    </div>
  )
}

function Count() {
  const {count, setCount} = useAppContext()
  return (
    <div>
      <h3>Current count from context: {count}</h3>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  )
}

function App() {
  return (
    <div>
      <AppProvider>
        <h2>Re-renders! 😩</h2>
        <Message />
        <Message />
        <Message />
        <Count />
      </AppProvider>
    </div>
  )
}
render(App)

Nope! Memoization with useMemo doesn’t help at all!

What about components that don’t consume Context, do they re-render?

That’s an excellent question, let’s test it with a Message component that doesn’t consume context:

const {useContext, useState, createContext, useMemo} = React
const AppContext = createContext()

function useAppContext() {
  const context = useContext(AppContext)
  if (!context) throw new Error('useAppContext must be used within AppProvider!')
  return context
}

function AppProvider(props) {
  const [count, setCount] = useState(0)
  const [message, setMessage] = useState('Hello from Context!')
  const value = useMemo(() => ({
    count,
    setCount,
    message,
    setMessage
  }), [count, message])
  return <AppContext.Provider value={value} {...props}/>
}

// this component does NOT consume the context
// but is still within the Provider component
function IndependentMessage() {
  const getColor = () => (Math.floor(Math.random() * 255))
  const style = {
    color: `rgb(${getColor()},${getColor()},${getColor()})`
  }
  return (
    <div>
      <h4 style={style}>I'm my own Independent Message!</h4>
    </div>
  )
}

function Message() {
  const { message } = useAppContext()
  const getColor = () => (Math.floor(Math.random() * 255))
  const style = {
    color: `rgb(${getColor()},${getColor()},${getColor()})`
  }
  return (
    <div>
      <h4 style={style}>{message}</h4>
    </div>
  )
}

function Count() {
  const {count, setCount} = useAppContext()
  return (
    <div>
      <h3>Current count from context: {count}</h3>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  )
}

function App() {
  return (
    <div>
      <AppProvider>
        <h2>Re-renders! 😩</h2>
        <Message />
        <Message />
        <Message />
        <IndependentMessage />
        <Count />
      </AppProvider>
    </div>
  )
}
render(App)

Well, this is the only good news so far. Only components that call useContext re-render whenever the context’s state changes.

Still, this is bad news for our app. We don’t want to trigger a bunch of unnecessary re-renders everywhere we use a context.

Imagine if those message components were doing a lot of work like calculating animations, or if we had a huge React app with lots of components dependent on our context. That could lead to pretty serious performance issues, right?

Should we stop using Context?

I’ll go ahead and say this now: no, this isn’t a reason to stop using context. There’s a ton of apps out there using context and chugging along just fine, including a bunch of my own apps.

Still, performance is kind of a big deal. I don’t want to leave you sitting up at night worrying about the Context API’s dirty little secret. So let’s talk about some ways to deal with this re-render business.

Option 1: Don’t worry at all. Keep on Context’n like you do. YOLO 🤪!

I’ve basically used Context a whole bunch in a lot of various apps without memoization, at the top level of my app, and consumed by a bunch of components without noticing any performance hits at all. Like I said before, a lot of the React folks say you shouldn’t even worry about performance optimizations until you see performance impacts.

Still, this strategy won’t work for everyone. You may already have performance issues in your app, or if your app processes a lot of logic or animations, you may see performance issues as your app grows and end up doing some serious refactoring down the road.

Option 2: Use Redux or Mobx

Redux and Mobx both use the context API, so how do they help? The store that’s shared by these state management libraries with context is a little different from sharing state directly with context. When you’re using Redux and Mobx, there’s a diffing algorithm at work that makes sure to only re-render the components that actually need to re-render.

Still, context was supposed to save us from having to learn Redux and Mobx! There’s a lot of abstractions and boilerplate involved in using a state management library, making it an unattractive solution to some folks.

Plus, isn’t keeping all of our state in global state a bad practice?

Option 3: Use Multiple Contexts, and keep state close to its Dependent Components

This solution takes the most finesse to pull off, but gives you the best performance without reaching for Redux and Mobx. It relies on being smart about your state management choices, and only passing state up to a context if you need to share it between distant components.

There’s a few key tenants to this strategy:

Let a component manage its own state if it can. This is a good practice to follow regardless of your choice of state management. For example, if you have a modal that needs to keep track of an open/closed state, but no other components need to know if that modal is open, keep that open/closed state in the modal. Don’t push state into context (or Redux) if you don’t have to!
If your state is shared between a parent and a few children, just prop it down. This is the old school method of sharing state. Just pass it as props to the children components that need it. Passing props or “Prop-drilling” can be miserable with deeply nested components, but if you’re only passing things down a few levels, you should probably just do it.
If the previous two things fail, use context but keep it close to the components that depend on it. This means if you need to share some state, like a form for instance with multiple components, go ahead and make a separate context for just the form and wrap the form components in your provider.

That last one deserves an example. Let’s apply it to our problem app from before. We can fix those re-renders by separating the message and count into their own contexts.

const { useContext, useState, createContext } = React
const CountContext = createContext()

// Now count context only worries about count!
function useCountContext() {
  const context = useContext(CountContext)
  if (!context)
    throw new Error('useCountContext must be used within CountProvider!')
  return context
}

function CountProvider(props) {
  const [count, setCount] = useState(0)
  const value = { count, setCount }
  return <CountContext.Provider value={value} {...props}/>
}

// And message context only worries about message!
const MessageContext = createContext()

function useMessageContext() {
  const context = useContext(MessageContext)
  if (!context)
    throw new Error('useMessageContext must be used within MessageProvider!')
  return context
}

function MessageProvider(props) {
  const [message, setMessage] = useState('Hello from Context!')
  const value = { message, setMessage }
  return <MessageContext.Provider value={value} {...props}/>
}

function Message() {
  const { message } = useMessageContext()
  const getColor = () => (Math.floor(Math.random() * 255))
  const style = {
    color: `rgb(${getColor()},${getColor()},${getColor()})`
  }
  return (
    <div>
      <h4 style={style}>{message}</h4>
    </div>
  )
}

function Count() {
  const {count, setCount} = useCountContext()
  return (
    <div>
      <h3>Current count from context: {count}</h3>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  )
}

function App() {
  return (
    <div>
      <h2>No Unnecessary Re-renders! 😎</h2>
      <MessageProvider>
        <Message />
        <Message />
        <Message />
      </MessageProvider>
      <CountProvider>
        <Count />
      </CountProvider>
    </div>
  )
}
render(App)

Now our state is only shared with the components that care about that state. When we increment, the colors of our message components stay the same because count lives outside of messageContext.

Final Thoughts

Although this article’s title is a little incendiary and the “problem” with context may not be the boogie man some might envision it to be, I still think this is worth talking about. React’s flexibility makes it both a great framework for beginners as well as a devastating footgun for those that don’t know its inner-workings. I don’t forsee a lot of people tripping over this particular detail, but if you’re using context and seeing performance issues, it’s a good thing to know!

Like this post? Please subscribe to my newsletter and check out my podcast!

What are debounce and throttle functions, and how do you write them in JavaScript and React?

Lee Warrick — Thu, 17 Oct 2019 16:00:00 +0000

Originally published at leewarrick.com/blog

Have you ever heard the story of the QWERTY layout on a keyboard? The popular legend is that it was too easy to type if the letters were arranged alphabetically, and this caused mechanical typewriters to jam. The most common letters were too close together, supposedly. So to fix this, the QWERTY layout was invented, to slow down the typist.

This Dilbertian engineering idea is eerily similar to what a debounce function does.

What is a debounce?

A debounce function is meant to slow down something in your application, typically a function call. The best way to wrap your head around this is by example.

Consider this: you have a search input on your site somewhere, and as the user types, you want to go fetch some search results to try and match what the user is looking for before they finish typing.

Piece of cake!, you think. With React, you can attach your API call to your input’s onChange event like so:

(Note: If you want to see the live versions of these example snippets, please check out the original post.)

function SearchForm() {
  const [inputVal, setInputVal] = React.useState("")
  const [callCount, setCallCount] = React.useState(0)

  function handleChange(e) {
    setInputVal(e.target.value)
    // let's say this was an API call
    // to add auto-complete data
    setCallCount(callCount + 1)
  }

  return (
    <div>
      <h2>Type in this Box ⬇️</h2>
      <input onChange={handleChange} value={inputVal}/>
      <p>Current Data: {inputVal}</p>
      <p>Calls Done: {callCount}</p>
    </div>
  )
}

Notice that as you type in the search box, if your API function is attached to your input’s onChange event, you’ll make an API call every time the user presses a key 😱. If you couple this with the small delay it takes to make an API call, you can imagine the traffic jam that this would cause as you have multiple API calls being made and flooding back in.

This isn’t what we imagined when we first cooked up this auto-populating search box scheme. What we really want to do is to make our API call when the user pauses or stops typing.

This is the purpose of a debounce function, to limit the amount of calls that can happen in a given amount of time.

How to debounce a function in JavaScript

So we need to fire fewer API calls, but how do we do it?

Before we jump into React, let’s give this a shot with regular JavaScript. Let’s put our fake API call in its own function, then wrap it in our debounce function.

let callCount = 0

// this is just a promise that resolves after 300ms
// and console logs a counter
function fakeAPICall() {
  return new Promise(resolve => {
    setTimeout(() => {
      callCount++
      console.log("Calls Made:" + callCount)
      resolve()
    }, 300)
  })
}

fakeAPICall() // 1
fakeAPICall() // 2
fakeAPICall() // 3

function debounce(callback) {
    // each call to debounce creates a new timeoutId
    let timeoutId
    return function() {
      // this inner function keeps a reference to
      // timeoutId from the function outside of it
      clearTimeout(timeoutId)
      timeoutId = setTimeout(callback, 800)
    }
}

// wraps the fakeAPICall function and returns
// a function that calls fakeAPICall
const debouncedFakeApiCall = debounce(fakeAPICall)

// all these calls cancel each other
// Until the last call finally happens after 800 ms
debouncedFakeApiCall()
debouncedFakeApiCall()
debouncedFakeApiCall()
debouncedFakeApiCall()
debouncedFakeApiCall()
debouncedFakeApiCall()
debouncedFakeApiCall() // 4

Success!

Without a debounce, we get 3 calls, but with a debounce, we only fire an API call on the last function call.

How it works

The most basic, critical piece of this debounce function is to delay the actual API call, then as more calls come in, cancel and reset the delay for the API call. We do this with setTimeout and clearTimeout in the JavaScript above.

If you noticed the debounce function taking a function and returning a another function, that is an example of a closure in JavaScript. When we debounce a function, we pass our original function in, and wrap it in another function that delays calls to the original. In this way our debounce function is reusable throughout our program. We could debounce as many different functions as we want, because each one has its own timeoutId variable.

How to write a debounce function in React

React allows us to encapsulate logic in components, so we can skip the fancy JavaScript closures and just use our component to write a debounce function.

Let’s take a look:

// just an async helper
function fakeAPICall() {
  return new Promise(resolve => {
    setTimeout(resolve, 300)
  })
}

function SearchForm() {
  const [inputVal, setInputVal] = React.useState("")
  const [query, setQuery] = React.useState("")
  const inputRef = React.useRef("")
  const [callCount, setCallCount] = React.useState(0)
  const timeoutId = React.useRef()

  function handleChange(e) {
    setInputVal(e.target.value)
    // mimic the value so we can access
    // the latest value in our API call
    inputRef.current = e.target.value
  }

  React.useEffect(() => {
    // if the user keeps typing, stop the API call!
    clearTimeout(timeoutId.current)
    // don't make an API call with no data
    if (!inputVal.trim()) return
    // capture the timeoutId so we can
    // stop the call if the user keeps typing
    timeoutId.current = setTimeout(() => {
      // grab our query, but store it in state so
      // I can show it to you below in the example 😄
      setQuery(inputRef.current)
      fakeAPICall()
      // here we pass a callback so we get the current callCount value
      // from the useState hook's setter function
      // we use a Ref for timeoutId to avoid this same problem
      .then(() => setCallCount(callCount => callCount + 1))
    }, 800)
  }, [inputVal])

  return (
    <div>
      <h2>Type in this Box ⬇️</h2>
      <input onChange={handleChange} value={inputVal}/>
      <p>Current Data: {inputVal}</p>
      <p>Query Sent: {query}</p>
      <p>Calls Done: {callCount}</p>
    </div>
  )
}

render(SearchForm)

Now as we type, the component won’t actually make any API calls until the typing stops.

The only difference here is that instead of writing a closure, we’re using a React Ref for our timeoutId. Refs are React’s version of instance variables, so each SearchForm component that we make should get its own timeoutId. If you want to learn more about Refs and useEffect, I wrote another post on that topic.

What is a throttle?

This might not be exactly what you imagined when you envisioned this functionality. For example, as you type into Google search, you still get autocomplete suggestions as you type, even if you haven’t stopped typing.

So while our previous examples will ensure we do the fewest API calls possible, we may want to tweak our solution to make an API call every so often as the user types. This would be a throttle function.

How to write a throttle in JavaScript

Let’s tweak our JavaScript debounce implementation so that we only make our API call every 800ms.

let callCount = 0

function fakeAPICall() {
  return new Promise(resolve => {
    setTimeout(() => {
      callCount++
      console.log("Calls Made:" + callCount)
      resolve()
    }, 300)
  })
}

function throttle(cb) {
    let makingCall
    return function() {
      // if I'm in progress of making an API call,
      // don't trigger another one
      if (makingCall) return
      // set up API call to fire
      makingCall = true
      // give the user some time to type by delaying the actual call
      setTimeout(() => {
        makingCall = false
        cb()
      }, 1000)
    }
}

const throttledFakeApiCall = throttle(fakeAPICall)

// imagine the user starting and stopping typing
// we'll only make a call every 800ms
throttledFakeApiCall() // 1
throttledFakeApiCall()
throttledFakeApiCall()
setTimeout(() => {
  throttledFakeApiCall()
  throttledFakeApiCall()
}, 600)
setTimeout(() => {
  throttledFakeApiCall() // 2
  throttledFakeApiCall()
}, 1200)
setTimeout(() => {
  throttledFakeApiCall()
  throttledFakeApiCall()
}, 1800)
setTimeout(() => {
  throttledFakeApiCall() // 3
  throttledFakeApiCall()
}, 2400)

Now as our throttle function fires, we are limiting our calls to happen every 800ms.

How it works

This new version uses a simple true/false value to determine if we should trigger more calls instead of clearing the timeout and cancelling previous calls. Now the first call to the throttled function tees up the call, and the subsequent calls are ignored until the API call is complete.

How to write a throttle in React

Let’s apply this same functionality to our previous React example.

// just an async helper
function fakeAPICall() {
  return new Promise(resolve => {
    setTimeout(resolve, 300)
  })
}

function SearchForm() {
  const [inputVal, setInputVal] = React.useState("")
  const [query, setQuery] = React.useState("")
  const inputRef = React.useRef("")
  const [callCount, setCallCount] = React.useState(0)
  const makingCall = React.useRef(false)

  function handleChange(e) {
    setInputVal(e.target.value)
    // mimic the value so we can access
    // the latest value in our API call
    inputRef.current = e.target.value
  }

  React.useEffect(() => {
    // if there's no value or we've already triggered a call
    // prevent further calls
    if (!inputVal.trim() || makingCall.current) return
    makingCall.current = true
    setTimeout(() => {
      // again, this setQuery is just so I can
      // render the query below.
      // if this API call were real, we'd probably
      // pass the query into the API call function
      setQuery(inputRef.current)
      fakeAPICall()
      .then(() => {
        setCallCount(callCount => callCount + 1)
        makingCall.current = false
      })
    }, 1000)
  }, [inputVal])

  return (
    <div>
      <h2>Type in this Box ⬇️</h2>
      <input onChange={handleChange} value={inputVal}/>
      <p>Current Data: {inputVal}</p>
      <p>Query Sent: {query}</p>
      <p>Calls Done: {callCount}</p>
    </div>
  )
}

render(SearchForm)

Great Success! Now as the user types, every 800ms we make a call for an autocomplete suggestion. This means more API calls, but better user experience , at least in the case of our search autocomplete example.

Parting Thoughts

So there you have it: throttling and debounce functions in JS and React.

But would you ever implement this yourself in real life?

Sure! If you just needed simple functionality like this, you could absolutely manage your own debounce logic/helpers in your app. However, there's no shame in pulling in Lodash and just using the debounce or throttle functions that they’ve implemented.

I find it fun to try and implement my own solutions, and I think it’s worth the mental gymnastics to give this stuff a shot in your own code every once in a while. But don’t be fooled, nobody will judge you if you reach for a third-party solution!

Like this post? Please subscribe to my newsletter and check out my podcast!

Front-end Fisticuffs: Angular vs React vs Vue in 2019

Lee Warrick — Sat, 05 Oct 2019 14:00:00 +0000

Originally published at leewarrick.com/blog

Being a front-end developer is a bit like being a cowboy in a rodeo. As a developer, you’ll find yourself wrangling a new framework over and over because of the speed at which the front-end landscape evolves. Sure, learning comes with the territory as a developer, but front-end development in particular is becoming quite the skillset to maintain.

The fact is, you’re likely going to need to know at least one if you’re going to become a web developer. Before we talk about choosing one to spend your time on, let’s first highlight the problems they solve.

Why use a framework?

Three weeks into a boot camp, I was amazed with the things I could build with HTML/CSS/JS, including a dice-roll based RPG for the browser.

I’ve often wanted to make improvements to that game, but the thought of adding features or refactoring has held me back. The problem is, it’s written with a thousand lines of spaghetti jQuery. I can only imagine the challenge of working on a project like a banking application before frameworks came onto the scene.

Front-end frameworks are a response to the challenge of increased complexity and scale in web applications. As we began making bigger web applications that do more and more for the user, we had to find a way to wrangle increasing amounts of logic, traffic, and code.

Frameworks handle the problem of scope by separating code into components. A component can be purely visual, functional, or both. For the most part, JavaScript you write in a component is scoped to that component, providing isolation from other parts of the codebase. You don’t have to worry as much about conflicting code when using components. Components are also reusable , meaning you can accomplish more with less code.

Frameworks have performance benefits over plain JavaScript or jQuery. Specifically, frameworks optimize re-rendering , or in laymen’s terms, updating the page’s HTML. JavaScript’s DOM API (all the document.getElementById stuff), is resource intensive for the browser. Frameworks increase performance by minimizing the actual changes to the HTML.

Frameworks also help mitigate large amounts of traffic to a website. Instead of having one server build a new HTML file for each user and request, we can simply send the entire app to each user and let the user’s browser handle re-rendering. This way the server only has to serve HTML/CSS/JS once, and can communicate to the browser with only data after that.

But…

There’s a few downsides to frameworks. It’s more JavaScript for the browser to run, which can be costly in terms of load times when a user first visits your site. It’s also another layer of complexity for you to deal with as a developer, adding to your growing list of skills to maintain.

If you’re building a static site like a business information page, you might not need a framework. But for complex applications like your banking website or the game I mentioned above, a framework can bring a lot to the table, albeit with its own costs.

The Big 3: Angular, React, and Vue

Before we talk about picking a framework, let’s talk about the differences between them. As of 2019, there’s three big players in the JavaScript front-end framework game: Angular, React and Vue.

Angular

Angular is a Google invention. It all started with AngularJS, which exploded onto the scene and saw widespread use. Then came React, and the Angular team rewrote the entire framework completely and called it Angular 2 (Then they skipped version 3 and went directly to 4 and we’re currently on version 8).

Basically AngularJS and Angular 2+ are completely different beasts, and so a large amount of the AngularJS crowd switched to React when version 2 came out.

The Good

Angular absolutely rocks for enterprise development. If you want to work for a big company, Angular is a fantastic choice. Angular is batteries included , meaning it comes with its own packages and solutions for the common things you want to do. For example, if you want to make an API call, there’s a feature for that. Internationalization, Global State Management and other Angular libraries/features are all built and maintained by the Angular team.

Angular is also the most opinionated of the Big 3. And because of its opinionated nature, most Angular projects look the same. When I say “opinionated” I mean that Angular has a particular method or way of doing what you want to accomplish. This means that once you learn it, you likely can work on any other Angular codebase with little effort.

The Bad

Being opinionated is a double-edged sword. Yes, it means that everyone is probably doing something the same way, but remember that Angular was written by Google Engineers. So the “Angular Way” does not necessarily mean the easy way.

TypeScript is mandatory in Angular, and the Angular team loves RxJS , so that’s also rolled into the framework. NGRX, Angular’s state management library, makes Redux look lightweight by comparison. All this adds up to a fairly steep learning curve for the novice developer.

Angular also wraps its components in HTML elements in such a way that CSS is scoped by default. There’s no way to turn it off either. Because of this, it can be incredibly difficult to override a component’s CSS when you need to.

The Ugly

Working with the module pattern in Angular is frustrating for beginners. Every component comes with an HTML, CSS, TypeScript, and Test file by default. You then have to register that component in a higher level module that tells Angular and TypeScript where it can find everything. The CLI has commands to generate a new component and auto-register it in a module because of how laborious it can be to do manually.

If you’re still learning front-end development and you’re new to frameworks, Angular can feel like building a rocket launcher to swat a fly. It’s honestly overkill for a small application, the type of which you need to build a lot of when learning.

To boot, the documentation is not great, and the community is not as prolific as React or Vue’s. This means it’s harder to find solutions for your problems via Google, and there’s not many tutorials out there for you to learn from.

That said, I recommend Todd Motto’s courses and the Angular Firebase fellow on YouTube if you’re hoping to learn Angular.

React

React, created by Facebook, launched after AngularJS and quickly became the most popular front-end framework.

If I had to put the React philosophy into words, I might say that React wants to be as unobstrusive as possible and make you feel like you’re just working with JavaScript. React also highly values immutabililty and one-way data flow.

The Good

Because of its popularity, there are an absolute ton of resources to learn React. You can hop onto Google or YouTube and easily find entire free courses for React. Any questions you may have about React have likely been answered and posted to Stack Overflow or some other forum.

React’s popularity also means there is plenty of 3rd party support. If you need any kind of pre-built solution for any aspect of a React project, someone has undoubtedly already built it and published it to NPM.

React’s API is also very small, meaning there’s just not that much to it. Writing React is a lot like writing JavaScript , particularly with the new hooks API which emphasizes a functional approach to writing components. This makes learning React beginner-friendly.

The popularity of React also makes it a great skill for finding a job. Plenty of companies use React.

The Bad

Because React is so small and un-opinionated, you’re going to have to bring in your own solutions for everything. This means you may be using lots of 3rd party libraries to accomplish things that might come standard in Angular or Vue. For example, if you want to make an API call, you’ll probably use Axios or JS’s fetch. If you want global state management, you’re going to use Redux or some other solution, where Angular has NGRX and Vue has Vuex.

Being a “bring your own everything” framework, one React project may look wildly different from another. So just because you have worked with React at one company for a length of time, you might change jobs to another React-based team and find yourself on a strange and foreign codebase that you have to learn.

The Ugly

Because it’s “just JavaScript”, React will let you write a bunch of JavaScript and logic in your template. This can make your code confusing and obtuse to other developers, and even yourself on a second pass. It can be incredibly difficult to write JSX in a way that’s readable.

React is un-opinionated, so you can absolutely turn it into a footgun and begin writing code that’s not performant and full of bugs. It’s incredibly easy to write bad React code.

Vue

Vue is the underdog, and everyone loves a good underdog. It’s written by Evan You, a former AngularJS team member. This the only one of the Big 3 not backed by a huge company in Silicon Valley.

The Good

Vue’s API is incredibly easy to learn. There’s plenty of stories of designers and developers that were turned-off or confused by Angular/React that gravitated towards Vue and loved it.

Vue provides just enough opinion to keep your code readable and sane without making you feel like you’re jumping through hoops to use it. It also provides some excellent built-in solutions for common framework problems. For instance, state management is greatly simplifed through Vuex, Vue’s version of Redux/NGRX.

There’s also a good amount of community support ; there’s plenty of third party libraries and packages for Vue. There’s also plenty of tutorials and info to be found on Google for Vue. And the official documentation is excellent.

If you’re worried about jobs with Vue, it’s a valid concern. You’re probably not as likely to find a Vue job in the states as an Angular or React job. However, the PHP community loves Vue. Laravel ships with Vue, and so if you find a company writing PHP, you’re likely to also find them using Vue. Vue is also huge in Asia likely because the documentation has been translated to Asian languages.

The Bad

Sharing logic between components with Vue is currently a bit of a mess. “Mixins” let you write logic that can be shared between components. They’re easy enough to use, but it can be devilish trying to figure out how mixins interact with a components logic. Mixins are terrible.

Vue also doesn’t really play well with TypeScript currently, which is a concern for big codebases that could benefit from it.

And as I noted above, you might have a harder time finding work in the West as a Vue dev than you would if you had learned React/Angular.

The …Uncertain

Vue isn’t ugly. It’s vuetiful.

That said, Version 3 of Vue is coming, and it’s bringing a different API with it that mimics React hooks.

Now, React hooks are excellent , but it remains to be seen how well Vue hooks (or the Composition API) will be embraced by the community. Regardless, Vue 3 will be backwards compatible, so hooks will be opt-in.

Having used React hooks, and having seen what Vue hooks are bringing to the table, I am excited to give them a try.

What about Ember, Svelte, Backbone, etc?

There’s a lot of front-end frameworks out there that aren’t the big 3. Someone probably published a new one while you were reading this article. Here’s a few I didn’t mention:

Ember is another highly-opinionated framework, and while it’s not as popular, there are teams out there using it.
Svelte is so new that nobody is using it yet. The creator is brilliant, and this may blow up, so who knows?
Nobody uses backbone. Sorry backbone.
Lit-HTML/Polymer is an ultra-lightweight framework (like 30 lines of JS small or something). I don’t know of anyone using it.

Choosing a Framework

Now that we’ve talked about the big 3, how do you pick one to learn?

You’ll probably spend most of your time using one framework. A codebase is unlikely to pull in multiple frameworks, and as a developer you likely only have time to specialize in one framework at a time.

The truth is: it doesn’t really matter which framework you know, as long as you know one.

All of these frameworks do the same thing. You write a template, variables and logic and they re-render the template based on those variables and logic.

They all use webpack and babel, they all have build-steps and CLIs, and you can get the same apps written using all of them. They’re all just HTML, CSS and JavaScript at the end of the day.

Your skills in one will transfer to another, because you’re really learning web development before you’re learning Angular or React development.

With that said, choose the framework that aligns with your goals and preferences.

If you want to move to Asia and work as a developer, Vue is a solid choice. Are you a Java developer or want to work at a big corporation? Angular might be best for you. Are you self-taught? Maybe React is the best choice simply for the amount of free tutorials that are available.

Parting Thoughts

Learning the conventions and basics of a front-end framework is the hard part. Once you learn one, it becomes trivial to switch to another. I learned React in a boot camp, got hired at a big company that used Angular, and then changed jobs to another that used Vue.

Note : If you’re curious about how web development evolved from Geocities to React, I did a brief talk on the history of web development and its current landscape.

Like this post? Please subscribe to my newsletter and check out my podcast!

How to make menus with CSS—no JavaScript or Bootstrap required!

Lee Warrick — Fri, 27 Sep 2019 16:00:00 +0000

Originally published at leewarrick.com/blog

I think a lot of new developers, myself included, are really excited about CSS until it comes time to start building more modern website features like menus.

I remember building my first site, feeling empowered by CSS to do my own styles, and feeling really proud of myself …until I needed a navigation menu.

As soon as I added a few links to my header, I began to run out of room on smaller screens. My site had to look good on mobile, so I was left with a choice:

Use Bootstrap menus and include a bunch of JavaScript/jQuery on the page, or
Use fewer links

I’ve made that choice many times since then, assuming that those were the only options when building navigation menus.

Creativity through Constraint

It wasn’t until I had to do a coding challenge for a developer job that I had to reckon with the real power of CSS.

I was presented a set of mock-ups of a modern website and told to create the website as close to the provided assets as possible. That’s a pretty typical request, except there was one catch: no JavaScript allowed.

I thought, “No way! There’s menus everywhere! How can I pull that off without JS?”

There were dropdown menus , drawers , and even a Bootstrap-esque mobile hamburger menu on one of the mocks.

Being the intrepid developer that I am, I saw this as a fun challenge. I hopped on Codepen and began searching for CSS-only versions of these common UI components.

After a little digging, I found examples for all of them! While there were some tricks involved that I would have never thought of, the tricks themselves were simple.

I took those new tricks and used them to finish the coding challenge. And yes, I got the job!

I had always been told that CSS was super powerful, but I don’t think I believed it until that point.

So without further adieu, here’s how I managed to recreate all of those menus with CSS alone.

The Classic Dropdown Menu

The first menu I want to talk about is the dropdown menu. You’ve probably seen this on any e-commerce site or anything with lots of categories and navigation. There’s a header up top with a list of categories, and when you mouse over one, a new menu appears with more related items.

Here’s an example:

(Note: To see live versions of these snippets, please go to the original post)

.dropdown__header * {
  padding: 0;
  margin: 0;
}
.dropdown__header {
  display: flex;
  align-items: center;
  background: lightblue;
}

.dropdown__header strong {
  margin-left: 5px;
  margin-right: auto;
  font-size: 1.6rem;
}

.dropdown__header .dropdown__categories,
.dropdown__header .dropdown__menu {
  display: flex;
  list-style: none;
  padding: 0;
  margin: 0;
}

.dropdown__header li {
  padding: 10px;
  position: relative;
}

.dropdown__header li:hover {
  background: #d2f2fc;
}

.dropdown__header .dropdown__category .dropdown__menu {
  display: none;
  position: absolute;
  background: #ebfaff;
  width: 200px;
  top: 50px;
  right: 0;
}

.dropdown__header .dropdown__category:hover .dropdown__menu {
  display: block;
}

<header class="dropdown__header">
  <strong>Logo</strong>
  <ul class="dropdown__categories">
    <li class="dropdown__category">
      <span>Cat 1</span>
      <ul class="dropdown__menu">
        <li>Cat 1 Thing</li>
        <li>Cat 1 Thing</li>
        <li>Cat 1 Thing</li>
        <li>Cat 1 Thing</li>
      </ul>
    </li>
    <li class="dropdown__category">
      <span>Cat 2</span>
      <ul class="dropdown__menu">
        <li>Cat 2 Thing</li>
        <li>Cat 2 Thing</li>
        <li>Cat 2 Thing</li>
        <li>Cat 2 Thing</li>
      </ul>
    </li>
  </ul>
</header>
<br>
<h3>CSS Only Dropdown!</h3>
<p>Hover over the Categories above</p>
<p>Pretty cool, right?</p>

What makes this work?

There’s three main concepts here that make this possible: Showing/Hiding with Psuedoselectors , absolute positioning , and mindful HTML structure.

Showing/Hiding with Pseudoselectors

I think most people are comfortable showing/hiding things with display: none and display: block. The real trick here is the selectors.

We’re targetting .dropdown __menu, but notice the nesting structure. We’re looking for a .dropdown__ menu class that’s within a .dropdown__category class. Then we can apply the :hover pseudoselector to the parent, which means we’re targetting the menu based on a hover over the parent.

.dropdown__header .dropdown__category .dropdown__menu {
  display: none;
}

.dropdown__header .dropdown__category:hover .dropdown__menu {
  display: block;
}

Mindful HTML Structure

Are you wondering why our menu stays open even when you move your mouse into the menu?

Going along with our nesting explanation above, note that our .dropdown __menu is contained within .dropdown__ category:

<li class="dropdown__category">
  <span>Cat 1</span>
  <ul class="dropdown__menu">
    <li>Cat 1 Thing</li>
    <li>Cat 1 Thing</li>
    <li>Cat 1 Thing</li>
    <li>Cat 1 Thing</li>
  </ul>
</li>

This means that although we’re no longer over the words “Cat 1”, the mouse is still within the .dropdown__category list item, keeping the :hover selector trigger active.

Note : The menu and category elements must be adjacent to each other so that your mouse stays within one or the other—you can’t position the menu off by itself somewhere and be able to mouse into it. More on that when we get to positioning.

Absolute Positioning

We position the hovered menu next to the category in the header using position: absolute;.

W3 Schools has a great breakdown of CSS positioning, but here’s the short version:

When you set positioning, items can be moved around with top, bottom, left, and right options.

Static : The default. The element behaves normally, and is unaffected by top/bottom/left/right.
Fixed : The element is positioned relative to the viewport. Eg: top: 0; would be the top of the viewer’s screen.
Relative : The element is positioned based on where it would be normally. So top: 0 wouldn’t move it at all, and top: 10px would push it down 10 pixels.
Sticky : This is a newer, trickier positioning. The element stays where it is, but when the user scrolls the page, before the element moves out of view, it will still stick to whatever top/bottom/left/right position is set.

And lastly, there’s Absolute positioning. This is the most complicated. The behavior depends on whether this element is within an element that has some kind of positioning set. If it has a positioned ancestor, it positions relative to that ancestor element. If not, it is positioned relative to the whole page.

In the case of our dropdown menus, we make the li tag that contains the menu relative. Then within it we can use position: absolute; to position the expanded menu around our category title.

.dropdown__header li {
  position: relative;
}

.dropdown__header .dropdown__category .dropdown__menu {
  position: absolute;
  top: 50px;
  right: 0;
}

Here we right-align the menu, and bump it down just far enough so that it’s at the bottom of “Cat 1” under our mouse.

Nested Dropdown Menus

Using the same techniques, we can create a more complicated dropdown menu:

.nested-dropdown__header * {
  padding: 0;
  margin: 0;
}
.nested-dropdown__header {
  display: flex;
  align-items: center;
  background: lightblue;
}

.nested-dropdown__header strong {
  margin-left: 5px;
  margin-right: auto;
  font-size: 1.6rem;
}

.nested-dropdown__header ul {
  display: flex;
  list-style: none;
  padding: 0;
  margin: 0;
}

.nested-dropdown__header li {
  padding: 10px;
  position: relative;
}

.nested-dropdown__header li:hover {
  background: #d2f2fc;
}

.nested-dropdown__header .nested-dropdown__menu,
.nested-dropdown__header .nested-dropdown__submenu {
  display: none;
  position: absolute;
  background: #ebfaff;
  width: 150px;
  top: 50px;
  right: 0;
}

.nested-dropdown__header .nested-dropdown__category:hover .nested-dropdown__menu,
.nested-dropdown__header .nested-dropdown__subcategory:hover .nested-dropdown__submenu {
  display: block;
}

.nested-dropdown__header .nested-dropdown__submenu {
  top: 0;
  right: 100%;
}

<header class="nested-dropdown__header">
  <strong>Logo</strong>
  <ul class="nested-dropdown__categories">
    <li class="nested-dropdown__category">
      <span>Cat 1</span>
      <ul class="nested-dropdown__menu">
        <li class="nested-dropdown__subcategory">
          <span>Sub Cat 1</span>
          <ul class="nested-dropdown__submenu">
            <li>Sub Cat 1 Thing</li>
            <li>Sub Cat 1 Thing</li>
            <li>Sub Cat 1 Thing</li>
            <li>Sub Cat 1 Thing</li>
          </ul>
        </li>
        <li class="nested-dropdown__subcategory">
          <span>Sub Cat 2</span>
          <ul class="nested-dropdown__submenu">
            <li>Sub Cat 2 Thing</li>
            <li>Sub Cat 2 Thing</li>
            <li>Sub Cat 2 Thing</li>
          </ul>
        </li>
        <li>Cat 1 Thing</li>
        <li>Cat 1 Thing</li>
      </ul>
    </li>
  </ul>
</header>
<br>
<h3>CSS Only NESTED Dropdown!</h3>
<p>Hover over 'Cat 1' above,</p>
<p>Then check out the Sub Categories!</p>

There’s only two caveats to this nested menu.

The first is that it doesn’t work well on mobile devices. This type of menu requires a lot of real-estate and hovers don’t translate to touchscreens very well. This isn’t a fault of CSS, though. Most sites will switch to a different style of menu on smaller devices, regardless of CSS vs JS.

The second is that if your user wants to jump from a menu to a nested menu, she may take the shortest path and unintentionally move her mouse cursor out of the current element. Deeply nested menus are a little perilous for the user, so use with caution.

Content Drawers

Creating drawers with CSS alone seemed impossible. Hover effects don’t work, because when you open a drawer, you expect it to stay open. However, I learned that it is possible with some very clever uses of HTML input elements and CSS selectors.

This example has quite a bit of CSS, but don’t fret, I promise to explain the important bits:

.drawer {
  position: relative;
  box-sizing: border-box;
  width: 300px;
}
.drawer input {
  width: 100%;
  height: 60px;
  position: absolute;
  opacity: 0;
  top: 0;
  left: 0;
  margin: 0;
  z-index: 3;
  cursor: pointer;
}
.drawer__name {
  display: flex;
  justify-content: space-between;
  border: 1px solid black;
  padding: 10px;
  background: lightblue;
}
.drawer__content {
  border: 1px solid black;
  box-sizing: border-box;
  width: 100%;
  margin: 0;
  height: 0;
  opacity: 0;
  pointer-events: none;
  list-style: none;
  transition: padding 0.2s;
}
.drawer input:checked ~ .drawer__content {
  height: 100%;
  opacity: 1;
  pointer-events: initial;
  padding: 10px 0;
}
.drawer__arrow {
  font-weight: 900;
  font-size: 1.2rem;
  transition: transform 0.2s;
}
.drawer input:checked ~ .drawer__name > .drawer__arrow {
  transform: rotateZ(90deg);
}
.drawer__content li {
  padding: 10px;
  cursor: pointer;
}
.drawer__content li:hover {
  color: rebeccapurple;
  text-decoration: underline;
}

<div class="drawer">
  <input type="checkbox">
  <span class="drawer__name">
    <span><strong>Bananas</strong></span>
    <span class="drawer__arrow">></span>
  </span>
  <ul class="drawer__content">
    <li>Bruised</li>
    <li>Green</li>
    <li>Perfect</li>
  </ul>
</div>
<div class="drawer">
  <input type="checkbox">
  <span class="drawer__name">
    <span><strong>Apples</strong></span>
    <span class="drawer__arrow">></span>
  </span>
  <ul class="drawer__content">
    <li>Mealy</li>
    <li>Crisp</li>
    <li>Green</li>
  </ul>
</div>
<div class="drawer">
  <input type="checkbox">
  <span class="drawer__name">
    <span><strong>Oranges</strong></span>
    <span class="drawer__arrow">></span>
  </span>
  <ul class="drawer__content">
    <li>Bitter</li>
    <li>Sour</li>
    <li>Sweet</li>
  </ul>
</div>

Ta-da! ✨ Pure CSS drawers!

It seems like a lot of code is required to make this happen, but there’s just a few key pieces to this puzzle that make it possible.

What makes this work?

The main trick here really did blow my mind. The secret is HTML checkbox elements.

Note: I would have never thought of this in a million years. When I saw an example of this on Codepen I experienced the same feelings I had when seeing an awesome magic trick explained; I felt amazement of the ingenuity involved, and also anger at being duped by such a simple trick that I should have been able to figure out for myself.

If we position the checkbox over the drawer and stretch it to the same size as the drawer, then target siblings on a :checked state, we can eliminate the need for JavaScript to trigger the open/close events. The CSS sibling selector is ~, meaning target any neighbor elements coming after this element.

It’s important to note that the checkbox must come first in the HTML. You can select sibling/neighbor elements that come after, but not before. We also use ~ and not + because + targets only the first adjacent sibling element, whereas ~ will give you any following sibling.

.ex2-drawer {
  position: relative;
  box-sizing: border-box;
  width: 300px;
}
.ex2-drawer input {
  width: 100%;
  height: 60px;
  outline: 2px solid red;
  position: absolute;
  /* opacity: 0; */
  top: 0;
  left: 0;
  margin: 0;
  z-index: 3;
  cursor: pointer;
}
.ex2-drawer__name {
  display: flex;
  justify-content: space-between;
  border: 1px solid black;
  padding: 10px;
  background: lightblue;
}
.ex2-drawer__content {
  border: 1px solid black;
  box-sizing: border-box;
  width: 100%;
  margin: 0;
  height: 0;
  opacity: 0;
  pointer-events: none;
  list-style: none;
  transition: padding 0.2s;
}
.ex2-drawer input:checked ~ .ex2-drawer__content {
  height: 100%;
  opacity: 1;
  pointer-events: initial;
  padding: 10px 0;
}
.ex2-drawer__arrow {
  font-weight: 900;
  font-size: 1.2rem;
  transition: transform 0.2s;
}
.ex2-drawer input:checked ~ .ex2-drawer__name > .ex2-drawer__arrow {
  transform: rotateZ(90deg);
}
.ex2-drawer__content li {
  padding: 10px;
  cursor: pointer;
}
.ex2-drawer__content li:hover {
  color: rebeccapurple;
  text-decoration: underline;
}

<div class="ex2-drawer">
  <input type="checkbox">
  <span class="ex2-drawer__name">
    <span><strong>Bananas</strong></span>
    <span class="ex2-drawer__arrow">></span>
  </span>
  <ul class="ex2-drawer__content">
    <li>Bruised</li>
    <li>Green</li>
    <li>Perfect</li>
  </ul>
</div>
<div class="ex2-drawer">
  <input type="checkbox">
  <span class="ex2-drawer__name">
    <span><strong>Apples</strong></span>
    <span class="ex2-drawer__arrow">></span>
  </span>
  <ul class="ex2-drawer__content">
    <li>Mealy</li>
    <li>Crisp</li>
    <li>Green</li>
  </ul>
</div>
<div class="ex2-drawer">
  <input type="checkbox">
  <span class="ex2-drawer__name">
    <span><strong>Oranges</strong></span>
    <span class="ex2-drawer__arrow">></span>
  </span>
  <ul class="ex2-drawer__content">
    <li>Bitter</li>
    <li>Sour</li>
    <li>Sweet</li>
  </ul>
</div>

The other important piece to this puzzle is the transition. Notice we didn’t use display here to show and hide the drawer. If you do, you won’t be able to use CSS transitions to animate. You can’t animate an element that’s hidden with display: none

Instead, we use a combo of height, padding, opacity, and pointer-events. (That seems like a lot, but hear me out).

Here’s the main code that makes this possible for reference:

.drawer {
  position: relative;
}
.drawer input {
  width: 100%;
  height: 60px;
  position: absolute;
  opacity: 0;
  top: 0;
  left: 0;
  z-index: 3;
  cursor: pointer;
}
.drawer__content {
  height: 0;
  opacity: 0;
  pointer-events: none;
  transition: padding 0.2s;
}
.drawer input:checked ~ .drawer__content {
  height: 100%;
  opacity: 1;
  pointer-events: initial;
  padding: 10px 0;
}

<div class="drawer">
  <input type="checkbox">
  <span class="drawer__name">
    <span><strong>Oranges</strong></span>
    <span class="drawer__arrow">></span>
  </span>
  <ul class="drawer__content">
    <li>Bitter</li>
    <li>Sour</li>
    <li>Sweet</li>
  </ul>
</div>

First we squash the .drawer__content with height: 0, and hide it with opacity: 0. However, because it’s still on the page, the user would be able to click the things within, even though the content isn’t visible. The solution is to disable mouse interaction with pointer-events: none. This allows us to animate the content while not letting the use see or interact with it.

Finally, we use padding as our animation. Animating the height causes some weird behavior, but animating the padding allows some for some subtle animation while keeping the drawer itself very responsive.

Note: It’s possible to make drawers with just HTML alone using the details element. You lose out on the ability to animate with CSS, though.

Here’s a quick example. None of the CSS is necessary for the drawer behavior:

details {
  background: rebeccapurple;
  color: #ddd;
  width: 300px;
  border-radius: 4px;
  margin-bottom: 5px;
}
summary {
  padding: 10px;
}
summary:focus {
  outline: none;
}
details ul {
  background: #ddd;
  margin: 0;
  color: black;
  padding: 10px;
  border-radius: 0 0 4px 4px;
}

details li {
  margin-left: 30px;
  margin-top: 10px;
}

<details open>
  <summary>Drawer 1</summary>
  <ul>
    <li>Thing 1</li>
    <li>Thing 2</li>
    <li>Thing 3</li>
    <li>Thing 4</li>
  </ul>
</details>
<details>
  <summary>Drawer 2</summary>
  <ul>
    <li>Thing 1</li>
    <li>Thing 2</li>
    <li>Thing 3</li>
    <li>Thing 4</li>
  </ul>
</details>

CSS Only Hamburger Menus

Now for the coup de grâce, CSS-only Hamburger menus!

What’s a hamburger menu? It gets its name from the three stacked dashes that indicate “hey this is a menu”. I guess someone was awful hungry for three lines to look like a hamburger, but I digress.

You may have some ideas on how to pull this off in your head after seeing the previous examples. Let’s take a look (Warning, incoming a ton of CSS):

.hamburger-menu__wrapper {
  min-height: 400px;
  position: relative;
  text-align: center;
}
.hamburger-menu {
  height: 100%;
  width: 300px;
  position: absolute;
  top: 0;
  left: 0;
}
.hamburger-menu__button {
  width: 40px;
  height: 40px;
  border: 2px solid #777;
  border-radius: 5px;
  display: flex;
  flex-direction: column;
  justify-content: center;
  position: relative;
  z-index: 3;
}

.hamburger-menu__button span {
  line-height: 8px;
  text-align: center;
  font-size: 1.6rem;
  font-weight: 400;
}

.hamburger-menu__button span:last-child {
  padding-bottom: 5px;
}
.hamburger-menu__wrapper {
  position: relative;
  height: 100%;
  overflow: hidden;
}
.hamburger-menu__wrapper input[type='checkbox'] {
  width: 40px;
  height: 40px;
  outline: 3px solid red;
  opacity: 0;
  position: absolute;
  top: 6px;
  left: 6px;
  z-index: 4;
  cursor: pointer;
}

.hamburger-menu__wrapper input:checked ~ .hamburger-menu__button {
  background: #d2f2fc;
}

.hamburger-menu__wrapper input:checked ~ .hamburger-menu__slider {
  transform: none;
}

.hamburger-menu__slider {
  position: absolute;
  top: 0;
  left: 0;
  width: 300px;
  height: 100%;
  background-color: lightblue;
  z-index: 2;
  transform: translateX(-310px);
  transition: transform 0.3s;
  text-align: left;
}

.hamburger-menu__item {
  padding: 10px 0 10px 10px;
}

.hamburger-menu__item:hover {
  background-color: #d2f2fc;
}

.hamburger-menu__item:first-of-type {
  margin-top: 60px;
}

<div class="hamburger-menu__wrapper">
  <div class="hamburger-menu">
    <div class="hamburger-menu__wrapper">
      <input type="checkbox" />
      <div class="hamburger-menu__button">
        <span>&mdash;</span>
        <span>&mdash;</span>
        <span>&mdash;</span>
      </div>
      <div class="hamburger-menu__slider">
        <div class="hamburger-menu__item">Thing 1</div>
        <div class="hamburger-menu__item">Thing 2</div>
        <div class="hamburger-menu__item">Thing 3</div>
        <div class="hamburger-menu__item">Thing 4</div>
      </div>
    </div>
  </div>
  <h2>Hamburger!!</h2>
  <p>Click the Button to toggle the menu</p>
</div>

Take that , bootstrap. 🤠

What makes it work?

A lot of the CSS above is for creating that silly hamburger style button. I literally stacked dashes and put a border around them, but you can use an icon if you like.

As for the menu, it uses absolute positioning , the input checkbox trick , as well as a new trick, which is using transform to slide the drawer in and out.

Here’s the code that makes the menu slide:

.hamburger-menu__wrapper {
  position: relative;
  height: 100%;
  overflow: hidden;
}

.hamburger-menu__wrapper input:checked ~ .hamburger-menu__slider {
  transform: none;
}

.hamburger-menu__slider {
  position: absolute;
  top: 0;
  left: 0;
  width: 300px;
  height: 100%;
  z-index: 2;
  transform: translateX(-310px);
  transition: transform 0.3s;
}

We style the menu to sit on top of the page, then add in transform: translateX(-310px) to pull the menu to the left so it’s no longer visible. When the input is checked, we remove that transform and the transition animates the drawer sliding into view.

There’s a ton of other neat things you can do with the transform property. We used it above on our drawers to turn our arrow to point downward when the drawer is open, for example.

We also use overflow: hidden on the wrapper to make sure our menu isn’t visible when the menu is closed.

Note: We also use z-index here to make sure things stack on top of each other. Absolute positioning breaks items out of normal HTML flow, so making sure the menu is on top is crucial. Even more critical, we apply a higher z-index to the checkbox to make sure the user can always open and close the menu. We applied z-index to our drawer checkboxes as well above.

But about JavaScript?

So yes, the point of this click-baity article title was that these things are possible without JavaScript. But does that make sense?

CSS is incredibly performant in general compared to using JavaScript. So it’s a good rule of thumb to use CSS instead of JS for most things.

That said, some of these examples could be improved with JavaScript. Our hamburger example could benefit from being able to click outside of the menu to close the drawer. For the drawers, you might want to only have one of the drawers open above at a time. And for the dropdown menus you might want to slow the closing of the menus when the mouse cursor moves outside of the menu.

If you’re already using an SPA like React, you may as well use a touch of JavaScript with your CSS to build the menus.

The point here is that for a simple site, you don’t need to reach for CSS frameworks or JS frameworks.

Parting Thoughts

CSS is powerful, and we could all use more excuses to practice and learn more and do more with it. HTML deserves a shout-out here as well. You can build a lot with HTML and CSS alone. Certainly more than I thought was possible when I started out.

JavaScript may rule the world, but CSS and HTML deserve your attention as a front-end developer as well.

Like this post? Please subscribe to my newsletter and check out my podcast!

Bridging the Gap between React's useState, useReducer, and Redux

Lee Warrick — Thu, 12 Sep 2019 16:00:00 +0000

Originally published at leewarrick.com/blog

Redux is one of those technologies that I consider a “personal Everest”. Everytime I look at it, I feel like there’s no end to the boilerplate and patterns to memorize.

At my first job and the first codebase I worked on, we had to use NGRX (Angular’s version of Redux). It was incredibly challenging; I spent hours reading docs and watching tutorials trying to understand NGRX. I even tried learning Redux in a desperate attempt to understand NGRX. I constantly complained to my boss about all the boilerplate, files, and patterns to memorize.

He told me, “If you were to use your own solution instead, you’d probably end up repeating those same patterns anyway”.

I finally concede. After managing React state with everything except Redux, I’ve found myself appreciating why it works the way it does and requires so much boilerplate. After learning React’s Context API, useReducer and a lot more about managing state, I finally appreciate Redux.

It’s not easy getting from A to B though. There’s a lot of ground to cover between learning useState and useReducer, and even more when you get into Redux and managing complicated states.

The ‘useState’ Hook

React’s useState is a pleasure to use. Give it an initial value, and it gives you a reference to the reactive value and a setter function to update that value.

Here’s the classic counter example with useState:

(Note: If you'd like to see live versions of these examples, please view the original post here.)

function Counter() {
    const [count, setCount] = React.useState(0)
    return (
        <div>
            <p>Count: {count}</p>
            <button onClick={() => setCount(count + 1)}>
                Increment
            </button>
        </div>
    )
}

Simple enough! There’s only two quirks:

The first is that you must provide a new state value to the setCount function (setCount(count++) and count++ won’t work). React is steeped in immutability, meaning you should always return a new value instead of changing the current value.

The other quirk is the returned array, but almost all hooks follow this pattern. It’s a small price to pay considering how easy it is to write functional hook components compared to class components.

So while useState seems simple enough, what happens when you need more than a single state value? What if you have a form with multiple fields?

Luckily, with hooks we can use useState multiple times:

function FormExample() {
  const [email, setEmail] = React.useState('')
  const [name, setName] = React.useState('')

  const columnStyle = {
    display: 'flex',
    flexDirection: 'column',
  }
  return (
    <form style={{ ...columnStyle, width: '300px' }}>
      <label style={columnStyle}>
        <span>Name:</span>
        <input
          onChange={e => setName(e.target.value)}
          value={name}
          type="text"
        />
      </label>
      <label style={columnStyle}>
        <span>Email:</span>
        <input
          onChange={e => setEmail(e.target.value)}
          value={email}
          type="text"
        />
      </label>
      <pre>{JSON.stringify({name, email}, null, 2)}</pre>
    </form>
  )
}
render(FormExample)

Great! But how much is too much with useState? Is there a sensible limit? Should we keep it to 5 or less?

And what if you need to manage more complicated data structures or perform side effects?

The ‘useReducer’ Hook

Now we’ve entered useReducer territory. The reducer in ‘useReducer’ comes from Redux, which in turn borrowed it from JavaScript’s Array.reduce().

So what does it mean to “reduce” something? Think of simmering balsamic vinegar so the vinegar evaporates and you’re left with a sweet, delicious glaze. That’s called a “balsamic reduction”. Think of reducers as taking arguments and cooking them down until they’re more pallatable.

In the context of React, here’s the typical pattern used with useReducer:

const reducer = function (currentState, action) {
  // Make a new state based on the current state and action
  // Note: There's usually a big switch statement here
  return newState
}
const [state, dispatch] = useReducer(reducer, initialValue)

// example usage:
dispatch({type: "THING_HAPPENED"})
// Or with an optional "payload":
dispatch({type: "THING_HAPPENED", payload: newData})

Before we dig into the classic reducer pattern, I want to boil useReducer down to its basic functionality. Simply put: useReducer is almost identical to useState, except useReducer lets you define exactly how to update it’s state value by passing it a function.

Let’s look at our counter example from before. Here we’ll implement our own useState with useReducer:

function Counter() {
    const [count, setCount] = React.useReducer((currentCount, newCount) => newCount, 0)
    return (
        <div>
            <p>Count: {count}</p>
            <button onClick={() => setCount(count + 1)}>
                Increment
            </button>
        </div>
    )
}

This is extra work with no benefit, though. Why pass a function to useReducer, only to pass another to onClick? Also, our counter logic is living in our JSX button element, which isn’t great.

Let’s cut out the extra function and move our logic out of the JSX:

function Counter() {
    const [count, increment] = React.useReducer(currentCount => currentCount + 1, 0)
    return (
        <div>
            <p>Count: {count}</p>
            <button onClick={increment}>
                Increment
            </button>
        </div>
    )
}

If you take nothing else away from this article, remember this:

The power of useReducer is that it allows us to define how we update our state value.

That said, before we dive further into reducers and patterns, I want to take a minute to define “state”.

The Problem with “State” in React

There are some major misconceptions about “state” in React. I think when Vue named it’s version of state “data”, they made it easier to think about Vue code.

What React defines as state is really just data that we would normally store in variables. However, React needs to, well, react to changes in that data. So under the hood, when you store things in state, React attaches methods and properties to that object so it knows when to trigger re-renders.

React “state” is just an object that React watches for updates.

So if React’s “state” isn’t really state, what is? The concept of “state” actually pre-dates React by decades. In computer science terms, the state of an application describes its current status and the previous events and user interactions that resulted in that status.

This type of state is notoriously difficult to deal with in programming. This is why every technical support agent defaults to “turn it off and on again” when you call for help. Your device entered a bad state somehow, and sometimes the easiest way to get out of a bad state is to reboot the system into a new state.

When we write React code, the problem is that we have a tendency to conflate the state of the program with the data React is watching for renders. For example, you might have data in your component that describes what the user typed in an input field, but also data that tells you if the form is valid or not. The combination of that current data and how it changed in response to the user is the actual state of your component.

We typically only worry about storing and updating data in our components, and avoid thinking about it’s actual state until we start to find bugs.

Reducers and Redux

The reducer pattern is an attempt to tame the flow of updating complex state. While not foolproof or easy, it can help us define and manages state changes in our application and components.

Let’s look at a simple version of the reducer pattern in the context of a form:

const reducer = function (currentState, action) {
    switch(action.type) {
        case 'NAME_CHANGED':
            return {...currentState, name: action.payload}
        case 'EMAIL_CHANGED':
            return {...currentState, email: action.payload}
        default:
            return state
    }
}
const [state, dispatch] = useReducer(reducer, {name: '', email:''})

// example usage:
dispatch({type: 'NAME_CHANGED'})
// or with a payload:
dispatch({type: 'NAME_CHANGED', payload: 'Suzy'})

Think about this as an event signaling system. When we call dispatch, we pass in an object that tells us what happened, and then our reducer takes that information and processes it to create a new state.

So why call it dispatch and action? Why the switch statement?

Dispatchers

I like to picture dispatch as a dispatcher of an old switchboard telephone system. The dispatcher packages the info with the main message (type) and any additional info (payload) and plugs it into the switchboard, our reducer (which coincidentally contains a switch).

Actions

They really should have called them “events” instead of “actions”. Actions describe events that have happened in your application. So when naming action types, it’s better to use the past tense ie "NAME_CHANGED", than the present, ie "CHANGE_NAME".

While this may seem like irrelevant semantics, it makes a big difference in understanding the redux pattern. It’s important to remember that your reducer is responding to events to decide on a new state. When you say "CHANGE_NAME", you’re implying that your reducer will change the name, as opposed to letting it decide if it will change it.

Note: While I would much rather refer to these as events, we’ll stick with “action” for sake of convention. Just remember to use the past tense in your action types.

Another Note: We also use SCREAMING_SNAKE_CASE for our action types. This is to denote that the strings are a constant value and to also implore you not to mutate or change them. (“Screaming Snake Case” is an excellent name for a metal band, btw.)

The Switch Statement

The choice of a switch statement over a long if/else if chain is mainly about readability.

You may also notice that there’s no break statements and lots of spread operators in our switch statement. We’re using return in lieu of break, which prevents the switch waterfall effect (more on that later). As for the spread operators, remember that React is built on immutability, so the creation of new objects is necessary. By spreading first and passing in our changes second, we can overwrite only the properties in state that we need to without affecting the rest:

const state = {
  name: "Robert",
  email: "SuperBobby74@aol.com"
}
const newState = {...state, name: "Bobby"}
console.log(newState)

Let’s apply the reducer pattern and useReducer to our form from earlier:

function FormExample() {
  function formReducer(state, action) {
    switch (action.type) {
      case 'NAME_CHANGED':
        return { ...state, name: action.payload }
      case 'EMAIL_CHANGED':
        return { ...state, email: action.payload }
      default:
        return state
    }
  }

  const [state, dispatch] = React.useReducer(formReducer, {
    name: '',
    email: '',
  })

  const columnStyle = {
    display: 'flex',
    flexDirection: 'column',
  }

  return (
    <form style={{ ...columnStyle, width: '300px' }}>
      <label style={columnStyle}>
        <span>Name:</span>
        <input
          onChange={e =>
            dispatch({ type: 'NAME_CHANGED', payload: e.target.value })
          }
          value={state.name}
          type="text"
        />
      </label>
      <label style={columnStyle}>
        <span>Email:</span>
        <input
          onChange={e =>
            dispatch({ type: 'EMAIL_CHANGED', payload: e.target.value })
          }
          value={state.email}
          type="text"
        />
      </label>
      <pre>{JSON.stringify(state, null, 2)}</pre>
    </form>
  )
}

render(FormExample)

This works great, but we can make some improvements.

First let’s pull our action types out and make them into an object like this:

const actions = {
  nameChanged: 'NAME_CHANGED',
  emailChanged: 'EMAIL_CHANGED',
}

This will save you from errors down the line. If you use actions.nameChanged in your switch and dispatch, your IDE may help prevent errors from typos in your action types. (You might see this same pattern with enums if the codebase is using TypeScript.)

We can also pull out our initial state into it’s own object, and move it outside of our component along with our reducer and our actions.

const actions = {
  nameChanged: 'NAME_CHANGED',
  emailChanged: 'EMAIL_CHANGED',
}

const initialState = {
  name: '',
  email: '',
}

function formReducer(state, action) {
  switch (action.type) {
    case actions.nameChanged:
      return { ...state, name: action.payload }
    case actions.emailChanged:
      return { ...state, email: action.payload }
    default:
      return state
  }
}

function FormExample() {
  const [state, dispatch] = React.useReducer(formReducer, initialState)

  const columnStyle = {
    display: 'flex',
    flexDirection: 'column',
  }
  return (
    <form style={{ ...columnStyle, width: '300px' }}>
      <label style={columnStyle}>
        <span>Name:</span>
        <input
          onChange={e =>
            dispatch({ type: actions.nameChanged, payload: e.target.value })
          }
          value={state.name}
          type="text"
        />
      </label>
      <label style={columnStyle}>
        <span>Email:</span>
        <input
          onChange={e =>
            dispatch({ type: actions.emailChanged, payload: e.target.value })
          }
          value={state.email}
          type="text"
        />
      </label>
      <pre>{JSON.stringify(state, null, 2)}</pre>
    </form>
  )
}
render(FormExample)

Handling Business Logic using Reducers

You might be wondering why exactly we’ve taken our useState example and made it so complicated. It seems like all we’ve done is add code to duplicate the same functionality we had before.

Reducers really start to shine when we add a submit button to the form. Forms are devilishly complex things to reason about (lots of state to manage), which is why there are so many form libraries out there. You need to account for validation, plus keep track of what fields are filled out, what happens when the form is submitted, etc.

If you were going to manage that logic with useState, you’d find yourself wrapping your submit in a lot of code, adding more useState hooks, and possibly wrapping your setter functions in validation functions that might update other state values. This would get messy quickly.

Unlike useState, useReducer provides a great infrastructure to handle all of the logic that surrounds validation and submission:

const actions = {
  nameChanged: 'NAME_CHANGED',
  emailChanged: 'EMAIL_CHANGED',
  formSubmitted: 'FORM_SUBMITTED',
}

const initialState = {
  name: '',
  email: '',
  nameError: null,
  emailError: null,
  formCompleted: false,
  formSubmitted: false,
}

function formReducer(state, action) {
  let error
  switch (action.type) {
    case actions.nameChanged:
      error = validate('name', action.payload)
      return { ...state, name: action.payload, nameError: error }
    case actions.emailChanged:
      error = validate('email', action.payload)
      return { ...state, email: action.payload, emailError: error }
    case actions.formSubmitted:
      // if the form has been successfully submitted,
      // stop here to prevent rage clicks and re-submissions
      if (state.formCompleted) return state
      let formValid = true
      // invalidate the form if values are missing or in error
      if (state.nameError || !state.name || state.emailError || !state.email) {
        formValid = false
      }
      // if the user has attempted to submit before, stop here
      if (state.formSubmitted) return { ...state, formCompleted: formValid }
      // if this is the first submit, we need to validate in case the user
      // clicked submit without typing anything
      let nameError = validate('name', state.name)
      let emailError = validate('email', state.email)
      return {
        ...state,
        nameError,
        emailError,
        formSubmitted: true,
        formCompleted: formValid,
      }
    default:
      return state
  }
}

// this helper function validates the name and email inputs
// if there's an error, it returns an error message describing the problem
// if there are no errors, it returns null
// it's outside our reducer to make things more readable and DRY
function validate(name, value) {
  if (typeof value === 'string') value = value.trim()
  switch (name) {
    case 'name':
      if (value.length === 0) {
        return 'Must enter name'
      } else if (value.split(' ').length < 2) {
        return 'Must enter first and last name'
      } else {
        return null
      }
      break
    case 'email':
      if (value.length === 0) {
        return 'Must enter email'
      } else if (
        !value.includes('@') ||
        !value.includes('.') ||
        value.split('.')[1].length < 2
      ) {
        return 'Must enter valid email'
      } else {
        return null
      }
      break
  }
}

function FormExample() {
  const [state, dispatch] = React.useReducer(formReducer, initialState)

  // extract our dispatch to a change handler to DRY the code up
  function handleChange(e) {
    dispatch({ type: actions[e.target.name + 'Changed'], payload: e.target.value })
  }

  // this is attached to the form, not the submit button so that
  // the user can click OR press 'enter' to submit
  // we don't need a payload, the input values are already in state
  function handleSubmit(e) {
    e.preventDefault()
    dispatch({ type: actions.formSubmitted })
  }

  const columnStyle = {
    display: 'flex',
    flexDirection: 'column',
  }
  // this adds a red outline to the input if the field isn't filled out correctly,
  // but only if the user has attempted to submit
  const inputStyle = hasError => {
    return {
      outline: hasError && state.formSubmitted ? '2px solid red' : 'none',
    }
  }
  return (
    <form style={{ ...columnStyle, width: '300px' }} onSubmit={handleSubmit}>
      <label style={columnStyle}>
        <span>Name:</span>
        <input
          style={inputStyle(state.nameError)}
          onChange={handleChange}
          name="name"
          value={state.name}
          type="text"
        />
        <span>{state.formSubmitted && state.nameError}</span>
      </label>
      <label style={columnStyle}>
        <span>email:</span>
        <input
          style={inputStyle(state.emailError)}
          onChange={handleChange}
          name="email"
          value={state.email}
          type="text"
        />
        <span>{state.formSubmitted && state.emailError}</span>
      </label>
      <p>{state.formCompleted && 'Form Submitted Successfully!'}</p>
      <button type="submit">Submit</button>
      <pre>{JSON.stringify(state, null, 2)}</pre>
    </form>
  )
}

render(FormExample)

Notice how our reducer function swelled with business logic. That’s OK! In fact, it’s a good rule of thumb to keep your reducers fat and event handlers skinny.

The functionality has changed as well. As our values change, the reducer handles validation and adds error messages to our state if necessary. If the form hasn’t been submitted, we can hold off on annoying the user with red boxes and error messages until they submit. If errors are present on submission, we can change the messages as they type to guide them to enter the correct information. Lastly, we can prevent rage clicks and repeat submissions with a formCompleted flag in our submission case.

This provides a great experience for the user, and a good organizational model for all these complex UI interactions.

Welcome to Redux

Believe it or not, We’ve now implemented all the major components of Redux. Redux itself is really just a helper library to assist in doing the same things we’ve done in this article.

In a typical Redux application, we lift the actions , reducers , and state into their own files in the project. To manage multiple state objects, we can group sets of actions/reducers/state into different stores that then become part of a global store with a root reducer. The root reducer’s job is to compose the state of each store into a single, global state object.

Then we import whatever store, dispatcher, and actions we need into our components to access state and signal events to the global store. Redux provides some utility to assist in composing this global state management system, but for the most part, you’re going to write all the actions, reducers, and states yourself, just like we did in this article.

So if you made it this far, you’re ready to use Redux! The real question is, should you?

Is Redux Dead ☠?

You can certainly do a lot without Redux nowadays with the Context API and the information learned here. Think of a Context as a Redux Store that you can position anywhere in your app. Any components that are wrapped in a Context Provider get access to the values you share from it. Context can be at the top level in your application, providing state to everything, or further down and only sharing its state with a handful of components.

Kent C Dodds has an excellent article on using Context for state management in React.

That said, Redux is not dead. There are plenty of codebases out there using it, and if you’re going to write React professionally, it’s not a bad idea to learn it.

Beyond Redux 😵

We’re going to get into some slightly advanced topics now, so buckle up.

The most astute tester might have noticed the bug in the last example. Scroll up and see if you can’t find the edge case we missed.

Give up?

You can edit the form after a successful submit!

How can we fix this? Your first instinct might be to start sprinkling the formSubmitted flag throughout our reducer to prevent further changes to the form, sort of how we did at the beginning of our submit case.

This would work, but it’s hard to read and reason about. I’d argue that the submission case is already a bit of a mess, and adding more logic to the other cases is only going to make things worse.

More importantly, how did we miss this in the first place? We learned all of this complicated JavaScript to prevent bugs, but we found some anyway!

Implicit vs Explicit States

In my tangent on state, I mentioned that we sometimes end up describing state with booleans or flags in our code. We’ve done that in our form with formCompleted and formSubmitted. The problem is that we’ve implicitly described the state of our form instead of explicitly.

That means that we’re relying on some combination of those booleans to describe the state of our form. For example, if the user hasn’t entered anything and hasn’t pressed submit, we might write:

if (!formSubmitted && !name && !email && !emailError && !nameError) {
  // behave as if user hasn't done anything yet
}

This is messy and hard to understand. When you come back to this code later you might even forget how it works and be hesitant to change it. It’s much better to explicitly describe the state of the form, and then ensure that the form can only exist in one of those states at any point in time.

We could describe our form states as:

Clean - User hasn’t entered anything or pressed submit
Dirty - User has started to enter info, but hasn’t successfully finished and submitted
Completed - Form has been filled out correctly and submitted

We also want to handle the transitions between these states as well as the possible actions that can happen in each state:

Clean - User hasn’t entered anything or pressed submit

Possible Transitions: Dirty

- Allowed Actions: editing and submitting, but submitting does not trigger errors, just a message

Dirty - User has started to enter info, but hasn’t successfully finished and submitted

Possible Transitions: Completed

- Allowed Actions: editing and submitting, but submitting triggers error messages

Completed - Form has been filled out correctly and submitted

Possible Transitions: None!
Allowed Actions: None!

Finite State Machines

The mental model we just created is a state machine or finite state machine (FSM). Finite meaning there’s a limited amount of states that the form can exist in, state describing the status of the form, and machine referring to the mechanism of how we transition to and from different states.

I’m not a state machine expert, so I highly recommend reading these articles by David Khourshid for a deeper dive into FSMs.

There are two options for applying this model to our code.

First, there’s library that’s tailor-made for FSMs called XState, written by the same David mentioned above. Here’s a great tutorial by Dave Geddes on using xstate in React if you’re interested.

The other option is to implement the logic ourselves in our reducer. This is a bit of a tall order, but if you read the FSM articles I linked, you might have seen an example of a FSM implemented with a nested switch statement. Let’s apply that to our form.

Advanced Switch Statements

Before we get to our final example, let’s briefly review JavaScript’s switch.

What we’re about to use is the “fall-through” or “waterfall” switch usage. What this means is we will deliberately not use break in every case so that we can match multiple cases.

Let’s see an example where we ignore Mom’s advice and skip breakfast, but still eat lunch and dinner:

const actionType = "LUNCH_ORDERED"

switch(actionType) {
  case "BREAKFAST_ORDERED":
    console.log("breakfast")
    // no break!
  case "LUNCH_ORDERED":
    console.log("lunch")
    // no break!
  case "DINNER_ORDERED":
    console.log("dinner")
    break
  default:
    console.log("fasting 😵")
}

Once you match a case, you match all cases until you break or return.

What about nested switches 😵?

function dailyLife(status, actionType) {
  switch(status) {
    case "work":
      switch(actionType) {
        case "WORK_REQUESTED":
          console.log("DOING WORK")
          break
      }
    //no break after "work"
    case "holiday":
      switch(actionType) {
        case "CAKE_EATEN":
          console.log("FEELING FAT")
          break
        case "NAP_REQUESTED":
          console.log("NAPPING")
          break
      }
  }
}
console.log("ooooh, who's birthday is it?")
dailyLife("work", "CAKE_EATEN") // feeling fat

console.log("Taking a break, afk")
dailyLife("work", "NAP_REQUESTED") // napping

console.log("Hey, I know it's Saturday, but can you get us that TPS report?")
dailyLife("holiday", "WORK_REQUESTED") // not happening, sorry boss

Here we can see that you can take a nap at work and on holiday, but you can’t work on a holiday. (At least you shouldn’t).

The idea is that if you have to share actions between states, put the state with unshared actions at the top. If we can only work at work, then the work status should be at the top. If you can eat cake at work and on holiday, then holidays/cake-eating should be below.

This is definitely an advanced technique, so be careful and test often when you’re writing a complicated switch that’s nesting and waterfalling through cases.

In the case of our form, we want the user to be able to edit the form regardless if it’s “clean” or “dirty”. To share the input change actions, we don’t break between the clean and dirty cases so that those actions are available to both. Also, you can submit in both states, but submit behaves differently in each.

Alright, here we go! Let’s take a look at our final form example with FSMs and useReducer:

const actions = {
  nameChanged: 'NAME_CHANGED',
  emailChanged: 'EMAIL_CHANGED',
  formSubmitted: 'FORM_SUBMITTED',
}

const initialState = {
  name: '',
  email: '',
  nameError: null,
  emailError: null,
  submitAttempted: false,
  submitMessage: '',
  status: 'clean',
}

function formReducer(state, action) {
  let error
  switch (state.status) {
    case 'dirty':
      switch (action.type) {
        case actions.formSubmitted:
          let formValid = true
          let nameError = validate('name', state.name)
          let emailError = validate('email', state.email)
          if (nameError || !state.name || emailError || !state.email) {
            formValid = false
          }
          return {
            ...state,
            nameError,
            emailError,
            submitAttempted: true,
            status: formValid ? 'completed' : 'dirty',
            submitMessage: formValid
              ? 'Form Submitted Successfully'
              : 'Form Has Errors',
          }
      }
    // no 'break' or 'return', case 'dirty' continues!
    case 'clean':
      switch (action.type) {
        case actions.nameChanged:
          error = validate('name', action.payload)
          return {
            ...state,
            name: action.payload,
            nameError: error,
            submitMessage: '',
            status: 'dirty',
          }
        case actions.emailChanged:
          error = validate('email', action.payload)
          return {
            ...state,
            email: action.payload,
            emailError: error,
            submitMessage: '',
            status: 'dirty',
          }
        case actions.formSubmitted:
          return {
            ...state,
            submitMessage: 'Please fill out the form',
          }
        default:
          return state
      }
    case 'completed':
    // no 'break' or 'return', case 'completed' continues!
    default:
      return state
  }
}

function validate(name, value) {
  if (typeof value === 'string') value = value.trim()
  switch (name) {
    case 'name':
      if (value.length === 0) {
        return 'Must enter name'
      } else if (value.split(' ').length < 2) {
        return 'Must enter first and last name'
      } else {
        return null
      }
      break
    case 'email':
      if (value.length === 0) {
        return 'Must enter email'
      } else if (
        !value.includes('@') ||
        !value.includes('.') ||
        value.split('.')[1].length < 2
      ) {
        return 'Must enter valid email'
      } else {
        return null
      }
      break
  }
}

function FormExample() {
  const [state, dispatch] = React.useReducer(formReducer, initialState)

  function handleChange({ target: { name, value } }) {
    dispatch({ type: actions[name + 'Changed'], payload: value })
  }

  function handleSubmit(e) {
    e.preventDefault()
    dispatch({ type: actions.formSubmitted })
  }

  const columnStyle = {
    display: 'flex',
    flexDirection: 'column',
  }
  const inputStyle = hasError => {
    return {
      outline: hasError && state.submitAttempted ? '2px solid red' : 'none',
    }
  }
  return (
    <form style={{ ...columnStyle, width: '300px' }} onSubmit={handleSubmit}>
      <label style={columnStyle}>
        <span>Name:</span>
        <input
          style={inputStyle(state.nameError)}
          onChange={handleChange}
          name="name"
          value={state.name}
          type="text"
        />
        <span>{state.submitAttempted && state.nameError}</span>
      </label>
      <label style={columnStyle}>
        <span>email:</span>
        <input
          style={inputStyle(state.emailError)}
          onChange={handleChange}
          name="email"
          value={state.email}
          type="text"
        />
        <span>{state.submitAttempted && state.emailError}</span>
      </label>
      <p>{state.submitMessage}</p>
      <button type="submit">Submit</button>
      <pre>{JSON.stringify(state, null, 2)}</pre>
    </form>
  )
}

render(FormExample)

Now our form is bug free!

We’ve explicitly modeled and accounted for all the possible states it can exist in, and defined the possible actions in those states.

Note: You may notice we still have a submitAttempted boolean in the code. This is OK because it is only used to show or hide the error messages in our form. Most importantly, We don’t check submitAttempted to determine what state we’re in.

Parting Thoughts

This post is full of advanced concepts and I hope that you were able to learn some of them even if you didn’t make it all the way to the end. Don’t fret if you didn’t understand every concept and example. Start at the easy stuff, and start applying and practicing those concepts first in your own code before moving on to the more difficult concepts. That’s how I learned them.

Thanks for reading this huge article, cheers!

Like this post? Please subscribe to my newsletter and listen to my podcast!

React's useEffect and useRef Explained for Mortals

Lee Warrick — Fri, 06 Sep 2019 16:00:00 +0000

Originally published at leewarrick.com/blog

If the React docs leave you in the dust, or Dan Abramov’s blog makes you feel like you’re reading a scroll handed down from Mt Olympus written in ancient Greek, you’re not alone.

Sometimes the pantheon of React Gods have a hard time translating their wisdom into language the rest of us can understand. It usually goes like this: You hit a snag with React, google your issue, and read a blog or Stack Overflow post with some advice that makes you feel more lost than when you started.

I’ve certainly fallen victim to this many, many times. Particularly with useEffect. Before we dive into this particular hook, let me say that I love writing React with hooks and wouldn’t want to go back to classes. That said, useEffect is a big pain point.

(Note: If you want to see the code snippets below in action, please visit the original post.)

What is an “effect” anyway?

To really wrap your head around useEffect, let’s back up a little bit and talk about programming and JavaScript.

The effects that useEffect is named for are what we affectionately refer to as “side effects”.

So what is a side effect? It’s a bit of code that reaches out and …does something else. It’s an abstract concept, so let’s talk in examples.

Here’s a function with NO side effects:

function add(a, b) {
    return a + b
}

The function add does nothing except take an input and return an output. It doesn’t reach outside itself to mess with anything else!

Let’s introduce a side effect.

const resultDiv = document.getElementById('add-example')
function add(a, b) {
    const result = a + b
    resultDiv.textContent = `The Result is ${result}`
    return a + b
}
add(3, 4)

<div id="add-example"></div>

Now our function reaches outside of itself to update the DOM (short for Document Object Model) and show the result. This additional behavior is a side effect.

Side Effects in React

So what about React? It’s a library that pretty much only updates the DOM. A view library, if you will. So what would you call a side effect in React?

Anything outside of updating the page. If you’re not using React to update state or render HTML, that’s a side effect. It’s any non-React thing.

This means anytime you call an API, use setInterval/setTimeout, add a keyboard listener, or really anytime you mess with the window object you’re introducing side effects.

Hooks are amazing and let you write really readable, reusable code… except when you’re dealing with side effects. And that’s unfortunate, because when you think about it, most of the fun, interesting stuff we do as web developers revolves around side effects.

Let’s take a step back from hooks for a minute and look at how we would handle side effects in class-based components.

Class-based Components and Side Effects

In class-based components, we would use lifecycle methods to perform side effects. For example, on componentDidMount we would call APIs to get data for render.

“Why not call the API in the constructor function?”, you might ask. Well, because React says stuff we use for render goes in “state” and we can’t mess with state until our component is loaded onto the page. If we try to update state before the component is loaded, we get errors.

Here’s a typical class-based component hitting the PokeAPI:

class Pokemon extends React.Component {
    constructor() {
        super()
        this.state = null
    }
    componentDidMount() {
        fetch('https://pokeapi.co/api/v2/pokemon/gengar/')
        .then(res => res.json())
        .then(res => {
            this.setState(res)
        })
    }
    render() {
        const pokemon = this.state
        const style = {textTransform: 'capitalize'}
        return (
            <div>
            { pokemon
                ? <>
                    <img src={pokemon.sprites.front_default}
                        alt={'Image of ' + pokemon.name}/>
                    <p style={style}>Name: {pokemon.name}</p>
                    <p style={style}>
                        Type: {pokemon.types.map(x => x.type.name).join(', ')}
                    </p>
                </>
                : 'Loading...'
            }
            </div>
        )
    }
}

This works well, except when it doesn’t. What happens when we want to hit the API again to grab a different pokemon? What if this component is attached to a certain route in our app and the route changes, but the component doesn’t unmount/remount. What if the user goes to a different page and the component unmounts before the API call finishes?

The answer is to add more lifecycle methods like componentDidUpdate and componentWillUnmount to perform more API calls and prevent weird unmounting errors. So we add those lifecycle methods in to handle all our edge cases. And by the time we’re done, we realize most of our component consists of lifecycle code.

Then Came React Hooks

The React team realized that the class API is a little unwieldy and hard to reason about. People were making lifecycle flowcharts trying to understand the inner workings of React …it was a mess.

So at ReactConf in October of 2018, after Sophie Alpert outlined just how bad classes are to use, Dan Ambramov got on stage and introduced hooks (You can watch the video here).

Hooks introduced statefulness in functional components, as well as a new way to handle side effects. Hooks made React code more reusable with less code—a huge win!

Except for one small quirk. Each render, the whole component/function is re-run.

Let’s look at an example of a hooks-based component:

function RerenderExample() {
    const [bool, setBool] = React.useState(false)
    const randomNum = Math.random()
    return (
        <div>
            <p>This number will be different each time you click the button:</p>
            <p>{randomNum}</p>
            <button onClick={() => setBool(!bool)}>Trigger a render</button>
        </div>
    )
}

We’re not even using bool in our rendered JSX, yet the whole function runs everytime the state changes. Every render, everything inside the component re-runs: function definitions, variable creation/assignment, etc.

If you’re thinking “what if I have to do something computationally expensive inside a component? This can’t be performant…”, that’s an astute observation. An expensive operation in a functional component wouldn’t be performant. In fact useCallback and useMemo exist as escape hatches for this very problem. Kent C Dodds has a challenging read on those here, but to summarize, according to Kent you shouldn’t worry about the re-renders until you see performance impacts.

( Note : If you’re unfamiliar with hooks, bookmark that article and come back to it when you’re ready. Don’t worry about memoization until you have to.)

Hooks like useState employ some magic under-the-hood to avoid the re-render problem. That’s great, and it seems simple enough using useState, but what about when you need to do things outside of setting state?

Enter useEffect. Gone are those pesky lifecycle methods, hooray! However this hook comes with its own weirdness. First let’s check out the syntax:

//accepts two arguments: a function, and dependency array
useEffect(() => {
    // do stuff
    return () => {} //function to undo our stuff from above when component unmounts
}, []) //dependency array of things to watch for changes on

So you pass useEffect a callback function to run that contains your side effects, and then an array of things to watch. If the watched things change, useEffect will re-run our callback function. If you need to clean up your side effect on unmount, return a function that contains that code.

Let’s look at our pokemon example with hooks and useEffect:

function Pokemon() {
    const [pokemon, setPokemon] = React.useState(null)
    React.useEffect(() => {
        fetch('https://pokeapi.co/api/v2/pokemon/gengar/')
        .then(res => res.json())
        .then(res => {
            setPokemon(res)
        })
    }, []) // empty array means nothing to watch, so run once and no more
    const style = {textTransform: 'capitalize'}
    return (
        <div>
        { pokemon
            ? <>
                <img src={pokemon.sprites.front_default}
                    alt={'Image of ' + pokemon.name}/>
                <p style={style}>Name: {pokemon.name}</p>
                <p style={style}>
                    Type: {pokemon.types.map(x => x.type.name).join(', ')}
                </p>
            </>
            : 'Loading...'
        }
        </div>
    )
}

If you’re staring at that empty dependency array, you’ve noticed the first useEffect quirk. By passing an empty array, we’re saying “only ever do this once”. The React pantheon tells us that on rare occasions that’s ok, but most of the time you want something in there. The reason is that usually you want to synchronize with something in your code, not just perform the effect once. For example, what if our pokemon component depended on a route parameter or props, anything that said, “go get a new pokemon” without mounting/unmounting?

Let’s say our component depended on a prop pokemonToGet that was an argument telling it which pokemon to get from the API. Let’s also add a tiny form for testing purposes:

function Pokemon({pokemonToGet}) {
    const [pokemon, setPokemon] = React.useState(null)
    React.useEffect(() => {
        fetch(`https://pokeapi.co/api/v2/pokemon/${pokemonToGet}/`)
        .then(res => res.json())
        .then(res => {
            setPokemon(res)
        })
    }, [pokemonToGet]) // get a new pokemon with the pokemonToGet prop changes
    const style = {textTransform: 'capitalize'}
    return (
        <div>
        { pokemon
            ? <>
                <img src={pokemon.sprites.front_default}
                    alt={'Image of ' + pokemon.name}/>
                <p style={style}>Name: {pokemon.name}</p>
                <p style={style}>
                    Type: {pokemon.types.map(x => x.type.name).join(', ')}
                </p>
            </>
            : 'Loading...'
        }
        </div>
    )
}
function PokemonForm() {
    const [inputValue, setInputValue] = React.useState("rowlet")
    const [pokemonToGet, setPokemonToGet] = React.useState("gengar")
    function getPokemon() {
        setPokemonToGet(inputValue.trim().toLowerCase())
        setInputValue("")
    }
    return (
        <div>
            <input onChange={(e) => setInputValue(e.target.value)}
                value={inputValue} type="text"/>
            <button onClick={getPokemon}>
                Get Pokemon
            </button>
            <Pokemon pokemonToGet={pokemonToGet} />
        </div>
    )
}
render(<PokemonForm />)

Great, now our component fetches a new pokemon based on our prop changes. With classes we would’ve had to play with componentDidUpdate and such to achieve a similar effect.

Ryan Florence has a great tweet to summarize useEffect’s usage:

The question is not “when does this effect run” the question is “with which state does this effect synchronize with”

useEffect(fn) // all state

useEffect(fn, []) // no state

useEffect(fn, [these, states])

That “all state” case he mentions where you pass in nothing for dependencies is a weird one. I’ve personally never found a use for it. We know that the whole component runs with each render, so I’m wondering if there’s some weird edge case that requires you to use useEffect(fn) without any dependency array. In any case, most of the time you’re going to be working with this: useEffect(fn, [these, states]).

UseEffect and Previous State: Where things fall apart

The mental model so far for useEffect seems straight-forward enough: synchronize it with certain state changes of your choosing. The problem is when you need to reference that state in an effect, not just know if it changed.

You don’t get access to current state inside of useEffect.

We didn’t see this in our API call example because we’re simply overwriting the previous state.

Let’s look at a simple example:

function Timer() {
    const [count, setCount] = React.useState(0)

    React.useEffect(() => {
        const intervalId = setInterval(() => {
            setCount(count + 1)
        }, 1000)
        return () => clearInterval(intervalId)
    }, [])

    return (
        <div>The count is: {count}</div>
    )
}

Seems like we did all the right things (even cleaning up our side effect on unmount) but our counter isn’t incrementing. Is it a this issue? Do we not have access to the window object that setInterval belongs to?

No and no. If you added a console.log into that interval, you’d see it tick every second.

I’ll prove it to you:

function Timer() {
    const [count, setCount] = React.useState(0)
    const [randomNum, setRandomNum] = React.useState(0)

    React.useEffect(() => {
        const intervalId = setInterval(() => {
            setCount(count + 1)
            setRandomNum(Math.random())
        }, 1000)
        return () => clearInterval(intervalId)
    }, [])

    return (
        <div>
            <p>The count is: {count}</p>
            <p>RandomNum is {randomNum}</p>
        </div>
    )
}

Notice we get a new random number every second. Our interval code is fine.

We’re able to set new state, but are unable to access current state.

This is a ” stale closure ”. I won’t get into closures, but just know that because of the implementation of React/hooks, the count variable is always going to be 0 in our interval function. It’s an old reference.

Update 9/7/19 : It turns out, there’s a solution for simple examples like above, as pointed out by John Tucker (thanks John!). Much like setState in class-based components, useState can also accept a callback function that receives the previous state as an argument. The React Docs also make note of this.

Here’s an example of the quick fix:

function Timer() {
    const [count, setCount] = React.useState(0)

    React.useEffect(() => {
        const intervalId = setInterval(() => {
            //let's pass a function instead
            //the argument is the current state
            setCount(count => count + 1)
        }, 1000)
        return () => clearInterval(intervalId)
    }, [])

    return (
        <div>The count is: {count}</div>
    )
}

This still doesn’t solve all of our problems, though. If you need to access to the latest state inside useEffect, but not update it, you would have to start wrapping your useEffect code in setState callbacks, and then returning the unchanged state at the end. This could quickly become an absolute mess, particularly if you’re working with multiple state values.

Another possible solution could be to work only with useReducer, as that receives previous state, but filling your reducer with side effects also seems very messy, and I wouldn’t suggest anyone stop using useState entirely.

In any case, I’ve fallen into the stale closure trap many, many times when writing hooks. I didn’t even know it had a name until I read it in this talk by Rich Harris, the man behind Svelte.

Apparently, I’m not the only one tripping over them in hooks, either:

React even mentions it in their docs:

“Any function inside a component, including event handlers and effects, “sees” the props and state from the render it was created in.”

I read this prior and it made little sense to me before really digging into the issue. I imagine it could be a bit of a black eye for React, so perhaps they don’t wish to call it out too loudly.

Dan Abramov, however, describes the problem better in his blog and even provides a solution:

“Effects always “see” props and state from the render they were defined in. That helps prevent bugs but in some cases can be annoying. For those cases, you can explicitly maintain some value in a mutable ref.”

This was helpful, because it provided a solution in the form of useRef (Thanks Dan!), but it left me in the dark as to how it would help avoid the issue (mostly because I didn’t understand useRef).

What is a “ref”, and how do you use one?

So traditionally, refs were meant to let you directly access an html element. For instance, let’s say you needed to focus an input field. You have to bail out of React and use regular JavaScript to call .focus(). Hooks actually make this fairly simple:

function InputField() {
    const inputRef = React.useRef()
    return (
        <div>
            <input type="text" ref={inputRef} />
            <button onClick={() => inputRef.current.focus()}>
                Click to Focus the input
            </button>
        </div>
    )
}

Great! Refs are an easy escape hatch to access native DOM APIs when we need to.

…but how does that help us fix our stale closure counter example?

Using Refs to avoid Stale Closures

The React docs compare refs to “instance variables”. I didn’t know what that meant (thanks Wikipedia), so I didn’t find that helpful.

I managed to wrap my head around refs by thinking about them this way:

Refs exist outside of the re-render cycle.

Think of refs as a variable you’re setting to the side. When your component re-runs it happily skips over that ref until you call it somewhere with .current.

Let’s see the fix for our timer example:

function Timer() {
    const [count, setCount] = React.useState(0)
    const countRef = React.useRef(0)

    React.useEffect(() => {
        const intervalId = setInterval(() => {
            countRef.current = countRef.current + 1
            setCount(countRef.current)
        }, 1000)
        return () => clearInterval(intervalId)
    }, [])

    return (
        <div>The count is: {count}</div>
    )
}

If we wanted to stop the timer at say, 10, we could easily do so using the ref:

function Timer() {
    const [count, setCount] = React.useState(0)
    const countRef = React.useRef(0)

    React.useEffect(() => {
        const intervalId = setInterval(() => {
            if (countRef.current === 10)
                return clearInterval(intervalId)
            countRef.current = countRef.current + 1
            setCount(countRef.current)
        }, 1000)
        return () => clearInterval(intervalId)
    }, [])

    return (
        <div>The count is: {count}</div>
    )
}

Here’s the alternative using the setState callback approach, for sake of comparison:

function Timer() {
    const [count, setCount] = React.useState(0)

    React.useEffect(() => {
        const intervalId = setInterval(() => {
            setCount(count => {
                if (count === 10) {
                    clearInterval(intervalId)
                    return count
                }
                else return count + 1
            })
        }, 1000)
        return () => clearInterval(intervalId)
    }, [])

    return (
        <div>The count is: {count}</div>
    )
}

I could see this quickly approaching callback hell, so I would caution against using the callback approach if you’re doing something more complex.

State Versus Refs

Is it possible to ditch state entirely and just use refs?

You might be inclined to think you could use refs instead of state for your component and just sidestep all this weird behavior.

You can’t. Refs aren’t reactive. When you change a ref, it doesn’t cause a re-render. (Remember, they exist outside of the re-render cycle).

This won’t work:

function Timer() {
    const count = React.useRef(0)

    React.useEffect(() => {
        const intervalId = setInterval(() => {
            count.current = count.current + 1
            //console.log('Ref example count: ' + count.current)
        }, 1000)
        return () => clearInterval(intervalId)
    }, [])

    return (
        <div>The count is: {count.current}</div>
    )
}

That component is actually counting upwards internally, but it’s not causing the HTML to update. You need useState for that. (Go ahead and uncomment the console.log if you don’t believe me)

Here’s an example to demonstrate refs vs state:

function Counter() {
  const [count, setCount] = React.useState(0)
  const countRef = React.useRef(0)

  return (
    <div>
      <p>State Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>
        Increment State Count
      </button>
      <p>Ref Count: {countRef.current}</p>
      <button onClick={() => countRef.current = countRef.current + 1}>
        Increment Ref Count
      </button>
    </div>
  )
}

render(<Counter/>)

You won’t see the ref count change until you trigger a re-render by setting state.

Parting Thoughts

I love hooks and functional components in React, but the quirks I’ve outlined have given me pause. I don’t like being required to know so much about the inner-workings of React to use it. I think it presents a roadblock for those learning React, and I hope in the future the React team comes up with some better ways to handle these quirks.

Have you hit the "stale closure" snag? Let me know in the comments!

Like this post? Please subscribe to my newsletter and check out my podcast!

An intro to testing with Gil Tayar

Lee Warrick — Sun, 01 Sep 2019 19:16:49 +0000

This week on Tech JR we talked to Gil Tayar about testing in JavaScript.

We covered the types of testing and some testing philosophies before diving into how to test Node and Node microservices.

Testing Node Microservices with Gil Tayar

Tech Jr

Your browser does not support the audio element.

1x initializing... ×

If you'd like to see how Gil tests React, definitely check out his talk from ReactNext on YouTube: "An Ode to Node: Testing Frontend the Backend Way"

What's your experience with testing? Do you write tests at work? What are your favorite testing tools? Let us know in the comments below!

Originally posted on Tech JR

If you enjoy this episode, please subscribe!

Staying Sane while Organizing CSS

Lee Warrick — Sun, 01 Sep 2019 17:00:00 +0000

In my time as a front-end developer, I’ve seen and heard a lot of gripes about CSS.

I often see people reach for a CSS framework like Bootstrap, Materialize, Bulma, Tailwind, etc. to avoid writing CSS. While CSS frameworks can be great accelerators, they often require solid CSS skills to wield them effectively. That is to say, if you’re not very good at CSS, you’re probably not going to be that great using a CSS framework either.

Framework or not, when hitting a snag people tend to throw more and more lines of CSS at the problem until they get a working solution. In essence, they’re following the “can’t tie a knot? Tie a lot!” method of development.

Unfortunately a massive, improper knot is unreliable and weakens the rope.

So don’t be the “see what sticks” developer. I’m going to show you how you can add a little organization to your stylesheets that will get you up and running quickly without pulling your hair out.

Preparing for Success: Reset vs Normalize

HTML elements come with their own default styling. Unfortunately, much of it is flat-out ugly (Looking at you, form input elements).

To make things worse, browsers still have not reached 100% parity on that default styling. This means certain elements appear differently on different browsers.

You may even end up overriding that default styling over and over again in your stylesheet to achieve the look or positioning you want. Don’t fall into this trap. Address the default styles once.

That said, there are two powerful, pre-built solutions for taming default styles: Reset and Normalize.

Note : Don’t forget to add these before all other styles—remember the cascade!

CSS Reset

CSS Reset is essentially the nuclear option. It wipes out all the styles from all of the elements, more or less making them differ in name only. <h1>’s look like <p> tags, for example.

This is a valid solution if you need to start from scratch, but you typically don’t need to obliterate the default styles completely. If you do, you’re going to have to go back in and make that <h1> large and bold again with more CSS.

Normalize CSS

Normalize CSS is the more elegant solution than a reset. Its goal is to even out the kinks between browsers and address the most common issues with default styles, while leaving the rest intact.

Most CSS frameworks have a normalize built into them already, so you won’t need to add this in if you’re using Bootstrap, Materialize, etc.

The Quick and Easy Option

There’s a third option here worth mentioning. If you’re trying to get things done quickly and not using a framework, you can eliminate most of the funk with something like this:

* {
    margin: 0;
    padding: 0;
    /* box-sizing: border-box */
    /* border: 1px solid black */
}

This ends up stripping out all the micro-adjustments you typically have to come in and do later if you roll with the default padding and margin on elements. (The * is a wildcard selector that selects all elements)

You can optionally toss in the box-sizing bit to make sure that your widths/heights are not additive. This means if you say an element is 500px, it will be exactly that regardless of padding, margin, or border that you add in later. I don’t typically find myself reaching for this, but it can help when you’re doing pixel-perfect layouts.

Note : The last bit is a little 🔥 hot tip 🔥 for debugging CSS layouts. If you’re wondering how big or what shape an element is, adding a border can quickly show you how something is being rendered. This adds a border to all elements, showing you how everything is laid out on the page.

Writing Good Markup and ‘Going with the Flow’

CSS Zen Garden showed us the awesome power of CSS to style HTML regardless of how it is written.

What’s that quote about power and responsibility…? 🤔🕷

HTML has a certain flow to it. It’s read and rendered top-to-bottom, certain elements are block or inline, etc. The greater your knowledge of this default behavior, the better you can use it to your advantage, and the less CSS you’ll have to write to change it.

Yes, CSS can do amazing things to change the default behavior of markup. However, if you write your HTML with your end goal in mind, you’ll end up weaponizing CSS less often to make your markup behave appropriately.

Mastering Layouts with Flexbox and Utility Classes

Layouts and positioning of elements is probably the biggest source of strife when learning CSS. You want an element to be in a particular spot, so you write ten lines of CSS that almost positions it perfectly. Then you write ten more lines of CSS, but now it’s vertically off-center, etc.

There’s a few tools and tricks that can dramatically reduce the amount of time you spend attempting to place elements where you want them to go.

Floats

Before we talk about flexbox, let’s talk briefly about floats. If you’re using floats for layouts, please stop. Flexbox is highly compatible with older browsers, and it’s way easier to use.

Floats are great for wrapping text around an element, but are awful for layouts. They break the flow of HTML and require a clearfix hack to restore that flow for the rest of the elements that come after.

(Note: To see these examples in action, go to the original post)

Here’s a quick example:

<div id="float-example">
    <img src="https://picsum.photos/200" id="floatImage"/>
    <!-- Let's say we want this blob of text to wrap around our example image -->
    Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris ultricies sem id ante ullamcorper, a commodo eros molestie. Phasellus leo justo, malesuada scelerisque ullamcorper et, finibus ut metus. Integer egestas tellus leo, et consectetur tortor bibendum at. Sed non imperdiet risus. Sed at metus mauris. Donec ullamcorper, nunc sit amet ullamcorper mattis, diam sapien viverra nisi, sit amet pretium ligula mi in est. Nulla finibus imperdiet fringilla. Proin fringilla augue et turpis placerat, sit amet commodo enim dictum. Vivamus viverra mollis augue, in fermentum odio placerat eu. Aenean porta tellus quis urna tristique sagittis.
</div>

#floatImage {
    /* 'float' makes the text wrap around the image, try 'right' */
    float: left;
    /* the rest of this is to better illustrate the wrapping effect */
    shape-outside: circle();
    border-radius: 100px;
    margin: 5px;
}

#float-example::after {
    /* Another gripe about floats is having to use a clearfix! */
    content: "";
    display: table;
    clear: both;
}

If you erase some of the lorem text, and remove that clearfix hack, you’ll see how floats destroy a page’s flow.

Floats are a good tool if you use them correctly. However for layouts, you probably don’t want to use a float.

Flexbox

Flexbox is a powerful and simple tool to use for creating layouts and positioning elements. If you’ve never heard of it, Wes Bos has a great free series on it called _What the Flexbox?_. If you’re already familiar with flexbox, there’s a great visual cheat sheet you can use as well.

Conceptually, flexbox is all about creating containers. So you create a flex container with display: flex and then every direct child element will be aligned a certain way based on that parent container element.

It’s also a one-dimensional system of laying things out. Each container runs in one direction, either horizontally with flex-direction: row (the default) or vertically with flex-direction: column. Children within can then be centered/aligned very easily from there.

Why not Grid?

You can absolutely use Grid! CSS Grid is very similar to flexbox, just way more powerful. If Flexbox is a one-dimensional layout system, Grid is two-dimensional. You can pretty much set a CSS grid container to do anything your heart desires. (If you want a great free CSS Grid course… yup, Wes Bos has you covered there as well.)

Why use flexbox then? Honestly, I like it because it’s incredibly simple and straightforward. It does one thing and does it very well. Plus you can absolutely nest flex containers and compose them into whatever you need.

Components vs Utility classes

So when it comes to organization of CSS, there’s two camps: components, and utility classes.

Components

Components could be thought of like how bootstrap organizes their building blocks. A “jumbotron” or “navbar”, etc. might be represented by one class applied to an element, or possibly with a handful of subclasses used on elements within. The approach here is to use fewer class names in your HTML, scope/name them smartly, and generally style larger chunks of markup with a handful of classes.

A popular convention for naming such classes is BEM. BEM stands for “Block, Element, Modifier”, and it’s essentially a system of -- and __ inside your class names to increase the reusability and composability of your CSS.

Here’s a BEM in 5-minutes video to get you up to speed.

The catch is that this reduces resuability of your CSS. You can’t very well apply jumbotron styles to a navbar. BEM and smart naming can only take you so far.

Utility Classes

The opposite approach to componentized classes is utility classes. These are small classes that typically do one thing only. For example, mx-auto would apply margin-left: auto; margin-right: auto.

Bootstrap and Materialize have a set of utility classes, and Tailwind CSS is made up entirely of utility classes if you’d like more examples.

The power of utility classes is in rapid development. You almost never have to leave your HTML file when prototyping if you have enough utility classes defined.

The con here is that your HTML elements can quickly become bloated with CSS classes, and a combination of ten utility classes used to define a component results in a lot of repeated code.

Finding Balance

In my experience, a combination of both methods is the sane choice. Having a handful of global utility classes in combination with larger presentational classes for blocks of markup makes the most sense. This has the added benefit of making your markup a little more readable as well, because your component class names like card are listed beside your layout class names like row or column. So card row would tell you this card has a row of children elements.

Let’s look at some examples. Let’s build a standard layout, starting with a header and some navigation links.

This little bit of CSS is going to let us do a lot of heavy lifting. We’re going to start with a global color palette using CSS variables, then define our layout classes.

(Note: To see these examples in action, go to the original post)

:root {
    --ex-black: #1C0F13;
    --ex-green-dark: #6E7E85;
    --ex-green-light: #B7CECE;
    --ex-purple-dark: #BBBAC6;
    --ex-purple-light: #E2E2E2
}
/* These are going to be our main, bread and butter layout classes */
.row, .column {
    display: flex;
    flex-wrap: wrap;
}
.column {
    flex-direction: column;
}
.container {
    max-width: 500px;
    margin: auto
}
/* These additional classes will be used to space/align content */
.center-x {
    justify-content: center;
}
.center-y {
    align-items: center
}
.split {
    justify-content: space-between
}

Next we’ll add some styles for our navigation header with BEM.

/* add some styles to prettify */
.header {
    background-color: var(--ex-black);
    padding: 10px 5px;
}
.header__logo {
    color: var(--ex-purple-light);
    margin: 0;
}
.header__link {
    color: var(--ex-purple-dark);
    margin: 0 5px;
}

<header class="header">
    <div class="container row split center-y">
        <h1 class="header__logo">Logo</h1>
        <div class="row">
            <p class="header__link">Link</p>
            <p class="header__link">Link</p>
            <p class="header__link">Link</p>
        </div>
    </div>
</header>

That made short work of the header!

Let’s go a little further and build out a jumbotron/call to action and a little text thrown in:

.jumbotron__container {
    background-color: var(--ex-green-light);
}
.jumbotron {
    height: 300px;
    color: var(--ex-black);
}
.jumbotron__button {
    background-color: var(--ex-purple-light);
    border: 2px solid var(--ex-green-dark);
    border-radius: 4px;
    color: var(--ex-green-dark);
    transition: background-color 200ms, color 200ms
}
.jumbotron__button:hover {
    color: var(--ex-black);
    background-color: var(--ex-purple-dark);
    border: 2px solid var(--ex-black);
}
.ex-heading {
    text-align: center;
    margin: 24px 0;
    color: var(--ex-green-dark);
}
.ex-text {
    color: var(--ex-black);
    max-width: 200px;
}

<header class="header">
    <div class="container row split center-y">
        <h1 class="header__logo">Logo</h1>
        <div class="row">
            <p class="header__link">Link</p>
            <p class="header__link">Link</p>
            <p class="header__link">Link</p>
        </div>
    </div>
</header>
<main>
    <div class="jumbotron__container">
        <div class="jumbotron column center-x center-y">
            <h2>This is a moving message</h2>
            <p>And this is why you should click the button below</p>
            <button class="jumbotron__button">Call to Action</button>
        </div>
    </div>
    <h3 class="ex-heading">Read Stuff</h3>
    <section class="container row split">
        <p class="ex-text">
            Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris ultricies sem id ante ullamcorper, a commodo eros molestie. Phasellus leo justo, malesuada scelerisque ullamcorper et, finibus ut metus. Integer egestas tellus leo, et consectetur tortor bibendum at.
        </p>
        <p class="ex-text">
            Sed non imperdiet risus. Sed at metus mauris. Donec ullamcorper, nunc sit amet ullamcorper mattis, diam sapien viverra nisi, sit amet pretium ligula mi in est. Nulla finibus imperdiet fringilla.
        </p>
    </section>
</main>

Cool right?

Doing something like this as a CSS beginner used to take me hours and many more lines of CSS!

Note : If you check this layout on mobile, you’ll see it is responsive without any additional work. The flex-wrap property makes our children elements wrap to a new line if there’s not enough space. Flexbox in general works very well with creating responsive layouts.

Parting Thoughts

Hopefully by now you see the power of applying some organizational principles to your CSS. With a little practice, you can get some amazing things done with only a few lines of code.

Questions? Comments? Post below! Tell me how you organize your CSS!

Originally published at leewarrick.com/blog

Like this post? Please subscribe to my newsletter

Finding the Courage to Code

Lee Warrick — Sun, 25 Aug 2019 16:00:00 +0000

Once I overheard someone describe a kid they met that knew he wanted to be a podiatrist 👣👨‍⚕️ at age 6. This story is not about that person.

My life has been rife with indecision. In fact, a good friend once described me as the “male Barbie of careers”. Sure, I eventually found my way to coding, but it was a long, winding road.

The Early Years

As a kid, I always thought I would like to do …stuff with computers. I wasn’t quite sure what that stuff was, but I wanted to do it.

What I did know, was that programming seemed dense and mystical. Actually I didn’t even really know what programming was. I basically thought it was like the movie “Hackers”.

In elementary and middle school, my only exposure to computers was through playing Math Blaster, Oregon Trail, and a Super Mario typing game. In high school I took an introductory computer course (basically a Microsoft A+ certification class), and a web design class where we learned a little HTML.

Writing math formula scripts on my graphing calculator was as close as I got to really coding something in grade school. Those miniature programs were silly, but also exciting.

Clueless in College

The smart kids in my high school seemed to be all applying and getting accepted to college. So I blindly followed suit.

I applied and was accepted to the University of Florida as a chemical engineering student. I stuck with it for about a month before catching wind of what those folks actually do, then changed majors to Computer Science.

I was going for it folks, I was going to pursue my dream.

The first day of my intro to computer science class went like this:

A lanky, disheveled man strode into the auditorium fifteen minutes late. He stood at the podium and addressed the class:

“A little news in the life of Pete. I just found out my former best friend has been sleeping with my ex-wife.”

Pete then proceeded to teach us binary, hexidecimal, and other very low-level computer science concepts. For homework, we had to solve small, boring puzzles with Java like Given a number N, print a triangle of #‘s to the screen that is N wide and N tall.

I stubbornly worked through those assignments. I coded in notepad.exe and ran my code with the windows command line. I didn’t know what an IDE was and I didn’t understand how this was going to add up to writing actual software.

In class, there was one student up front that nodded along with everything the instructor said, answered every question, and giggled at every Java idiosyncracy that arose during the lecture.

I hated that student. I hated him because I wished I was him. How did he know so much in an intro class? I felt so incredibly lost by comparison.

I spent two semesters suffering through Java. Our final project of the second semester was hangman. I finished it while having absolutely no idea what I was doing.

I thought, “If I’ve spent a year learning to code, and this is how far I’ve come, how will I ever make anything useful?”

Succombing to Self-doubt

I saw myself as hopelessly outmatched. I convinced myself that coding was for child prodigies and geniuses only seen on TV. I did all the mental gymnastics required to convince myself that I was the problem.

I switched majors again and got my degree in Japanese language.（こんいちは皆さん！）But I doubted my language skills too. In my mind, I couldn’t possibly be good enough to work as a translator or interpreter.

So I went back to school to be a firefighter. I reasoned that my father did it for 30 years, had a great retirement plan, and seemed to enjoy the job, so why shouldn’t I do the same?

I somehow made it through fire school. Then I became an EMT and a Paramedic. I got hired. Soon I was keeping the roads hot with my lights and sirens blaring, kicking down doors and saving lives!

Except it wasn’t like that at all. Most 911 calls are not emergencies—most are monotonous and mundane. And of the calls I ran, the 10% that were true emergencies still haunt me from time to time.

And the pay was awful. I was exposed to a lot of chemicals, disease, and stress for about $14 an hour.

I convinced myself I needed to do better. I went back to school and became a registered nurse, and worked in intensive care and the emergency room.

My situation had improved: now I was being exposed to a lot of chemicals, disease, and stress for about $25 an hour.

Changing Course

At some point I found myself looking back on my life and wondering how I ended up so far from my dreams. As a kid, I wanted to make things. I wanted to code.

Sometimes I’d find myself sitting at the nurse’s station absent-mindedly clicking through Codecademy or freeCodeCamp tutorials.

Then I discovered coding bootcamps.

There’s a lot of noise out there about bootcamps. You’d be forgiven for thinking that they’re the ponzi scheme of our time after doing a little research on the internet.

The risk didn’t matter though. I saw it as an opportunity to escape. I signed up.

Going to code bootcamp turned out to be a transformative experience for a few reasons:

I was surrounded by career changers. When we introduced ourselves on the first day I found myself in the company of marketing executives, fast-food workers, database administrators, school teachers, and even computer science undergrads.
Everyone struggled to get their code to run. Sure, some were better than others, but absolutely everyone had difficulties in class and doing the homework.
We built fun things. Not once did I have to print a triangle with for loops. We built personal websites, games, toy apps, and more. I could feel myself making progress. I actually enjoyed learning.
We were encouraged to find our own answers. From day one we were told to “google it.” It was our mantra. We weren’t expected to know everything, but we had to be able to search for the answers.

So there I was with like-minded, indecisive people that were struggling to learn, having fun building things, and just as clueless as I was. It was so radically different from that college class I had taken fifteen years ago. It was invigorating.

Getting Hired as a Developer

I worked very, very hard in class. I knew that this was my chance to change course. I took it very seriously.

I also knew going in that getting a job was not guaranteed or even likely.

Most employers don’t like junior developers, and they like bootcamp grads even less. They view juniors as a liability not worth the money they’ll save on a lower salary.

I needed to stand out in a positive way. I needed to convince someone to give me a chance despite my inexperience.

The bootcamp did not bless me with a great resume nor a great portfolio, and as a brand new developer living an hour outside of town, I had no network.

So I went to meetups. I got on a developer slack channel in town and asked a boatload of stupid questions. I worked tirelessly on my resume and portfolio, soliciting feedback from anyone willing to give it. And all the while I machine-gunned my resume to every developer job on indeed that I was remotely qualified for.

Eventually I saw a job-listing on slack. I messaged the poster, sent my resume and portfolio, and setup an interview.

In that interview, I was calm and collected. I made them laugh and answered their questions. My past careers had taught me to maintain my composure and stay calm. One of my interviewers even remarked how it would be great to have a nurse on the team.

I got the job. I quit nursing and became a fulltime developer.

Words of Wisdom

Here’s what I wish someone had told me many years ago at the start of this journey:

Stop doubting yourself. With enough patience and effort, you can learn anything.
Do the things that make you happy and make you feel fulfilled. Don’t do something because it’s “a good job” or “a steady paycheck”.
Find comfort in the fact that you’re not alone. We’re all making this up as we go along. Even our mentors struggle to get their code to work. Nobody has all the answers.
Don’t ever forget where you came from. Remember the things that confused, infuriated, and discouraged you. It will help you remember how far you’ve come, keep you humble, and remind you to be kind to those following in your footsteps.

Learn from my mistakes, then pay it forward.

Originally published at leewarrick.com/blog.

Please subscribe for updates.