Forem: Dave Ceddia

Implementing a Mockup: CSS Layout Step by Step

Dave Ceddia — Tue, 30 Apr 2019 00:23:35 +0000

Creating layouts is one of the hardest parts of front end development for a lot of people.

You can spend hours trying random CSS properties, copying and pasting from Stack Overflow, and hoping to stumble upon that magical combination that will produce the layout you want.

If your usual strategy is to approach layout in an item-by-item way – put A over here, and now that A is in its place, I want to put B over there… well, that’s a guaranteed route to frustration. CSS doesn’t work like Sketch or Photoshop.

In this post I want to show you a way to approach layouts wholistically, as a cohesive problem to be solved.

We’ll go through a small example, start to finish, and I’ll explain all the CSS along the way – so even if you don’t know or remember how position and display work, or you can’t tell your align-items from your justify-content, you’ll get something out of this.

We’re also gonna use plain HTML and CSS here, so you don’t need to know anything about React/Vue/Angular/CSS-in-JS or even JavaScript.

Sound good? Let’s get into it.

A Small Layout Example

For this post we’re going to replicate something that looks like a tweet:

Whether you’re starting from a sketch like this, or a pixel-perfect mockup, it’s a good idea to have something to go off of.

CSS layout goes more smoothly when you’re not trying to cobble it together in the browser while simultaneously designing it in your head. You absolutely can get to that level! But if you’re reading this, I’ll assume you’re not there yet :)

First Step: Identify the Pieces

Before we write any HTML or CSS, we’ll highlight the individual parts of this layout:

When laying things out with CSS I find it helpful to think in terms of rows and columns. So you either have elements going down the page one-after-another, or a series of elements arranged left-to-right. Thinking in terms of rows and columns maps nicely to two layout techniques CSS gives us: Flexbox and Grid.

This layout doesn’t really look like rows and columns, though. There’s an image flush-left, and a jumble of stuff to the right of it.

Second Step: Draw Boxes Around Stuff

Let’s draw some boxes around the elements and see if we can get this into some semblance of rows and columns. We’ll put boxes around the parts that are flowing in the same direction.

Every element you place on the page with HTML is basically a rectangle. Sure, sometimes they have rounded corners, or they’re circles, or fancy SVG shapes… Often you don’t actually see a bunch of rectangles on the page. But you can always draw a bounding box around a thing. So it helps to imagine everything as a rectangle.

I mention the rectangles because if you have a set of items you need to align – like the first row with the Name/@handle/Time or the last row with the icons – you can always wrap them in a box for styling purposes, to make it easier to arrange them.

If we were to stop here, and code this up in HTML, we’d have something like this:

<article>
  <img
    src="http://www.gravatar.com/avatar"
    alt="Name"
  />
  <div>
    <span>@handle</span>
    <span>Name</span>
    <span>3h ago</span>
  </div>
  <p>
    Some insightful message.
  </p>
  <ul>
    <li><button>Reply</button></li>
    <li><button>Retweet</button></li>
    <li><button>Like</button></li>
    <li><button>...</button></li>
  </ul>
</article>

And you’d see something like this (here’s a sandbox):

…which is not even close to what we want. But! All the content is there. And some of the clusters of elements are even flowing in the right direction.

You could make the case that this layout gets the point across even without further styling, and that’s a great benchmark to aim for with HTML.

A Note on Semantic HTML

You might wonder why I picked those particular elements – the article, the p, etc. Why not make everything a div?

Why this…

<article>
  <img ... />
  <div>
    <span/>
    <span/>
    <span/>
  </div>
  <p> ... </p>
  <ul>
    <li>
      <button> ... </button>
    </li>
  </ul>
</article>

Instead of this?

<div>
  <img ... />
  <div>
    <div/>
    <div/>
    <div/>
  </div>
  <div> ... </div>
  <div>
    <button> ... </button>
  </div>
</div>

Well, the names of HTML elements actually have meanings, and it’s a good idea to use elements that semantically match the thing they represent.

It’s good for humans, like the programmer trying to decipher the code, and the viewer using an assistive technology like a screenreader. It’s also good for search engines, which are trying to decipher what the page means, so they can ~~show relevant ads and make a ton of money~~ help searchers find what they’re looking for.

The article tag represents an article-like thing, and a tweet is sorta like an article if you squint hard enough.

A p tag represents a paragraph, and the text of the tweet is sorta like a paragraph.

The ul tag represents an unordered list of things (as opposed to an ordered, or numbered, list), and in this case it holds a list of actions you can take.

The semantic meanings of HTML elements and which specific ones to use in specific situations is… not straightforward. But for the most part, a semantic element – even a very loosely-related one – will be better than a div, which just denotes “a division”.

Default Styling of Elements

What makes it look the way it does? Why are some elements on their own line, while others appear side-by-side?

This happens because of the default styling applied to the elements, and it brings us to our first bit of CSS knowledge: inline versus block elements.

Inline elements will squeeze next to each other on one line (and wrap if they have to, just like words in a sentence). A span, a button, and an img are all inline elements, according to default browser styling.

Block elements , on the other hand, like to stand alone. In terms of console output, you could think of a block element as having a \n newline before and after it. It’s like a console.log("\ndiv\n"). The article, div, li, ul, and p tags are block-level elements.

In the example above, notice how the avatar image is on its own line, even though the img tag is inline? That’s because the div below it is a block element.

Then, notice how the @handle, Name, and time are all on one line? That’s because they’re inside span tags, which are inline.

Those three are on a separate line from the “insightful message” because (a) they’re within a div, which will have a newline after it and (b) the p tag is also a block element, so it would’ve forced a newline too. (you don’t see 2 newlines though, for the same reason that HTML combines adjacent whitespace).

If you look closely, you’ll notice the space above and below the “insightful message” is bigger than the space between the avatar image and the handle/name/time below it. That space is controlled by the default styles too: p tags have a top and bottom margin.

You’ll also notice the bullets on the list of buttons, and that the bulleted list is indented. That’s all default styling too. We’re gonna turn it off in a bit.

Step Three: More Boxes

We want to arrange the avatar image on the left, and everything else to the right. Given what you know about inline and block elements, you might think you could just wrap the right-side stuff in an inline element like a span.

That won’t work, though. An inline element won’t prevent block elements inside it from breaking the line.

To arrange elements the way we want, we’re going to need something more powerful, like Flexbox or Grid layout. We’ll solve this one with flexbox.

How Flexbox Works

CSS “flex” layouts can arrange items into rows or columns. It’s a one-dimensional layout system. In order to have alternating rows and columns (like in our tweet design), we’ll need to add a few wrapper elements to flip the direction.

You can turn on flex layout for a container by setting the property display: flex;. The container itself will then be a block-level element (so it’ll get its own line), and the elements inside the container will become “flex items” – meaning they’re no longer inline or block; they’re controlled by the flex container.

In our case, we’ll have a few flex containers nested within each other, so that we can arrange some of them into rows and some into columns.

We’ll arrange the outer wrapper (the green box) into columns, then the blue box will be arranged into rows, and each of the red boxes will be columns again.

Why Flexbox Instead of Grid?

I’m using flexbox here instead of CSS Grid for a few reasons. I think flexbox is a bit easier to learn, and it’s also better-suited to small layouts than grid. Flexbox is especially good for layouts where things are mostly rows or mostly columns.

The other important thing to know is that even though Grid is newer than Flexbox, Grid does not replace Flexbox. They are each well-suited to different kinds of layouts, and it’s good to know both. In some layouts you might even use both – say, Grid to lay out a page and Flexbox for a contact form within the page.

I know, I know… in other corners of web dev, the “new hotness” always replaces the “old and busted”, but CSS doesn’t work that way. Flexbox and Grid happily coexist.

There’s usually more than one way to solve a problem with CSS!

Step Four: Apply Flexbox

Alright, now that we have a plan, let’s apply some styles. I’ve gone and wrapped the left-side stuff in a div, and given a class to most of the elements to make them easier to target with CSS.

<article class="tweet">
  <img
    class="avatar"
    src="http://www.gravatar.com/avatar"
    alt="Name"
  />
  <div class="content">
    <div class="author-meta">
      <span class="handle">@handle</span>
      <span class="name">Name</span>
      <span class="time">3h ago</span>
    </div>
    <p>
      Some insightful message.
    </p>
    <ul class="actions">
      <li><button>Reply</button></li>
      <li><button>Retweet</button></li>
      <li><button>Like</button></li>
      <li><button>...</button></li>
    </ul>
  </div>
</article>

(here’s the CodeSandbox)

Visually, it still looks the same.

That’s because divs, aside from being block elements (and introducing a newline if there wasn’t one) are otherwise invisible. When you need something to contain other elements, and there’s not a more semantic option, a div makes a great wrapper.

Here’s our first bit of CSS, which we’ll put inside a style tag inside the head tag of the document:

.tweet {
  display: flex;
}

It’s a step in the right direction! We’re using a class selector to target all elements with the class of tweet. We only have one such element, but if we had ten of ‘em, they would all be flex containers now.

The leading . in CSS means it’s a class selector. Why a .? I dunno. You’ll just have to commit that one to memory.

Now the content is to the right of the avatar… but the image is skewed pretty weird.

This is because, by default, a flex container will:

arrange its items side-by-side
make them only as wide as the content they contain, and
set all of their heights based on the tallest one.

We can control their vertical alignment with the align-items property.

.tweet {
  display: flex;
  align-items: flex-start;
}

The default for align-items was stretch, but setting it to flex-start shoves them up to the top, and it lets the items govern their own heights.

Direction: Row or Column?

By the way, the default direction for flex containers is flex-direction: row;. Yes, it’s called “row,” even though, depending on how you look at it, you might be inclined to call that 2 columns. Think of it instead as a row of items side-by-side and it’ll make more sense.

Kind of like this picture of a vase. Or two faces. Whatever.

Wikipedia

Content Should Take More Space

The flex items only take as much horizontal space as they need, but we’d like the content area to take up as much width as possible.

To do that, we’ll apply the flex: 1; property to the content div. (Since it has a class, we’ll use another class selector!)

.content {
  flex: 1;
}

And we’ll also add some space between the avatar and the content, by giving the avatar a little margin:

.avatar {
  margin-right: 10px;
}

Looking a little better!

margin vs padding

So… why margin instead of padding? And why put it on the right of the avatar, instead of the left of the content?

As a general rule: put margins on the right and bottom of things, instead of left and top.

At least for layouts like English, things flow from right to left and top to bottom, so in a sense, each element “depends on” the one to its left, or the one above it.

With CSS, every item’s position is affected by those “before” it. (at least until you start messing with position: absolute and friends)

Separation of Concerns

Technically, in this case, where & how we place the gap between the avatar and the content doesn’t really matter. Space is space, and there are no borders to interfere (padding goes inside borders; margin goes outside).

But it does matter in terms of maintainability, and in terms of how you think about the elements from the standpoint of organization.

I try to think of each element as a standalone thing, with the same intention as having a JavaScript function that only does One Thing: if each thing only has one job to do, it’s easier to write the code, and easier to debug when it goes wrong.

If we had added the margin to the left of the content, and then one day decided to delete the avatar, we’d be left with that space. We’d have to hunt down what was causing the extra space (the surrounding tweet? the content?) and get rid of it.

Or, if the content had the left margin and we decided to replace the content with some other thing, we’d need to remember to add the space back to whatever took its place.

Ok, that was a lot to say about 10 pixels. Put the margins on the right and bottom. Let’s get back to styling.

Removing the List Style

The ul unordered list and the li list items inside it come stock with a bunch of space on the left, and bullets. We don’t want any of that.

The unordered list has a lot of left padding that we can turn off. Let’s also make it a flex container, so that the buttons will be arranged side-by-side (in a row, remember… with flex-direction: row by default)

The list items have a list-style-type of disc which shows the bullets, and we can turn that off by setting list-style: none; (list-style is a shorthand property that sets multiple other properties, including list-style-type, at the same time).

.actions {
  display: flex;
  padding: 0;
}
.actions li {
  list-style: none;
}

The .actions selector is just another class selector. Nothing special there.

The .actions li selector, though, says “all li elements anywhere inside elements with class actions”. It’s a combination of a class selector (.actions) and an element selector (li).

Separating selectors with a space like that narrows down the selection with each one. CSS actually reads selectors in reverse order. It goes “find all the lis on the page” and then “ok now only target the lis that are somewhere inside an element with class of actions”. You can think about it either way and you’ll get the same result. (more on the reasoning behind it at StackOverflow)

Spread out the Buttons

We can spread out the buttons a few ways.

One would be by setting the justification of the flex items. You’re probably familiar with these buttons at the top of pretty much every rich text editor ever:

They justify the content in your document to the left, center, right, or, uhh, “justified” a.k.a. full-width.

In flexbox you can do the this with the justify-content attribute. When you’re in flex-direction: row (the default, and the one we’ve been using so far), justify-content will move the items left and right. It defaults to flex-start (so everything is squeezed to the left). If we set justify-content: space-between on the .actions it will distribute them evenly across the entire width, like this:

That’s not quite what we want, though. It’d be better if they didn’t span the whole width. So take that out.

Instead, we can apply a right margin to each of the list items to space them out. Let’s also give the whole tweet a border so we can tell what’s going on. 1px solid #ccc will make it 1 pixel wide, a solid line (as opposed to dotted or dashed) and gray.

.tweet {
  display: flex;
  align-items: flex-start;
  border: 1px solid #ccc;
}
.actions li {
  list-style: none;
  margin-right: 30px;
}

Now it looks like this:

The buttons look better, but the border highlights the fact that everything is right up against the edge of that tweet container. Let’s give it some space with padding.

.tweet {
  display: flex;
  align-items: flex-start;
  border: 1px solid #ccc;
  padding: 10px;
}

Now the tweet has some padding, but there’s also some extra space coming from somewhere. If we highlight the elements in the browser’s developer tools, you’ll notice margins above and below the p and ul elements (in Chrome devtools, margins are orange and padding is green):

It’s also interesting that the margin between the lines is the same as above and below – it’s not doubled up! That’s because CSS collapses margins vertically. When two margins touch top-to-bottom like this, the bigger one wins. Read more about collapsing margins at CSS-Tricks.

For this layout, I’ll change the margin manually on those 3 elements on the right: the .author-meta, p, and ul. For a real site layout you might consider pulling in a CSS reset to give you a common starting point across the different browsers.

p, ul {
  margin: 0;
}
.author-meta, p {
  margin-bottom: 1em;
}

Separating selectors with commas , is a way to apply a set of properties to multiple selectors at once. So p, ul says “all p elements, AND all ul elements”. It’s a union of both.

We’re also using a new unit here, the em in 1em. One em is equal to the body font size in pixels. The default font size is 16px (16 pixels high), so in our case 1em == 16px. As the font size changes, the em scale changes with it, so 1em is a nice way to express “I want the margin below the text to be as tall as the text, whatever that is.”

And now we have this:

Now let’s make the image a bit smaller, and turn it into a circle. We’ll make it 48px, which is the same size Twitter uses.

.avatar {
  margin-right: 10px;
  width: 48px;
  border-radius: 50%;
}

The border-radius property lets us round the corners of boxes, and there are a few ways to specify its value. You can give it a number in px or em or another unit, if you want a small radius. Here’s border-radius: 5px for instance:

If we set the border radius to half the width and height (24px in this case) we’ll get a circle. But an easier way is to set it to 50%, which will figure out the correct size to make a circle without us having to know the exact size ahead of time. And, bonus, if the size changes later, we don’t need to touch the border-radius at all!

Draw the Rest of the Owl

There are a few more changes we can make to polish up the final product.

We’ll set the font to Helvetica (the one Twitter uses), bring the font size down a bit, bold the Name, and, um, flip the order of the “@handle Name” (in the HTML) because that’s not how it looks on Twitter :D

.tweet {
  display: flex;
  align-items: flex-start;
  border: 1px solid #ccc;
  padding: 10px;
  /* 
    Change the font and size.
    Setting it on .tweet changes it for all child elements.
    (except the buttons. buttons are weird)
  */
  font-family: Helvetica, Arial, sans-serif;
  font-size: 14px;
}

.name {
  font-weight: 600;
}

.handle,
.time {
  color: #657786;
}

Using font-weight: 600; is the same as font-weight: bold; Some fonts come in lots of different weights, and you can specify from 100 to 900 (thinnest to boldest). normal (the default) is the same as 400.

By the way… CSS technically does not allow comments to start with // like in JS and other langauges. The // style will work in some browsers, but it’s not safe across all of them. Surround your comments with the C-style /* */ and you’ll be all set.

One more little trick: we’ll add a raised dot between the “handle” and the “time” by using a pseudo-element. Since the dot is purely stylistic, it makes sense to do it in CSS without muddying up the HTML.

.handle::after {
  content: " \00b7";
}

The ::after part creates a pseudo-element which gets placed inside .handle, but at the end of it (“after” the content). You can also use ::before. The content attribute can be set to any text, including Unicode characters. You can go wild styling pseudo elements, same as any other. They can be handy for things like badges, notification indicators, or other little flourishes.

Icon Buttons

We’ll do one more thing, which is to replace the buttons with icons. We’ll add Font Awesome inside the head tag:

<link
  rel="stylesheet"
  href="https://use.fontawesome.com/releases/v5.8.1/css/all.css"
  integrity="sha384-50oBUHEmvpQ+1lW4y57PTFmhCaXp0ML5d60M1M7uH2+nqUivzIebhndOJK28anvf"
  crossorigin="anonymous"
/>

And then replace the actions ul with this one, where each button has an icon and some hidden text:

<ul class="actions">
  <li>
    <button>
      <i
        class="fas fa-reply"
        aria-hidden="true"
      ></i>
      <span class="sr-only">Reply</span>
    </button>
  </li>
  <li>
    <button>
      <i
        class="fas fa-retweet"
        aria-hidden="true"
      ></i>
      <span class="sr-only">Retweet</span>
    </button>
  </li>
  <li>
    <button>
      <i
        class="fas fa-heart"
        aria-hidden="true"
      ></i>
      <span class="sr-only">Like</span>
    </button>
  </li>
  <li>
    <button>
      <span aria-hidden="true">...</span>
      <span class="sr-only">More Actions</span>
    </button>
  </li>
</ul>

Font Awesome is an icon font, and it co-opts the i “italic” tag to display icons. Since it’s a font, CSS properties that apply to text (like color and font-size) will work on the icons too.

Here we’ve added a few small tweaks to make the buttons accessible:

The aria-hidden="true" attribute tells screen readers to ignore the icon.
The sr-only class is provided by Font Awesome. It visually hides elements that it’s applied to, while leaving them accessible to screen readers.

Here’s an excellent free egghead lesson from Marcy Sutton about creating accessible icon buttons.

Now we’ll add a little bit of style to the buttons – removing the border, giving them a better color, and enlarging the font a bit. We’ll also set cursor: pointer which will turn the mouse cursor into the “hand” you usually see when you hover over a link. Finally, .actions button:hover will target buttons that are being hovered-over, and color them blue.

.actions button {
  border: none;
  color: #657786;
  font-size: 16px;
  cursor: pointer;
}
.actions button:hover {
  color: #1da1f2;
}

Here is the final styled tweet in all its glory:

And here’s the CodeSandbox if you want to play around with it yourself.

How to Get Better at CSS

The biggest thing you can do to improve your CSS skills is to practice.

Pick existing sites that you like, and copy them. Designers and artists call this “copy work”. I wrote an article about how to learn React with copywork and the principles all apply to CSS as well.

Pick layouts that look interesting, and a bit outside your comfort zone. Recreate them with HTML and CSS. When you get stuck, use your browser’s developer tools to inspect the existing sites and figure out their tricks. Lather, rinse, repeat :)

Implementing a Mockup: CSS Layout Step by Step was originally published on my blog.

The Path to Becoming a Front End Developer in 2019

Dave Ceddia — Tue, 15 Jan 2019 19:06:24 +0000

As 2019 kicks off, there’s always a flood of New Years’ resolutions.

Lose weight. Eat healthy. Get a job as a front end developer.

You know. Little, easy things. Nothing crazy.

I’m kidding, of course. These big life goals are never easy. Simple, maybe – go to the gym every day, choose salad for lunch, practice coding every evening – but we know from experience that actually doing the work every day is not easy.

And the results never come as quick as we want. Day-to-day, sometimes it feels like a slog. Honestly, it is a slog sometimes.

And yet, if we want to make progress on our goals, real progress, some amount of daily effort is a big help. Daily effort quickens the pace.

The big decision, then, is what to focus on. What are the critical skills you need to master, and what order should you tackle them?

I’m going to try to give you some perspective and a concrete plan of action.

Learning is a Puzzle

If you’re putting together a puzzle, you probably wouldn’t try to assemble the top row, then the second row, then the third. Puzzle pieces don’t tend to fit into “rows.” Except in that image I drew, because it was easier to draw that way.

More likely, you’ll start from the corners and the edges, and work your way in. Start with some pieces you’re sure of.

Along the way you might discover a handful pieces that fit together in a little clump. 2, 3, maybe 5 pieces. Then you’ll wonder “where does this clump fit?”, but you might not find an answer until much later in the puzzle.

Learning web development is like this.

You are collecting little clusters of knowledge. Some of those clusters you’ll use every day, and some of them you’ll use rarely (but they’ll come in super handy one day, like when the server crashes at 2am and you remember that you used grep once, and start grepping through logs to find the problem.). They’re all part of the massive puzzle we call “web development.”

Learn in Isolation

Whenever you can, break down the subject you are trying to learn into the smallest atoms possible – individual skills.

Then, learn each skill all by itself, even if that means taking a diversion and creating a small sandbox project to focus on that one skill. This will make the learning go much faster, and you’ll retain more of it.

If there was one “hack” I could give to every person learning web development, it would be this: the ability to see a problem or project not as an indivisible thing, but as a cluster of skills which can be broken apart, learned separately, and then recombined.

Break it down: Full Stack React App

Here’s an example. Let’s say you want to learn all the parts of building a production-level app with React, so you can build your own (or get hired to build one).

An app like this is made up of many parts.

There’s the front end. It’s written in JavaScript, probably. It uses React. Maybe Redux or MobX. There might be a Webpack config. There’s definitely JSX. Maybe CSS or Sass, or maybe CSS-in-JS. There are probably HTTP requests with fetch or axios. There might be GraphQL.

The back end might be written with Node + Express, or Ruby on Rails, or Elixir and Phoenix, or any number of things. And that back end probably talks to a database, which might be SQL-based (PostgreSQL or MySQL) or document-based (MongoDB).

All of that is waaaaayyy too much to learn simultaneously. If you take it on as one big project, intending to learn it all as you go, it turns into a big jumble in your head and it’s hard to remember which pieces go where. Even if you just try to isolate the front end part, it’s still an overwhelming amount of stuff.

So ask yourself, could I split it up by technology, and learn one at a time?

Learn Each Skill on Its Own

Could you learn JavaScript by itself? Sure, there’s the excellent You Don’t Know JS series (free online), and plenty of other resources.

Could you learn React by itself? Yep, there’s a book focused on just React (I wrote it!).

JSX looks a lot like HTML, so it’s probably easier to figure out how HTML works before going too far with React + JSX.

You could write a janky-looking app without even touching CSS at all, so you could definitely learn React without CSS. Or CSS without React. And you could wait to learn styled-components or some other CSS-in-JS lib until after you figure out how CSS rules work.

Redux is an add-on to React, so you could learn Redux by itself. (once you know a bit about React)

Webpack configuration is orthogonal to the goal of getting a React app on the screen; you could use Create React App now and figure out Webpack later.

External data, no matter whether it comes from plain a REST API or GraphQL, is another complication. For the purposes of learning how React works, you can use static data initially, by copying the JSON response data from the API and storing it in a variable – open up DevTools, Network tab, pick a request, copy-paste the response! Then learn how to asynchronously fetch the data later.

The back end can be broken down in the same way.

Always question the assumption that a problem or project must be learned or built as a whole. See if you can break it down. Tease out the individual parts or layers. Learn those parts on their own when you can. Sometimes you can’t do that, and in that case, still: strip out as much unnecssary stuff as possible.

A Web Development Learning Plan

All that said, real-life you needs some real-life direction right now.

Here’s the path I suggest, linearized the best I can. Keep in mind the idea of “just in time learning.”

Practice each new thing as you learn it. Reading blogs & watching tutorials is great, but your brain won’t remember it for long without practice. Devise your own exercises if none are given. Here are some ideas for how to come up with your own React practice projects, for instance.

For each of these things, learn just enough, then move on.

You do not need an encyclopedic knowledge of every HTML element, CSS selector, JavaScript feature, or command line tool. That’s what Google and StackOverflow are for. Most of us who’ve been coding for years can tell you about recently learning some fairly basic thing and being amazed by it. (right this moment: omg there’s a dialog element?)

A Bit of Command Line

Often times the first step to getting started on a project is cloning a repo from Github, or creating a blank project with create-react-app. Then you’ll need to run npm or yarn to install packages, and be able to navigate your project on the filesystem.

A little bit of command line knowledge can help make all of this feel less like typing magical commands into a magical box.

You don’t need to go crazy here, but it’s worthwhile to understand the basics of navigating the fileystem, displaying files, and that kind of thing. Learn Enough Command Line to Be Dangerous by Michael Hartl (of Rails Tutorial fame) is a nice intro, and it’s free to read online. This DEV article by Max Antonucci is also good: The Shell Introduction I Wish I Had.

Version Control with Git

You know that problem where your code is working great, and then you change one tiny thing, and then for some reason it breaks?

And then, when you undo that change, it’s still broken? wtf!!

This is literally the worst.

Version control solves this problem, and I wish I had learned about it earlier than I did. (I also wish someone had framed version control as a benefit to me rather than a chore. Because the benefit is HUGE, and Git makes it pretty easy.)

My introduction was this explanation of how Git works in story form, The Git Parable. Give it a read, it’s great. Even if you understand Git commands I bet you’ll learn something new.

Git is just one of many different version control systems, but it’s the current reigning champion, popularized by Github.

Also, fun fact: Git and Github are not the same thing. Github is a hosting service for Git repositories, but Git existed long before Github and it can be used independently. You can use Git to manage your code locally without even having an internet connection, which is part of what makes it so awesome.

So once you’ve got a bit of command line knowledge under your belt, install the git command. Then whenever you create a new project directory, do this:

git init .
git add .
git commit -m "Initial commit"

And then every time you get the code into a working state, or before you make a change that might break something, commit your code:

git add .
git commit -m "Saving this before I break it."

Each commit is like a checkpoint. You can go jump back in time to any previous commit (back when your code was working). This all exists locally on your computer. If your computer goes up in flames, your code is gone. That’s what Github is for (and offsite backups, I suppose).

If you want to learn more about Git, like how to checkout previous commits to get back to your working code, push to Github, and more, go through this Learn Enough Git to Be Dangerous tutorial. It’s not too long and at the end you’ll even have a webpage deployed to Github Pages. Which is a great sandbox for...

The Languages of the Web

To build software for the web, you need to know HTML, CSS, and JavaScript. At least enough of each to get by.

You can write HTML without any CSS or JS. You can’t do much with CSS unless you have an HTML document to style. So you’ll want to learn some HTML before you learn some CSS.

JavaScript’s utility is multi-pronged, though. It can be added on top of an HTML document, to make an interactive app... or it can be used outside the browser with Node.js to do any number of interesting things – from writing servers, to command line apps, to controlling IoT devices and doing machine learning.

What seems more fun? Writing JS to do stuff in a browser, or learning it in isolation with little coding exercises in Node? No right answer here. It depends on your goals.

If you’re leaning toward front end development, I’d suggest learning JS in the browser from the beginning, starting with “vanilla” JS, without React and Webpack builds and all that stuff.

And in all of these, remember, the point is not to master each skill to completion before moving on. Just learn enough, until it feels like you can tackle the next skill.

I’ll probably get yelled at for saying this, but I don’t believe you need to master vanilla JS and the DOM before you move on to something like React, if what you really want to do is use frameworks. I do think it’s good to get at least a bit of practice with them, and know that they exist, and be able to look up the specifics (on MDN, for example) when you need them.

Learn to Debug

Debugging is a learnable skill. Luckily, if you’re like me, or most other people getting started, you’ll have plenty of practice running into errors and needing to solve them.

The easiest solution, of course, is to copy and paste your error into Google.

Sometimes, though, Google is no help. Maybe the error is too specific to your code, like a syntax error.

And then sometimes, Google finds almost no related results. This is almost always a sign that it’s a simple, silly mistake somewhere. Like “I forgot to save the file” or “I forgot to restart the server.”

One time, I hit upon an editor bug in some flavor of Eclipse where the Save function stopped working.

I’d change the file. The title bar would show AbstractFactoryObserverPatternImpl.java * (with the little star, showing it had been changed). I’d click “Save” and mash Ctrl+S, but the little star remained. “Maybe it’s a UI bug,” I thought. So after saving I opened up the file in vim – and sure enough, it hadn’t been changed.

This was (a) ridiculous, because text editors basically have only two jobs, editing text and saving it... and (b) a nice reminder to always check assumptions. Even crazy ones.

So the next time you run into a weird problem, break down the problem into layers, and check every assumption in the stack. Brainstorm possible reasons for failure.

For example, with the “I changed the code but it didn’t do anything” problem:

Is that section of code running at all? Can you add a console.log and see it printed?
Is the automatic build working? (or, if it’s manual, did you run the build?)
If it’s part of a running server, has that server been restarted?
Are you hitting the right server?
Are you changing the right file?
Are you changing the right project? (e.g. maybe you made a copy, myproject-working-for-real-this-time-7, but your editor is still open to myproject-working-for-real-this-time-6. Also: stop doing that and start using Git ;)
Is the file actually changing? Did the Save function in your editor stop working?

After you ask all those questions, and you check everything, and everything seems correct but it’s still broken... it’s time to start restarting things. Trust nothing and nobody.

Remember how I mentioned earlier how learning web dev is like building little clusters of interconnected skills? Debugging time is when you draw upon all those skills. The better you understand why things work the way they do, including the interconnections between different parts of your app, the better and faster you can debug problems when they arise.

You’ll begin to see problems and solutions in high resolution. Instead of just “the app is broken,” you’ll see “the server threw an exception while preparing part of the data” or “the JS code failed to parse the JSON and stopped running.”

Learn How The Web Works

It will be a big help to understand how the web works in general. Having the big picture in mind will help not only during development, but also help a TON when debugging.

Learn what happens when you visit a web page. There’s a lot going on behind the scenes! Most of it can fail sometimes, too. If you know all the steps you can diagnose whether, for example, the server is down, or the DNS entry is wrong, or the server machine is up but the webserver process is not, or an adblocker prevented your icon font from loading, or whatever other weird thing might happen.

The Developer Tools are a huge help in learning how this works. Open up the devtools in your browser, look at the Network tab, and refresh the page. Look at all the requests that went out. Look for failures. Click into them and see the data they returned. This, by the way, is a great way to discover and use an undocumented “API” from a site you want to build an app around!

Learn a Framework

React is very popular right now, and it benefits from a ton of good resources online for learning. The job market is also good for React developers at the moment.

The official React Tutorial is a great place to start. It’s well-written, and will help you get from setup to a working app. I also put together a nice little free 5-day React course for learning the basics, and if you want something more long-form, I wrote a book, Pure React, that goes deep on just React with plenty of exercises and examples to make it all stick.

If you try React and don’t like it, check out Vue.js. It’s a popular alternative to React and a lot of people love it.

Begin (or continue) Today!

If learning web development is a goal of yours this year, I encourage you to take action on it right now. Reading and wishing and hoping won’t get you much closer. Putting hands to keyboard and writing code will.

Even though it’s impossible to cover everything and provide a path for everyone’s own unique starting point, I hope this guide has given you some direction in your web development learning journey. Leave a comment if it helped, or if you have done something specific that helped you move forward!

Originally published at Dave's blog as The Path to Becoming a Front End Developer in 2019.

React Project Ideas, and How to Invent Your Own

Dave Ceddia — Tue, 11 Dec 2018 14:12:08 +0000

When you get right down to it, learning React (or any new thing) is all about practice. Sure, you need to read some tutorials and docs first. Maybe watch a few videos.

But then? Once you get stuck in the rut of googling for the answer every time, it can be a very tough habit to break. You find yourself googling for every little thing, and then – the next time you have the exact same problem – you have to google it again. I still do this every time I have to quit vim. Please send help.

The truth is, when you don’t understand the underlying concepts – how state works, how to pass props, how to think in components – it’s pretty damn hard to build an app from scratch.

Even though you know you can probably struggle through and figure it out, it’s way faster to just google it.

You can find lists of React project ideas, but even those might not be exactly what you want. Maybe they don’t cover the skills you want to learn, or they just don’t seem fun to you, despite how hard I worked on making that list.

So how can you come up with your own project ideas?

Invent Your Own Project Ideas

Where do good project ideas come from?

Personally, I tend to reach for things that are modeled after existing apps or real-world objects. I try to avoid anything too original. That might seem weird, but originality adds complexity.

If this project is for practice, then your goal is to practice React (or Redux, or GraphQL, or whatever) – not to also simultaneously practice design, and user experience, and product development (unless, of course, it is).

Focus is key here. Scope the problem down to the bare minimum. The Minimum Viable Practice Project. A tiny atom. A mere slice of the full functionality of an entire production application.

What Do You Want To Learn?

Before you can focus, you’ll need to figure out what you want to focus on. Pick one thing, even if you have a whole laundry list of tech to learn.

Want to learn React? Then just focus on React, all by itself (the way I teach it in my book). Don’t add Redux yet. Don’t add other tech that you don’t yet understand (whether that’s GraphQL, AWS Lambdas, server-side rendering, or whatever).

Want to learn Redux? Hopefully you already understand the basics of React – great! Now create a tiny React app and add Redux to it, so you can focus on the new things that Redux brings to the table: a store, actions, reducers, thunks, etc.

Want to learn GraphQL? Awesome. Make sure you understand React. Then create a small app that includes React + GraphQL. Now you have to find or create a GraphQL server for the backend, too.

You could find a public one – like GitHub’s GraphQL API, and just focus on learning the client side… or you could stand up your own little GraphQL server to play with.

Minimize and Simplify

The point is this: More moving parts means more things that can break, and a much bigger headache to debug. Anyone who’s ever googled “react CORS error” knows the pain of thinking that the problem lies in one piece of tech they’re focused on, while the root cause is something else entirely.

So: Choose your own difficulty setting. You don’t have to learn it all at once, in parallel. You can learn it all in time. Piece-by-piece, like building a brick wall.

Whenever you can, cut down on the number of moving pieces that are not the one thing you are trying to learn.

Brainstorm Project Ideas

Look around at the apps you use – mobile and desktop. Look at the sites you visit. Look around your house for physical objects that you could represent digitally.

Pick something that interests you, or relates to one of your hobbies in some way.

Into woodworking? Make a “cut list” app.

Into aviation? Maybe a “log book” would be a fun project.

Playing music? How about building a Circle of Fifths calculator.

Saving for early retirement a la Mr. Money Mustache? Maybe a gas mileage calculator would help. (or bike mileage, for that matter).

Here are a bunch of ideas I came up with while brainstorming examples for a new course. Hopefully it’ll get your creative ideas flowing.

Thermostat. It’s a physical object with controls and state; basically a “Counter” plus a timer)
Toaster. A few pieces of state – on/off, light/dark. A timer.
Traffic light. Red/Yellow/Green lights and a timer.
Activity tracker. At its most basic, it’s just a list of things you did. You could also design it like a chain-based habit tracker.
Podcast player. Model it after iTunes, or Overcast, or whatever you like.
Weather app. This could be extremely simple, with just a few days… or it could be hugely complex, like a whole weather site.
Notes recorder. Learn the Web Audio API, make short recordings, and then store them in a list. Add/Rename/Delete recordings.
Shopping site w/ cart. It’s a list of products, and a list of items in the cart. Add/Remove/Update. You could make it client-side only (static data) or integrate it with a server.
Customizable dashboard w/ graphs. Everyone loves a good dashboard. Here’s a chance to learn D3.js and integrate it with React.
Website Analytics. Mostly, it’s a list of page names and view counts. But if you fancied it up with graphs, you could work in some D3. And to do it for real, you’ll need a whole back end, and some minimal plain JS code to track page views.
Blog + editor. It’s basically Wordpress. Clone their UI design.
Some kind of quiz/survey builder like TypeForm (that would be great practice for getting the little UX details right)
Trip packer. It’s pretty much a Todo List, but reframed. You could save multiple lists, like “Going on Vacation” vs. “Work Trip”.
Email client. Model an app after Gmail or Fastmail. Great practice for using static data.
Slack clone. Model an app after Slack or IRC. Channels & messages. Good Redux practice.
Course platform. Model it after Teachable or Podia or egghead, with a list of lessons on the side and content in the middle. Good CRUD practice.

Go Forth And Build Things

Now that you can invent endless project ideas on your own, all that’s left to do is… go build them :)

React Project Ideas, and How to Invent Your Own was originally published on my blog.

Redux vs. The React Context API

Dave Ceddia — Tue, 17 Jul 2018 13:50:31 +0000

React 16.3 added a new Context API – new in the sense that the old context API was a behind-the-scenes feature that most people either didn’t know about, or avoided using because the docs said to avoid using it.

Now, though, the Context API is a first-class citizen in React, open to all (not that it wasn’t before, but it’s, like, official now).

As soon as React 16.3 came out there were articles all across the web proclaiming the death of Redux because of this new Context API. If you asked Redux, though, I think it would say “the reports of my death are greatly exaggerated.”

In this post I want to cover how the new Context API works, how it is similar to Redux, when you might want to use Context instead of Redux, and why Context doesn’t replace the need for Redux in every case.

A Motivating Example

I’m going to assume you’ve got the basics of React down pat (props & state), but if you don’t, I have a free 5-day course to help you learn react here.

Let’s look at an example that would cause most people to reach for Redux. We’ll start with a plain React version, and then see what it looks like in Redux, and finally with Context.

This app has the user’s information displayed in two places: in the nav bar at the top-right, and in the sidebar next to the main content.

The component structure looks like this:

With pure React (just regular props), we need to store the user’s info high enough in the tree that it can be passed down to the components that need it. In this case, the keeper of user info has to be App.

Then, in order to get the user info down to the components that need it, App needs to pass it along to Nav and Body. They, in turn, need to pass it down again, to UserAvatar (hooray!) and Sidebar. Finally, Sidebar has to pass it down to UserStats.

Let’s look at how this works in code (I’m putting everything in one file to make it easier to read, but in reality these would probably be split out into separate files).

import React from "react";
import ReactDOM from "react-dom";
import "./styles.css";

const UserAvatar = ({ user, size }) => (
  <img
    className={`user-avatar ${size || ""}`}
    alt="user avatar"
    src={user.avatar}
  />
);

const UserStats = ({ user }) => (
  <div className="user-stats">
    <div>
      <UserAvatar user={user} />
      {user.name}
    </div>
    <div className="stats">
      <div>{user.followers} Followers</div>
      <div>Following {user.following}</div>
    </div>
  </div>
);

const Nav = ({ user }) => (
  <div className="nav">
    <UserAvatar user={user} size="small" />
  </div>
);

const Content = () => <div className="content">main content here</div>;

const Sidebar = ({ user }) => (
  <div className="sidebar">
    <UserStats user={user} />
  </div>
);

const Body = ({ user }) => (
  <div className="body">
    <Sidebar user={user} />
    <Content user={user} />
  </div>
);

class App extends React.Component {
  state = {
    user: {
      avatar:
        "https://www.gravatar.com/avatar/5c3dd2d257ff0e14dbd2583485dbd44b",
      name: "Dave",
      followers: 1234,
      following: 123
    }
  };

  render() {
    const { user } = this.state;

    return (
      <div className="app">
        <Nav user={user} />
        <Body user={user} />
      </div>
    );
  }
}

ReactDOM.render(<App />, document.querySelector("#root"));

Here’s a working example on CodeSandbox.

Now, this isn’t terrible. It works just fine. But it’s a bit annoying to write. And it gets more annoying when you have to pass down a lot of props (instead of just one).

There’s a bigger downside to this “prop drilling” strategy though: it creates coupling between components that would otherwise be decoupled. In the example above, Nav needs to accept a “user” prop and pass it down to UserAvatar, even though Nav does not have any need for the user otherwise.

Tightly-coupled components (like ones that forward props down to their children) are more difficult to reuse, because you’ve gotta wire them up with their new parents whenever you plop one down in a new location.

Let’s look at how we might improve it with Redux.

Using Redux to Improve Data Flow

I’m going to go through the Redux example quickly so we can look more deeply at how Context works, so if you are fuzzy on Redux, read this intro to Redux first (or watch the video).

Here’s the React app from above, refactored to use Redux. The user info has been moved to the Redux store, which means we can use react-redux’s connect function to directly inject the user prop into components that need it.

This is a big win in terms of decoupling. Take a look at Nav, Body, and Sidebar and you’ll see that they’re no longer accepting and passing dow the user prop. No more playing hot potato with props. No more needless coupling.

import React from "react";
import ReactDOM from "react-dom";

// We need createStore, connect, and Provider:
import { createStore } from "redux";
import { connect, Provider } from "react-redux";

// Create a reducer with an empty initial state
const initialState = {};
function reducer(state = initialState, action) {
  switch (action.type) {
    // Respond to the SET_USER action and update
    // the state accordingly
    case "SET_USER":
      return {
        ...state,
        user: action.user
      };
    default:
      return state;
  }
}

// Create the store with the reducer
const store = createStore(reducer);

// Dispatch an action to set the user
// (since initial state is empty)
store.dispatch({
  type: "SET_USER",
  user: {
    avatar: "https://www.gravatar.com/avatar/5c3dd2d257ff0e14dbd2583485dbd44b",
    name: "Dave",
    followers: 1234,
    following: 123
  }
});

// This mapStateToProps function extracts a single
// key from state (user) and passes it as the `user` prop
const mapStateToProps = state => ({
  user: state.user
});

// connect() UserAvatar so it receives the `user` directly,
// without having to receive it from a component above

// could also split this up into 2 variables:
// const UserAvatarAtom = ({ user, size }) => ( ... )
// const UserAvatar = connect(mapStateToProps)(UserAvatarAtom);
const UserAvatar = connect(mapStateToProps)(({ user, size }) => (
  <img
    className={`user-avatar ${size || ""}`}
    alt="user avatar"
    src={user.avatar}
  />
));

// connect() UserStats so it receives the `user` directly,
// without having to receive it from a component above
// (both use the same mapStateToProps function)
const UserStats = connect(mapStateToProps)(({ user }) => (
  <div className="user-stats">
    <div>
      <UserAvatar user={user} />
      {user.name}
    </div>
    <div className="stats">
      <div>{user.followers} Followers</div>
      <div>Following {user.following}</div>
    </div>
  </div>
));

// Nav doesn't need to know about `user` anymore
const Nav = () => (
  <div className="nav">
    <UserAvatar size="small" />
  </div>
);

const Content = () => (
  <div className="content">main content here</div>
);

// Sidebar doesn't need to know about `user` anymore
const Sidebar = () => (
  <div className="sidebar">
    <UserStats />
  </div>
);

// Body doesn't need to know about `user` anymore
const Body = () => (
  <div className="body">
    <Sidebar />
    <Content />
  </div>
);

// App doesn't hold state anymore, so it can be
// a stateless function
const App = () => (
  <div className="app">
    <Nav />
    <Body />
  </div>
);

// Wrap the whole app in Provider so that connect()
// has access to the store
ReactDOM.render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.querySelector("#root")
);

Here’s the Redux example on CodeSandbox.

Now you might be wondering how Redux achieves this magic. It’s a good thing to wonder. How is it that React doesn’t support passing props down multiple levels, but Redux is able to do it?

The answer is, Redux uses React’s context feature. Not the modern Context API (not yet) – the old one. The one the React docs said not to use unless you were writing a library or knew what you were doing.

Context is like an electrical bus running behind every component: to receive the power (data) passing through it, you need only plug in. And (React-)Redux’s connect function does just that.

This feature of Redux is just the tip of the iceberg, though. Passing data around all over the place is just the most apparent of Redux’s features. Here are a few other benefits you get out of the box:

`connect` is pure

connect automatically makes connected components “pure,” meaning they will only re-render when their props change – a.k.a. when their slice of the Redux state changes. This prevents needless re-renders and keeps your app running fast. DIY method: Create a class that extends PureComponent, or implement shouldComponentUpdate yourself.

Easy Debugging with Redux

The ceremony of writing actions and reducers is balanced by the awesome debugging power it affords you.

With the Redux DevTools extension you get an automatic log of every action your app performed. At any time you can pop it open and see which actions fired, what their payload was, and the state before and after the action occurred.

Another great feature the Redux DevTools enable is time travel debugging a.k.a. you can click on any past action and jump to that point in time, basically replaying every action up to and including that one (but no further). The reason this can work is because each action immutably update’s the state, so you can take a list of recorded state updates and replay them, with no ill effects, and end up where you expect.

Then there are tools like LogRocket that basically give you an always-on Redux DevTools in production for every one of your users. Got a bug report? Sweet. Look up that user’s session in LogRocket and you can see a replay of what they did, and exactly which actions fired. That all works by tapping into Redux’s stream of actions.

Customize Redux with Middleware

Redux supports the concept of middleware, which is a fancy word for “a function that runs every time an action is dispatched.” Writing your own middleware isn’t as hard as it might seem, and it enables some powerful stuff.

For instance…

Want to kick off an API request every time an action name starts with FETCH_? You could do that with middleware.
Want a centralized place to log events to your analytics software? Middleware is a good place for that.
Want to prevent certain actions from firing at certain times? You can do that with middleware, transparent to the rest of your app.
Want to intercept actions that have a JWT token and save them to localStorage, automatically? Yep, middleware.

Here’s a good article with some examples of how to write Redux middleware.

How to Use the React Context API

But hey, maybe you don’t need all those fancy features of Redux. Maybe you don’t care about the easy debugging, the customization, or the automatic performance improvements – all you want to do is pass data around easily. Maybe your app is small, or you just need to get something working and address the fancy stuff later.

React’s new Context API will probably fit the bill. Let’s see how it works.

I published a quick Context API lesson on Egghead if you’d rather watch than read (3:43):

There are 3 important pieces to the context API:

The React.createContext function which creates the context
The Provider (returned by createContext) which establishes the “electrical bus” running through a component tree
The Consumer (also returned by createContext) which taps into the “electrical bus” to extract the data

The Provider is very similar to React-Redux’s Provider. It accepts a value prop which can be whatever you want (it could even be a Redux store… but that’d be silly). It’ll most likely be an object containing your data and any actions you want to be able to perform on the data.

The Consumer works a little bit like React-Redux’s connect function, tapping into the data and making it available to the component that uses it.

Here are the highlights:

// Up top, we create a new context
// This is an object with 2 properties: { Provider, Consumer }
// Note that it's named with UpperCase, not camelCase
// This is important because we'll use it as a component later
// and Component Names must start with a Capital Letter
const UserContext = React.createContext();

// Components that need the data tap into the context
// by using its Consumer property. Consumer uses the
// "render props" pattern.
const UserAvatar = ({ size }) => (
  <UserContext.Consumer>
    {user => (
      <img
        className={`user-avatar ${size || ""}`}
        alt="user avatar"
        src={user.avatar}
      />
    )}
  </UserContext.Consumer>
);

// Notice that we don't need the 'user' prop any more,
// because the Consumer fetches it from context
const UserStats = () => (
  <UserContext.Consumer>
    {user => (
      <div className="user-stats">
        <div>
          <UserAvatar user={user} />
          {user.name}
        </div>
        <div className="stats">
          <div>{user.followers} Followers</div>
          <div>Following {user.following}</div>
        </div>
      </div>
    )}
  </UserContext.Consumer>
);

// ... all those other components go here ...
// ... (the ones that no longer need to know or care about `user`)

// At the bottom, inside App, we pass the context down
// through the tree using the Provider
class App extends React.Component {
  state = {
    user: {
      avatar:
        "https://www.gravatar.com/avatar/5c3dd2d257ff0e14dbd2583485dbd44b",
      name: "Dave",
      followers: 1234,
      following: 123
    }
  };

  render() {
    return (
      <div className="app">
        <UserContext.Provider value={this.state.user}>
          <Nav />
          <Body />
        </UserContext.Provider>
      </div>
    );
  }
}

Here’s the full code in a CodeSandbox.

Let’s go over how this works.

Remember there’s 3 pieces: the context itself (created with React.createContext), and the two components that talk to it (Provider and Consumer).

Provider and Consumer are a Pair

The Provider and Consumer are bound together. Inseperable. And they only know how to talk to each other. If you created two separate contexts, say “Context1” and “Context2”, then Context1’s Provider and Consumer would not be able to communicate with Context2’s Provider and Consumer.

Context Holds No State

Notice how the context does not have its own state. It is merely a conduit for your data. You have to pass a value to the Provider, and that exact value gets passed down to any Consumers that know how to look for it (Consumers that are bound to the same context as the Provider).

When you create the context, you can pass in a “default value” like this:

const Ctx = React.createContext(yourDefaultValue);

This default value is what the Consumer will receive when it is placed in a tree with no Provider above it. If you don’t pass one, the value will just be undefined. Note, though, that this is a default value, not an initial value. A context doesn’t retain anything; it merely distributes the data you pass in.

Consumer Uses the Render Props Pattern

Redux’s connect function is a higher-order component (or HoC for short). It wraps another component and passes props into it.

The context Consumer, by contrast, expects the child component to be a function. It then calls that function at render time, passing in the value that it got from the Provider somewhere above it (or the context’s default value, or undefined if you didn’t pass a default).

Provider Accepts One Value

Just a single value, as the value prop. But remember that the value can be anything. In practice, if you want to pass multiple values down, you’d create an object with all the values and pass that object down.

That’s pretty much the nuts and bolts of the Context API.

Context API is Flexible

Since creating a context gives us two components to work with (Provider and Consumer), we’re free to use them however we want. Here are a couple ideas.

Turn the Consumer into a Higher-Order Component

Not fond of the idea of adding the UserContext.Consumer around every place that needs it? Well, it’s your code! You can do what you want. You’re an adult.

If you’d rather receive the value as a prop, you could write a little wrapper around the Consumer like this:

function withUser(Component) {
  return function ConnectedComponent(props) {
    return (
      <UserContext.Consumer>
        {user => <Component {...props} user={user}/>}
      </UserContext.Consumer>
    );
  }
}

And then you could rewrite, say, UserAvatar to use this new withUser function:

const UserAvatar = withUser(({ size, user }) => (
  <img
    className={`user-avatar ${size || ""}`}
    alt="user avatar"
    src={user.avatar}
  />
));

And BOOM, context can work just like Redux’s connect. Minus the automatic purity.

Here’s an example CodeSandbox with this higher-order component.

Hold State in the Provider

The context’s Provider is just a conduit, remember. It doesn’t retain any data. But that doesn’t stop you from making your own wrapper to hold the data.

In the example above, I left App holding the data, so that the only new thing you’d need to understand was the Provider + Consumer components. But maybe you want to make your own “store”, of sorts. You could create a component to hold the state and pass them through context:

class UserStore extends React.Component {
  state = {
    user: {
      avatar:
        "https://www.gravatar.com/avatar/5c3dd2d257ff0e14dbd2583485dbd44b",
      name: "Dave",
      followers: 1234,
      following: 123
    }
  };

  render() {
    return (
      <UserContext.Provider value={this.state.user}>
        {this.props.children}
      </UserContext.Provider>
    );
  }
}

// ... skip the middle stuff ...

const App = () => (
  <div className="app">
    <Nav />
    <Body />
  </div>
);

ReactDOM.render(
  <UserStore>
    <App />
  </UserStore>,
  document.querySelector("#root")
);

Now your user data is nicely contained in its own component whose sole concern is user data. Awesome. App can be stateless once again. I think it looks a little cleaner, too.

Here’s an example CodeSandbox with this UserStore.

Pass Actions Down Through Context

Rememeber that the object being passed down through the Provider can contain whatever you want. Which means it can contain functions. You might even call them “actions.”

Here’s a new example: a simple Room with a lightswitch to toggle the background color – err, I mean lights.

The state is kept in the store, which also has a function to toggle the light. Both the state and the function are passed down through context.

import React from "react";
import ReactDOM from "react-dom";
import "./styles.css";

// Plain empty context
const RoomContext = React.createContext();

// A component whose sole job is to manage
// the state of the Room
class RoomStore extends React.Component {
  state = {
    isLit: false
  };

  toggleLight = () => {
    this.setState(state => ({ isLit: !state.isLit }));
  };

  render() {
    // Pass down the state and the onToggleLight action
    return (
      <RoomContext.Provider
        value={{
          isLit: this.state.isLit,
          onToggleLight: this.toggleLight
        }}
      >
        {this.props.children}
      </RoomContext.Provider>
    );
  }
}

// Receive the state of the light, and the function to
// toggle the light, from RoomContext
const Room = () => (
  <RoomContext.Consumer>
    {({ isLit, onToggleLight }) => (
      <div className={`room ${isLit ? "lit" : "dark"}`}>
        The room is {isLit ? "lit" : "dark"}.
        <br />
        <button onClick={onToggleLight}>Flip</button>
      </div>
    )}
  </RoomContext.Consumer>
);

const App = () => (
  <div className="app">
    <Room />
  </div>
);

// Wrap the whole app in the RoomStore
// this would work just as well inside `App`
ReactDOM.render(
  <RoomStore>
    <App />
  </RoomStore>,
  document.querySelector("#root")
);

Here’s the full working example in CodeSandbox.

Should You Use Context, or Redux?

Now that you’ve seen both ways – which one should you use? Well, if there’s one thing that will make your apps better and more fun to write, it’s taking control of making the decisions. I know you might just want “The Answer,” but I’m sorry to have to tell you, “it depends.”

It depends on things like how big your app is, or will grow to be. How many people will work on it – just you, or a larger team? How experienced are you or your team with functional concepts (the ones Redux relies upon, like immutability and pure functions).

One big pernicious fallacy that pervades the JavaScript ecosystem is the idea of competition. The idea that every choice is a zero-sum game: if you use Library A, you must not use its competitor Library B. The idea that when a new library comes out that’s better in some way, that it must supplant an existing one. There’s a perception that everything must be either/or, that you must either choose The Best Most Recent or be relegated to the back room with the developers of yesteryear.

A better approach is to look at this wonderful array of choices like a toolbox. It’s like the choice between using a screwdriver or an impact driver. For 80% of the jobs, the impact driver is gonna put the screw in faster than the screwdriver. But for that other 20%, the screwdriver is actually the better choice – maybe because the space is tight, or the item is delicate. When I got an impact driver I didn’t immediately throw away my screwdriver, or even my non-impact drill. The impact driver didn’t replace them, it simply gave me another option. Another way to solve a problem.

Context doesn’t “replace” Redux any more than React “replaced” Angular or jQuery. Heck, I still use jQuery when I need to do something quick. I still sometimes use server-rendered EJS templates instead of spinning up a whole React app. Sometimes React is more than you need for the task at hand. Sometimes Redux is more than you need.

Today, when Redux is more than you need, you can reach for Context.

Redux vs. The React Context API was originally published by Dave Ceddia at Dave Ceddia on July 17, 2018.

Perfect Pulled Pork with React Native, Expo, and Express

Dave Ceddia — Thu, 07 Jun 2018 13:51:09 +0000

Originally posted on my blog.

Or: Taking a Picture Every 30 Seconds and Sending It To A Server.

I was planning to make pulled pork the next day. That evening I set up the Weber kettle, got out the bag of charcoal and some chunks of apple wood, and laid everything out. Mise en place, as they say. I’d be waking up at 7am the next morning to light it up, and I didn’t trust my sleepy self to remember everything.

One of the things I set out was the probe thermometer and 2 probes: one to measure the air temperature, and one to measure the internal temperature of the meat. Smoking is a low and slow method of cooking: you want to get the air temperature up to 225˚F and hold it there for hours as the meat slowly cooks and infuses with smoke. Smoking a pork shoulder (a.k.a. pulled-pork-to-be) can take 8 - 12 hours. Hence why I’m waking up at 7am.

So where does React Native play into all this?

Well, holding a temperature with a Weber kettle is a bit of a trick. And a manual one at that. There are 2 air vents you can tweak – one on top, one on the bottom. Open them up to increase the temperature, close them down to lower it. The fire takes a while to respond, though. It’s a fire, not a digital dial. So you, as the pit master, get to be a human PID controller for the day.

What I mean is: you have to keep watching the temperature, adjusting the vents, and re-checking. If you’re good at it, you don’t have to tweak it much, but I’m a newb, so I’m out there a lot.

I wanted to be able to know, without running out to the smoker every 15 minutes, whether the temperature was at 225˚F or close enough.

This is where React Native comes in.

At 9pm, after I’d laid out all the materials, I had the idea: I’ll make an app to take a picture of the thermometer every 30 seconds, and upload it to a server – and then I can just refresh a page instead of running down to the smoker!

And before you tell me – yes, I know there are remote thermometers for sale that do exactly this. And yes, I also know I could’ve just sat outside with a beer all day watching the thing, and that would’ve been fun too. But really I just wanted an excuse to play with React Native :)

Grand Plans: The System Layout

Like any good project, I started off thinking about how I wanted it to work.

I would need:

A phone with a camera (old iPhone 4S).
An app running on the phone to take pictures all day.
A server to receive the pictures, running on my laptop.
The same server to serve up the latest picture.

I decided I wanted to keep this as minimal as possible (mostly because it was 9pm and I still needed to wake up at 7). There would be little to no security. There would be no websockets notifying a React app to download the latest image. This server would simply accept images, and send back the latest upon request.

React Native

You’ve probably heard of React Native - a framework for building native mobile apps using React and JS. If you can write React apps, you can figure out React Native pretty quickly. The core concepts are the same, just props and state.

Since there’s no DOM behind React Native, though, there are some differences. Mainly, the HTML elements you know and love (div, span, img, etc.) are replaced by React Native components (div == View, span == Text, img == Image).

Also, “real” CSS isn’t supported, but RN does support styling through inline styles. Flexbox layout and most normal styles like color and backgroundColor and the like will work. I noticed that some shorthand properties don’t work either: something like border: 1px solid red would instead be described explicitly, like { borderWidth: 1, borderColor: 'red' }.

Expo

Expo is a tool, and a platform, for building apps with React Native.

One nice thing about using Expo is that it lets you deploy apps to your phone without signing up for an Apple Developer subscription (for us iPhone people anyway). I’ve read that you actually can get an app onto your phone without the Apple Developer subscription, but it requires messing with Xcode and that wasn’t something I wanted to tackle this evening.

The other big bonus with Expo is that it comes with the Expo SDK which gives you a bunch of native APIs out of the box – like the accelerometer, compass, location, maps, and the most important one for this project: the camera.

Install Expo on Computer and Phone

I used the Expo command line but they also provide an IDE. If you want to follow along, install the Expo commandline tool with NPM or Yarn:

npm install -g exp

(Yes, it’s exp, not expo).

Then you need to install the Expo app on your phone, and you can find that in the App Store / Play Store.

Create the Project

With the command line tool installed, run this command to create a new project:

exp init grillview

It’ll prompt for a template: choose the “blank” one.

Then follow the provided instructions to start it up:

$ cd grillview
$ exp start

At some point it will ask you to create an account with Expo. This is needed in order to deploy the app from your computer to Expo’s servers. Then the Expo app on your phone can load your app.

Follow the instructions to send the URL to your device, or just type it in. Expo also lets you run this in a simulator, but I thought it’d be more fun with the real phone so that’s what I did.

Once you’ve got it open on your phone, the developer experience is pretty nice. Change code, save, and the app will live reload (auto-refresh) automatically – just like developing locally with Create React App. There’s a small delay as it downloads the JS bundle each time. You can also enable hot reloading (no refresh) from Expo’s developer menu, which you can bring up if you shake your phone. Gently. Don’t throw it through a window or whatever.

File Structure

Expo sets us up with an App.js file in the root of the project, which exports the App component. Here’s the entirety of the generated app:

import React from 'react';
import { StyleSheet, Text, View } from 'react-native';

export default class App extends React.Component {
  render() {
    return (
      <View style={styles.container}>
        <Text>Open up App.js to start working on your app!</Text>
      </View>
    );
  }
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  },
});

You’ll notice there’s a Text component inside the View. Try leaving the “Open up App.js…” text alone, but removing the wrapping Text component and see what happens.

If you peek inside package.json you’ll see this line:

"main": "node_modules/expo/AppEntry.js"

This is what kicks off our app, and it expects to find an App.js file that exports the root component.

If you wanted to reorganize the project structure, the first step would be to copy AppEntry.js into your project and modify it accordingly, but we’re gonna stick with defaults on this one.

Using the Camera

Permission Granted

To take pictures, Expo provides a Camera component. But before we can use it, we need to ask for permission.

Open up App.js, add a new import for the camera and permissions objects, and change the component to look like this:

import React from 'react';
import { StyleSheet, Text, View } from 'react-native';

// add this:
import { Camera, Permissions } from 'expo';

export default class App extends React.Component {
  // initialize state
  state = {
    cameraPermission: null
  };

  render() {
    const { cameraPermission } = this.state;

    // Render one of 3 things depending on permissions
    return (
      <View style={styles.container}>
        {cameraPermission === null ? (
          <Text>Waiting for permission...</Text>
        ) : cameraPermission === false ? (
          <Text>Permission denied</Text>
        ) : (
          <Text>yay camera</Text>
        )}
      </View>
    );
  }
}

Now the app should render “Waiting for permission…” and just be stuck there, since we’re not doing anything yet.

We’ll ask for permission in the componentDidMount lifecycle hook. Add that in:

export default class App extends React.Component {
  ...

  componentDidMount() {
    Permissions.askAsync(Permissions.CAMERA)
      .then(({ status }) =>
        this.setState({
          cameraPermission: status === 'granted'
        })
      );
  }

  render() {
    ...
  }
}

When you save, and the app refreshes, you’ll see a dialog asking for camera permission. And once you allow it, the text should change.

If this is your first time using Expo, it will probably ask for permissions for Expo itself before asking about your app.

Live Camera View

Now let’s replace the “yay camera” text with a component that will render the camera. Add a new component to App.js named Autoshoot. For now, it will just render the Camera, and we can make sure everything is working.

class Autoshoot extends React.Component {
  render() {
    return (
      <View style={{ flex: 1, width: '100%' }}>
        <Camera
          style={{ flex: 1 }}
          type={Camera.Constants.Type.back}
          ref={cam => this.camera = cam}>
        </Camera>
      </View>
    );
  }
}

We’re putting the Camera inside a View, giving both flex: 1 so they take up the entire height, and the width: '100%' so the View takes the entire screen (without the width set, you’ll see a blank screen: try it!).

We’re using the “better” camera (on iPhone anyway – the back one, as opposed to the front selfie one).

And we’re saving a ref to this camera component, because that’s how we’ll trigger the shutter in the next section.

Now that this component exists, go back to the render method of App and replace the “yay camera” element with this Autoshoot component:

render() {
  const { cameraPermission } = this.state;

  // Render one of 3 things depending on permissions
  return (
    <View style={styles.container}>
      {cameraPermission === null ? (
        <Text>Waiting for permission...</Text>
      ) : cameraPermission === false ? (
        <Text>Permission denied</Text>
      ) : (
        <Autoshoot/>
      )}
    </View>
  );
}

Finally: Taking a Picture

To trigger the shutter, we’ll put a “button” of sorts inside the Camera component. Unfortunately Camera doesn’t support the onPress prop (the one that gets triggered when you tap it), so we’ll import TouchableOpacity and render one of those inside.

At the top, import it:

import { StyleSheet, Text, View, TouchableOpacity } from 'react-native';

And in Autoshoot’s render, insert the component as a child of Camera:

render() {
  const { photo } = this.state;

  return (
    <Camera
      style={{ flex: 1 }}
      type={Camera.Constants.Type.back}
      ref={cam => this.camera = cam}>
      <TouchableOpacity
        style={{ flex: 1 }}
        onPress={this.takePicture}/>
    </Camera>
  );
}

Then we need a takePicture method, which we can insert above render:

takePicture = () => {
  this.camera.takePictureAsync({
    quality: 0.1,
    base64: true,
    exif: false
  }).then(photo => {
    this.setState({ photo });
  })
}

At this point, the app will behave the same: when you tap the screen, the app will still display the camera (and hopefully no errors).

Next, we need to initialize the state of photo at the top:

class Autoshoot extends React.Component {
  state = {
    photo: null
  }

  ...
}

Then inside render, we’ll either render the photo (if there is one) or the camera:

render() {
  const { photo } = this.state;

  return (
    <View style={{ flex: 1, width: '100%' }}>
     {photo ? (
       <ImageBackground
         style={{ flex: 1 }}
         source={{ uri: photo.uri }} />
     ) : (
       <Camera
         style={{ flex: 1 }}
         onPress={this.takePicture}
         type={Camera.Constants.Type.back}
         ref={cam => this.camera = cam}>
         <TouchableOpacity
           style={{ flex: 1 }}
           onPress={this.takePicture}/>
       </Camera>
     )}
    </View>
  );
}

We’re using the ImageBackground component for the first time here too, so make sure to import that at the top from ‘react-native’:

import { StyleSheet, Text, View, TouchableOpacity, ImageBackground } from 'react-native';

There we go! Now you can tap the screen to take a picture, and it will stay up on the screen.

Here’s a quick exercise for you:

Make it so that when you tap the captured photo, the app goes back to displaying the Camera. Hint: ImageBackground doesn’t support onPress, so you’ll need to use the same trick we used with the TouchableOpacity.

Taking Photos On a Timer

We’ve got the code in place to take a picture manually – now let’s automate it.

We can do this by essentially calling takePicture on an interval. But there’s a small problem: the camera needs a bit of time to focus before it takes the shot. So what we really need is something like this:

Activate camera (screen shows live camera)
Let it focus for 3 seconds
Take a picture (screen shows still image)
Wait 27 seconds
GOTO 1

And once we get that working, we’ll insert a step “3a”: send the picture to the server. (which doesn’t exist yet, but we’ll get to that in a bit)

When Autoshoot initially renders, we’ll start a 30-second timer. Let’s create a constant for the timer, and the amount of time to focus, because we’ll need it in a few places.

const PHOTO_INTERVAL = 30000;
const FOCUS_TIME = 3000;

class Autoshoot extends React.Component {
  componentDidMount() {
    this.countdown = setTimeout(
      this.takePicture,
      PHOTO_INTERVAL
    );
  }

  componentWillUnmount() {
    clearInterval(this.countdown);
  }

  ...
}

And for testing purposes, just change the timeout to 2 seconds so we’re not waiting around all day.

When the app reloads (which you can trigger manually by shaking your device, and choosing “Reload JS Bundle”), a photo will be taken automatically. Awesome.

Start Another Timer

Now that we’re taking a photo automatically, we just need a couple more timers to have it take photos all day long.

There are a few ways to write this: we could do it with two stacked timers (one for 27 seconds, which then triggers one for 3 seconds), or we could do it with 2 simultaneous timers, or we could do it with setState callbacks.

The latter option is probably the most precise (and avoids potential race conditions), but we’ll go with the easy option: 2 simultaneous timers. With the triggers this far apart, a race condition/overlapping timers is pretty unlikely.

To make it work, replace takePicture with this implementation:

takePicture = () => {
  this.camera.takePictureAsync({
    quality: 0.1,
    base64: true,
    exif: false
  }).then(photo => {
    this.setState({ photo });

    // In 27 seconds, turn the camera back on
    setTimeout(() => {
      this.setState({ photo: null });
    }, PHOTO_INTERVAL - FOCUS_TIME);

    // In 30 seconds, take the next picture
    setTimeout(this.takePicture, PHOTO_INTERVAL);
  });
}

Now when the app refreshes, it will take pictures for infinity. (or until your battery runs out)

The Express Server

We have the React Native app taking pictures now. Let’s work on building a server to send them to.

We’re going to use Express to write a barebones server to handle two routes:

POST /: Upload a new photo
GET /: View the latest photo

For this most simple of servers, we’re just gonna create a server.js file in the root of our grillview project. React Native and Express, side-by-side. (Is this a recommended way to create Real Projects™? Nah, but this whole thing is a bit of a hack, so.).

We’ll need a couple packages to make this work, so install those now:

yarn add express body-parser

Then we can start with a barebones Express server. Create the server.js file and paste this in:

const express = require('express');
const bodyParser = require('body-parser');

const app = express();

// If your phone has a modern camera (unlike my iPhone 4S)
// you might wanna make this bigger.
app.use(bodyParser.json({ limit: '10mb' }));

// TODO: handle requests

const port = process.env.PORT || 5005;
app.listen(port);

console.log(`Grill server listening on ${port}`);

This won’t handle requests yet, but it will run. We have bodyparser.json in place to handle the POST’ed images. Now let’s add the POST request handler in place of the TODO:

// Store the single image in memory.
let latestPhoto = null;

// Upload the latest photo for this session
app.post('/', (req, res) => {
  // Very light error handling
  if(!req.body) return res.sendStatus(400);

  console.log('got photo')

  // Update the image and respond happily
  latestPhoto = req.body.photo;
  res.sendStatus(200);
});

This just accepts the image from the client and saves it in a local variable, to be returned later.

Quick warning: this is doing nothing about security. We’re blindly saving something from the client and will parrot it back, which is a recipe for disaster in a deployed app. But since I’m only running it on my local network, I’m not too worried. For a real app, do some validation of the image before saving it.

Underneath that we’ll add the GET handler that will send back the latest image:

// View latest image
app.get('/', (req, res) => {
  // Does this session have an image yet?
  if(!latestPhoto) {
    return res.status(404).send("Nothing here yet");
  }

  console.log('sending photo');

  try {
    // Send the image
    var img = Buffer.from(latestPhoto, 'base64');
    res.writeHead(200, {
      'Content-Type': 'image/png',
      'Content-Length': img.length
    });
    res.end(img);
  } catch(e) {
    // Log the error and stay alive
    console.log(e);
    return res.sendStatus(500);
  }
});

We’re creating a buffer to convert the base64 image to binary, and then sending it to the client.

And just to reiterate: this is not a secure setup. We’re assuming that the client sent us a good base64 image, but Rule 1 is “Don’t trust the client” – we should be validating the image before storing it.

That’s all we need for the server! Start it up:

node server.js

Then visit http://localhost:5005 – you should see the message “Nothing here yet”. Leave the server running in a separate command line terminal, and we’ll go work on sending images to the server.

Uploading the Pictures

Back in App.js and the Autoshoot component, we need to add a method for uploading the picture. In a larger app we might pull the API methods into a separate file and export them as individual functions – but since we only have the single call to make, we’ll put it in Autoshoot. Add this method:

uploadPicture = () => {
  return fetch(SERVER_URL, {
    body: JSON.stringify({
      image: this.state.photo.base64
    }),
    headers: {
      'content-type': 'application/json'
    },
    method: 'POST'
  })
  .then(response => response.json())
}

Here we’re using fetch (which is built into React Native) to POST the data to the server. Notice the SERVER_URL variable, which we haven’t created yet. Since this will only be working on our local network, we can hard-code that above Autoshoot:

const SERVER_URL = 'http://<your-ip>:5005/'

Replace <your-ip> with your own dev machine’s IP address. If you don’t know where to find that, Google is your friend :)

Now we’ll change takePicture to call uploadPicture, and as part of that change, we’ll pull out the timer code into a separate method because we want to call it from 2 places:

// Here's the timer code, lifted from takePicture:
queuePhoto = () => {
  // In 27 seconds, turn the camera back on
  setTimeout(() => {
    this.setState({ photo: null });
  }, PHOTO_INTERVAL - FOCUS_TIME);

  // In 30 seconds, take the next picture
  setTimeout(this.takePicture, PHOTO_INTERVAL);
}

// Take the picture, upload it, and
// then queue up the next one
takePicture = () => {
  this.camera.takePictureAsync({
    quality: 0.1,
    base64: true,
    exif: false
  }).then(photo => {
    this.setState({ photo }, () => {
      this.uploadPicture()
        .then(this.queuePhoto)
        .catch(this.queuePhoto);
    });
  });
}

Notice that I’m calling queuePhoto in both the .then and .catch handlers.

I wanted the app to keep on chugging away even if I restarted the server (which will cause failed requests), so I just made it ignore errors entirely.

During development it was helpful to add a console log in there to see why things were failing (syntax errors, etc), but I took it out once everything was working.

Time to cook some pulled pork!

With those last changes in place, the app is working!

I was excited to try it out. The next morning, I set up the thermometer and the phone. Started up the app, aaand… hmm, there’s no good place to put the phone.

I could’ve just put the phone and the thermometer on the ground. That’s what I should’ve done. What a reasonable person would do.

7am Dave did not do that. He grabbed an old board, cut 2 pieces of scrap wood, and fashioned it together into a little shelf leaned against the house.

“Carpentry.” It has pocket screws. Why? I have no idea.

As for the app?

It performed admirably. Mostly. It only crashed a few times.

It turned out to be pretty useful, and saved me a bunch of running up and down the stairs to check the temperature. A+++ would build again.

And the pulled pork was delicious.

Takeaways

I think it’s important to work some fun into programming projects. Give yourself permission to build something that already exists, if only to learn how to build it yourself. It doesn’t have to be a big serious project, or a perfect portfolio piece.

And on that note, don’t be afraid to hack things together. It’s a fun project! Write some terrible code that you know is terrible. Don’t stress so much about perfect abstractions and Best Practices and feeling like you have to incorporate every new library and tool. It’ll be fine. You can always refactor it when you write the blog post ;)

Recipes, Tools, Code…

You can get the full code for this project on Github.

I followed Amazing Ribs’s Perfect Pulled Pork recipe.

I used a Weber 22” Grill with a Slow n’ Sear (evidently discontinued, but I see there’s a v2 which looks similar).

The thermometer is a ThermoWorks DOT.

(no affiliate links, just good products)

Thanks for reading!

I have more articles on React and Redux at my blog.

Why Not To Modify React State Directly

Dave Ceddia — Fri, 01 Jun 2018 18:19:48 +0000

Everybody says don’t do it. Never mutate state directly, always call setState.

But why, though?

If you’ve tried it out, you might’ve noticed nothing bad happened. If you modify state directy, call this.setState({}) or even this.forceUpdate(), then everything might appear to be just fine.

this.state.cart.push(item.id);
this.setState({ cart: this.state.cart });
// renders like normal! maybe?

This is a bad idea for two reasons (even though it would work in this example, and many others).

(other patterns to avoid are things like this.state.something = x and this.state = x)

Mutating state directly can lead to odd bugs, and components that are hard to optimize. Here’s an example.

As you may already know, a common way to tune a React component for performance is to make it “pure,” which causes it to only re-render when its props change (instead of every time its parent re-renders). This can be done automatically by extending React.PureComponent instead of React.Component, or manually by implementing the shouldComponentUpdate lifecycle method to compare nextProps with current props. If the props look the same, it skips the render, and saves some time.

Here is a simple component that renders a list of items (notice that it extends React.PureComponent):

class ItemList extends React.PureComponent {
  render() {
    return (
      <ul>
        {this.props.items.map(item => <li key={item.id}>{item.value}</li>)}
      </ul>
    );
  }
}

Now, here is a tiny app that renders the ItemList and allows you to add items to the list – the good way (immutably), and the bad way (by mutating state). Watch what happens.

class App extends Component {
  // Initialize items to an empty array
  state = {
    items: []
  };

  // Initialize a counter that will increment
  // for each item ID
  nextItemId = 0;

  makeItem() {
    // Create a new ID and use
    // a random number as the value
    return {
      id: this.nextItemId++,
      value: Math.random()
    };
  }

  // The Right Way:
  // copy the existing items and add a new one
  addItemImmutably = () => {
    this.setState({
      items: [...this.state.items, this.makeItem()]
    });
  };

  // The Wrong Way:
  // mutate items and set it back
  addItemMutably = () => {
    this.state.items.push(this.makeItem());
    this.setState({ items: this.state.items });
  };

  render() {
    return (
      <div>
        <button onClick={this.addItemImmutably}>
          Add item immutably (good)
        </button>
        <button onClick={this.addItemMutably}>Add item mutably (bad)</button>
        <ItemList items={this.state.items} />
      </div>
    );
  }
}

Try it out!

Click the immutable Add button a few times and notice how the list updates as expected.

Then click the mutable Add button and notice how the new items don’t appear, even though state is being changed.

Finally, click the immutable Add button again, and watch how the ItemList re-renders with all the missing (mutably-added) items.

This happens because ItemList is pure, and because pushing a new item on the this.state.items array does not replace the underlying array. When ItemList is asked to re-render, it will notice that its props haven’t changed and it will not re-render.

Recap

So there you go: that’s why you shouldn’t mutate state, even if you immediately call setState. Optimized components might not re-render if you do, and the rendering bugs will be tricky to track down.

Instead, always create new objects and arrays when you call setState, which is what we did above with the spread operator. Learn more about how to use the spread operator for immutable updates.

Why Not To Modify React State Directly was originally published by Dave Ceddia at Dave Ceddia on June 01, 2018.

CodeProject

Where to Initialize State in React

Dave Ceddia — Thu, 29 Mar 2018 14:08:13 +0000

Ahh, the many ways of initializing state… It can be confusing. Do you put the state = {...} directly inside the class, or do you write a constructor and say this.state = { ... } inside the constructor? And do you need to have a constructor at all?

2 Ways to Initialize State

There are two ways to initialize state in a React component: inside the constructor, and directly inside the class. Here are a couple examples.

Inside the Constructor

Initializing state inside the constructor looks like this:

class App extends React.Component {
  constructor(props) {
    // Required step: always call the parent class' constructor
    super(props);

    // Set the state directly. Use props if necessary.
    this.state = {
      loggedIn: false,
      currentState: "not-panic"
      someDefaultThing: this.props.whatever
    }
  }

  render() {
    // whatever you like
  }
}

When the component class is created, the constructor is the first method called, so it’s the right place to initialize everything – state included. The class instance has already been created in memory, so you can use this to set properties on it.

This is the one place where it is acceptable to have this.state on the left side of an equal sign. Everywhere else, you should always use this.setState instead of doing this.state.whatever = ... – that way, React will know that you’ve changed something, and it can re-render the component.

One important thing to note when you write a constructor is to make sure to call the parent class’ constructor: the super(props) line in the example above. The default constructor (provided by JS when you create a class) automatically calls super with any arguments passed in.

By writing your own constructor, you’re overriding that default behavior, and unless you call super yourself, it could lead to bugs if the parent needed to do some initialization.

Is a constructor required?

You aren’t required to write one, because JS provides a default constructor. To see how this works, try running these 3 lines in your browser’s console:

class Parent { constructor(arg) { console.log('constructing Parent with', arg) } }
class Child extends Parent {}
new Child(5);

Notice how it prints “constructing Parent with 5” when you create a new Child, even though Child has no explicitly-defined constructor, and doesn’t explicitly call the parent’s with super(arg). This super call is handled by JS automatically when you don’t define your own constructor.

Directly Inside the Class

The second way to initialize state is directly inside the class definition, using a class property. Here’s what that looks like:

class App extends React.Component {
  state = {
    loggedIn: false,
    currentState: "not-panic",
    someDefaultThing: this.props.whatever
  }

  render() {
    // whatever you like
  }
}

Nice and clean! A couple things to note here:

There’s no constructor
The state property is referenced directly. It’s not this.state, just state.
The scope is inside the class, but not inside a method.
You can still refer to this.props (and this.context).
This is a class instance property, as opposed to a static one, which you might use for propTypes (e.g. static propTypes = {...}).

As I’m writing this, the class property syntax is a Stage 3 proposal so it’s not part of the official JS spec yet. To use it, you’ll need to enable Babel’s class properties transform.

But! If you’re using Create React App to bootstrap your projects, it already has the class properties transform turned on, and you can start using this class property syntax today.

Which is better? Constructor or no?

Like all things, it’s up to you.

Me, I prefer the clean look of the class property. I don’t like the extra boilerplate of the constructor, and having to remember to call super(props) (though ESlint can remind you to do that, and Create React App’s config does that out of the box).

You may have seen event handling functions being bound in the constructor, and might think constructors are required to pull this off. I’m talking about code like this:

class Thing extends React.Component {
  constructor(props) {
    super(props);
    this.handleClick = this.handleClick.bind(this);
  }

  handleClick(event) {
    // do stuff
  }
}

Another type of syntax supported by the class properties feature can make this constructor unnecessary: you can set a property equal to an arrow function, and the arrow function inherits the this binding of the class instance so you don’t have to bind it explicitly. It looks like this:

class Thing extends React.Component {
  // This is all you need to do:
  handleClick = (event) => {
    // do stuff
  }
}

This might look at little odd at first, but you can think of it this way:

// This statement:
const add = (a, b) => console.log(a + b);

// Can be thought of as assigning an arrow function to `add`:
const add = arrowFunction;

// where `arrowFunction` is expanded to:
(a, b) => console.log(a + b)

With that in mind, take another look at the class Thing example above. Hopefully it looks a little less weird. If you still hate it, give it some time and write some more arrow functions. I had the same problem at first. Your eyes will adjust :)

Where to Initialize State in React was originally published by Dave Ceddia at Dave Ceddia on March 29, 2018.

CodeProject

What is a Redux reducer?

Dave Ceddia — Mon, 19 Mar 2018 14:08:13 +0000

reducer , n. – A word Redux made up to confuse you.

In order to write Redux code, you need to know a few things. One of those things is what a reducer is and what it does. It might seem a bit scary and foreign, but after this short article I think you’ll come to agree that it is, as the saying goes, “just a function.”

First off, where does the name “reducer” come from? Redux didn’t actually make it up (I was kidding about that). It might not seem too foreign if you’re familiar with functional programming and JavaScript’s Array.reduce function. And if you know Array.reduce, you know that it takes a function (one might call it a “reducer” function) that has the signature (accumulatedValue, nextItem) => nextAccumulatedValue.

Array.reduce is like a sister to Redux

If you aren’t yet familar with Array.reduce, here’s what’s up:

JavaScript’s Array has a built-in function called reduce.

(Technically I should be writing it as Array.prototype.reduce, because it is a function on array instances, not on the capital-A Array constructor.)

It takes a function as an argument, and it calls your provided function once for each element of the array, similar to how Array.map works (or a for loop, for that matter). Your function gets called with 2 arguments: the last iteration’s result, and the current array element. This will make more sense with an example:

var letters = ['r', 'e', 'd', 'u', 'x'];

// `reduce` takes 2 arguments:
// - a function to do the reducing (you might say, a "reducer")
// - an initial value for accumulatedResult
var word = letters.reduce(
  function(accumulatedResult, arrayItem) {
    return accumulatedResult + arrayItem;
  },
''); // <-- notice this empty string argument: it's the initial value

console.log(word) // => "redux"

In this example, the reducer will get called 5 times (because there are 5 elements in the array). The calls go like this:

first called with ('', 'r') => returns 'r'
- the empty string '' comes from the 2nd argument to reduce, and the 'r' is the first element of the array
then ('r', 'e') => returns 're'
- the ‘r’ comes from the previous return value, and ‘e’ is the next element of the array
then ('re', 'd') => returns 'red'
- the ‘re’ is the previous return value, and ‘d’ is the third array element
then ('red', 'u') => returns 'redu'
- by now you are sensing a pattern
then ('redu', 'x') => returns 'redux'
- the pattern is all too clear now

The last return value, 'redux', is returned as the final result and stored in the word variable.

Redux Reducers

Now that you know how Array.reduce works, I can tell you that Redux is basically a fancy Array.reduce function (ok ok that’s a huge oversimplification, but bear with me).

A Redux reducer function has this signature:

(state, action) => newState

As in: it takes the current state, and an action, and returns the newState. Looks a lot like the signature of an Array.reduce reducer, eh? Remember:

(accumulatedValue, nextItem) => nextAccumulatedValue

Plainly speaking, a Redux reducer gets to decide how each action affects the state. Let’s look at an example one:

function wordReducer(state = '', action) {
  switch(action.type) {
    case 'ADD_LETTER':
      return state + action.letter;
    case 'RESET':
      return '';
    default:
      return state;
  }
}

Quick quiz: is there any Redux-specific code in here? Anything that depends on the Redux library to work? Go ahead, think it over, I’ll wait.

…

Answer: Nope! This is a plain old function. Sure, it takes (state, action) arguments and returns a new state. And it expects action to look something like {type: 'ADD_LETTER', letter: 'r'}. But none of that is particularly bound to Redux.

How it Works

But anyway, what does it actually do? Let’s try calling it with a few things and see what it returns.

let state = '';
console.log(wordReducer(state, {type: 'ADD_LETTER', letter: 'y'}));
  // => y
console.log(wordReducer(state, {type: 'ADD_LETTER', letter: 'y'}));
  // => y
console.log(wordReducer(state, {type: 'ADD_LETTER', letter: 'y'}));
  // => y

First: notice that wordReducer does not remember anything. It holds no state within.

let state = '';
console.log(wordReducer(state, {type: 'ADD_LETTER', letter: 'a'}));
  // => a
console.log(wordReducer(state, {type: 'ADD_LETTER', letter: 'b'}));
  // => b
console.log(state)
  // => ''

Next: notice that wordReducer does not change the state. It merely returns a new one. It treats state as immutable. This is important because, by updating state in an immutable way, Redux is able to tell which pieces of state changed, and optimize how your app is re-rendered.

One more thing:

console.log(wordReducer(undefined, {type: 'UNHANDLED'}));
  // => ''
console.log(wordReducer('existing state', {type: 'UNHANDLED'}));
  // => 'existing state'

Notice that the reducer has an initial state (when given undefined, it returns an empty string anyway), and that it has a default case that handles any actions it doesn’t understand (it returns the existing state, unchanged, when it sees such an action).

Pilot Needed

I can tell you don’t think this is very useful. What good is a function that doesn’t remember anything, and doesn’t change anything?

I’ll tell you: This function is nice because it is predictable. If you call it with the same arguments, you get the same outputs, every single time. It doesn’t matter what else has changed in your app – this function will always act the same way.

It is easy to figure out what it does by reading its code (and easy to debug!) because it’s all self-contained.

Now, the downside with a function like this is that it needs a driver of sorts. Something needs to hold on to the intermediate state, otherwise the app won’t really do much of anything.

The driver, in this case, is Redux. Specifically, the Redux store. It does something like this:

let state = '';
state = wordReducer(state, {type: 'ADD_LETTER', letter: 'a'}));
state = wordReducer(state, {type: 'ADD_LETTER', letter: 'b'}));
state = wordReducer(state, {type: 'ADD_LETTER', letter: 'c'}));

The store maintains an internal state variable. When an action is dispatched, the store calls the reducer, and replaces its internal state with whatever the reducer returned. Every time the store calls the reducer, it passes in the last-known state.

Around and around it goes: Redux sitting there waiting for an action, handling that action, updating the state, re-rendering your app, on and on forever.

So that’s it! That’s how Redux reducers work, in a nutshell. Not too bad?

What is a Redux reducer? was originally published by Dave Ceddia at Dave Ceddia on March 19, 2018.

CodeProject

Love JavaScript, but hate CSS?

Dave Ceddia — Thu, 15 Mar 2018 01:02:42 +0000

A reader wrote in to say that he was having great fun with JS and React, but when it came to styling, he was at a loss.

I love JavaScript but hate CSS. I just don’t have the patience to make something look good.

Writing code is fun. Solving problems is fun. That feeling of bliss when you finally get the computer to do what you want? Awesome.

But then: oh crap, the CSS. The app works fine but it looks terrible, and nobody will take it seriously because it doesn’t Look Like Apple(TM).

You’re Not Alone

First, I want to get this out there: if you like everything about front end development except CSS, you are not alone. I have known real actual professional UI developers with jobs that were either rubbish at styling, or could do it but they held their nose and tried to get it over with as quickly as possible.

I was in that spot a few years ago. CSS was like a magical black box where I’d type things in and it would, at least 60% of the time, spit out something that looked worse than when I started. I solved most CSS problems with Google and StackOverflow and hoping like crazy that someone had encountered my exact problem before (somehow, they usually had).

But I’ve since emerged from that dark place, and I can say that CSS (and the process of applying styles to a page) is a learnable skill. Even design is a learnable skill. And for the record, they are different skills.

Styling is not Design

The process of taking an existing visual design and writing the CSS to transform a hunk of divs to match the visual design is called styling.

The process of taking a blank canvas and coming up with a beautiful looking web site is called design.

You can be good (even very good) at one of these while simultaneously being very bad at the other.

To be a front end developer, you need some styling (CSS) skills but not necessarily design skills.

Can you avoid CSS?

I wish I could tell you that you could forget all about CSS and stay in JS land 100% of the time.

But in truth, I can’t do that. If you want to do front end development you’ll eventually need to get your hands dirty and learn you some CSS.

I can tell you from experience though that CSS sucks a lot less once you understand a little bit about it. It can even be fun! I find it satisfying when I can get a page laid out just right, and know just which parameters to tweak to make it look the way I want.

What To Do

While you can’t avoid CSS entirely, there are a few things that can make styling less sucky.

Frameworks

CSS frameworks can help you get projects started quickly, and even make up for a lack of design skills. They are usually available as installable libraries with npm/yarn, or from a CDN. Each one has its own visual style, so you’ll want to weigh the appearance of each when you make a choice. CSS frameworks help you build a nice-looking app without fussing over styles (much).

Here are some popular choices (I’m focusing on ones that work nicely with React):

Bootstrap - Extremely popular (read: lots of questions and answers on SO) and decent looking. The latest version (v4) is more modern looking, but the older ones can look a bit dated these days. You can customize it with some of your own CSS, or use free and paid themes to change the look. If you’re using React, have a look at react-bootstrap for a bunch of pre-made components like modal dialogs, popovers, forms, etc.

Semantic UI - Another popular CSS framework with React components, it has a few more components available than Bootstrap, and (I think) a more modern look.

Blueprint - I think Blueprint looks great, and to my eyes, better than Bootstrap or Semantic UI. But I haven’t used it myself. One thing that stands out with Blueprint is that it is written in (and supports) TypeScript. It doesn’t require TypeScript, but if you’re using TS it might be worth a look.

There are a ton of CSS frameworks available. Here’s a list with more that work with React.

While frameworks might help you avoid touching much CSS at all, these next two things will let you work more easily with CSS directly.

Flexbox

Flexbox layout is a modern way to lay out content using CSS, much easier to use than the floats of old (or the random stabbing in the dark you were doing 5 minutes ago). It has good browser support and makes it dead-simple to do some things that have traditionally been a big pain with CSS, like vertically centering things.

Take a look at this:

Look how nicely centered that little red square is! The outer box with the gray border just needs these 3 lines of CSS to make that happen:

display: flex; /* turn flexbox on */
justify-content: center; /* center horizontally */ 
align-items: center; /* center vertically */

If you right-click it and Inspect Element, you’ll see that it has more than those 3 lines… but they’re not responsible for centering the red box. That additional stuff gives it the gray border, makes it a square, centers it horizontally within this blog post (margin: 0 auto), and the bottom margin gives it some breathing room from the text below.

CSS Tricks has a great Complete Guide to Flexbox if you’re interested in learning more. I suggest checking it out! Flexbox really helped me get a grip on CSS and it’s my go-to tool for solving most layout problems now.

CSS Grid

Grid is an even more modern way to do layout, and more powerful than flexbox. It can handle 2 dimensions (rows and columns) whereas flexbox is better at doing one direction or the other. Browser support is pretty good. Accoding to CSS Tricks:

As of March 2017, most browsers shipped native, unprefixed support for CSS Grid: Chrome (including on Android), Firefox, Safari (including on iOS), and Opera. Internet Explorer 10 and 11 on the other hand support it, but it’s an old implementation with an outdated syntax. The time to build with grid is now!

As I write this, I have only barely fiddled around with CSS grid for layout. Being more powerful than flexbox, it’s a bit more complex, and I’ve found flexbox suits my needs well enough most of the time. It’s on my list to learn though!

You can read CSS Tricks’ Complete Guide to CSS Grid to learn more.

A Logical Approach

This is sort of a bonus meta “strategy” for dealing with CSS. As much as you can, try to avoid the random stabbing in the dark and copying-and-pasting from StackOverflow to get your layouts looking right.

Try taking a more methodical approach.

get the item into position (flexbox, grid, or maybe absolutely positioned inside a relative container)
set its margins and padding
set the border
set a background color
then draw the rest of the owl - add box shadows, set :hover/:active/:focus states, etc.

In some ways, software engineering principles like DRY (Don’t Repeat Yourself) and the Law of Demeter can apply to styling elements on a page. As an example, consider this layout for a user’s message with their avatar:

Notice that everything is 20 pixels away from the edges of the box. One way to achieve this would be to set the margin of both elements in the box to 20px.

But that has some downsides. First off, there’s repetition: what happens if that margin needs to change? Gotta change it in 2 places!

Secondly, shouldn’t it be the box’s “responsibility” to determine how far inset its elements are, rather than leaving it up to each element to decide its own distance from an edge?

A better way to do this layout would be to set the box’s padding to 20px, so then the contents can be blissfully unaware of where they need to be. This also makes it easier to add new elements inside the box too – you don’t need to explicitly tell each element where to place itself.

This is a tiny example just to illustrate the point, which is that a bit of forethought and a logical approach can make styling go much more smoothly.

Action Steps!

Find 3 layouts to copy. These could be small elements of sites you use (a single tweet, a Pinterest card, etc) or they could be physical things like a credit card or a book cover.
Read the Complete Guide to Flexbox.
Use flexbox to create the layouts you picked in Step 1.

Love JavaScript, but hate CSS? was originally published by Dave Ceddia at Dave Ceddia on March 15, 2018.

CodeProject

Where and When to Fetch Data With Redux

Dave Ceddia — Fri, 02 Feb 2018 13:19:57 +0000

If a component needs data in order to render, and you want to fetch that data with Redux and keep it in the Redux store, when is the best time to make that API call?

tl;dr – Kick off the action in the componentDidMount lifecycle hook

How This Works, in Code

Let’s imagine you want to display a list of products. You’ve got a backend API that answers to GET /products, so you create a Redux action to do the fetching:

productActions.js

export function fetchProducts() {
  return dispatch => {
    dispatch(fetchProductsBegin());
    return fetch("/products")
      .then(handleErrors)
      .then(res => res.json())
      .then(json => {
        dispatch(fetchProductsSuccess(json.products));
        return json.products;
      })
      .catch(error => dispatch(fetchProductsFailure(error)));
  };
}

// Handle HTTP errors since fetch won't.
function handleErrors(response) {
  if (!response.ok) {
    throw Error(response.statusText);
  }
  return response;
}

Side note: fetch() does not throw HTTP errors. This is really confusing if you’re used to something like axios. Read here for more about fetch and error handling.

Redux actions that fetch data will typically be written with begin/success/failure actions surrounding the API call. This isn’t a requirement, but it’s useful because it lets you keep track of what’s happening – say, by setting a “loading” flag true in response to the Begin action, and then false after Success or Error. Here’s what those actions look like:

productActions.js

export const FETCH_PRODUCTS_BEGIN = 'FETCH_PRODUCTS_BEGIN';
export const FETCH_PRODUCTS_SUCCESS = 'FETCH_PRODUCTS_SUCCESS';
export const FETCH_PRODUCTS_FAILURE = 'FETCH_PRODUCTS_FAILURE';

export const fetchProductsBegin = () => ({
  type: FETCH_PRODUCTS_BEGIN
});

export const fetchProductsSuccess = products => ({
  type: FETCH_PRODUCTS_SUCCESS,
  payload: { products }
});

export const fetchProductsError = error => ({
  type: FETCH_PRODUCTS_FAILURE,
  payload: { error }
});

And then we’ll have the reducer save the products into the Redux store when it receives the FETCH_PRODUCTS_SUCCESS action. It’ll also set a loading flag to true when the fetch begins, and false when it finishes or fails.

productReducer.js

import {
  FETCH_PRODUCTS_BEGIN,
  FETCH_PRODUCTS_SUCCESS,
  FETCH_PRODUCTS_FAILURE
} from './productActions';

const initialState = {
  items: [],
  loading: false,
  error: null
};

export default function productReducer(state = initialState, action) {
  switch(action.type) {
    case FETCH_PRODUCTS_BEGIN:
      // Mark the state as "loading" so we can show a spinner or something
      // Also, reset any errors. We're starting fresh.
      return {
        ...state,
        loading: true,
        error: null
      };

    case FETCH_PRODUCTS_SUCCESS:
      // All done: set loading "false".
      // Also, replace the items with the ones from the server
      return {
        ...state,
        loading: false,
        items: action.payload.products
      };

    case FETCH_PRODUCTS_ERROR:
      // The request failed, but it did stop, so set loading to "false".
      // Save the error, and we can display it somewhere
      // Since it failed, we don't have items to display anymore, so set it empty.
      // This is up to you and your app though: maybe you want to keep the items
      // around! Do whatever seems right.
      return {
        ...state,
        loading: false,
        error: action.payload.error,
        items: []
      };

    default:
      // ALWAYS have a default case in a reducer
      return state;
  }
}

Finally, we just need to pass the products into a ProductList component that will display them, and also be responsible for kicking off the data fetching.

ProductList.js

import React from "react";
import { connect } from "react-redux";
import { fetchProducts } from "productActions";

class ProductList extends React.Component {
  render() {
    if (error) {
      return <div>Error! {error.message}</div>;
    }

    if (loading) {
      return <div>Loading...</div>;
    }

    return (
      <ul>
        {products.map(product =>
          <li key={product.id}>{product.name}</li>
        )}
      </ul>
    );
  }
}

const mapStateToProps = state => ({
  products: state.products.items,
  loading: state.products.loading,
  error: state.products.error
});

export default connect(mapStateToProps)(ProductList);

But It Will Render Twice!

This is a really common concern. And yes, it will render more than once.

It will render in an empty state, then re-render in a loading state, and then re-render again with products to show. The horror! 3 renders! (you could get it down to 2 if you skip straight to the “loading” state)

You may be worried about “unnecessary” renders because of performance, but don’t be: single renders are very fast. If you’re working on an app where they are slow enough to notice, do some profiling and figure out why that’s the case.

Think of it this way: the app needs to show something when there are no products, or when they’re loading, or when there’s an error. You probably don’t want to just show a blank screen until the data is ready. This gives you an easy opportunity to make those decisions.

But The Component Shouldn’t Have to Fetch!

From an architecture standpoint, it would be nicer if there was a parent “thing” (component or function or router or whatever) that automatically fetched data before it loaded the components. Then components could be blissfully unaware of any dirty API nonsense; they could simply wait around to be handed data on a silver platter. What a life!

There are ways to fix this, but as with everything, there are tradeoffs. Magic data loaders are magic (harder to debug, harder to remember how/when/why they work). They might require more code instead of less.

Many Ways To Skin This Cat

There are many many ways to factor this code. There is no “best way,” because these things exist on a spectrum, and because the “best” for one use case may be the “worst” for another.

“Fetch the data in componentDidMount” is not the one true way, but it’s simple, and it gets the job done.

If you don’t like the idea of doing it this way, though, here are some things you could try:

Move the API call out of the Redux action and into an api module, and call it from the action. (better separation of concerns)
Have the component call the API module directly, and then have it dispatch the action when that data is returned, like Dan Abramov shows in this video.
Use a library like redux-dataloader or redux-async-loader or one of the other libraries from Mark Erikson’s list of data fetching libs
Make a wrapper component to do the fetching – in the above example, that might be called ProductListPage. Then the “Page” takes care of fetching, and the “List” just accepts data and renders it.
Use recompose to pull the componentDidMount hook out into its own higher-order wrapper component

Like I said, there are a lot of ways to do this :)

Action Steps

Try implementing this yourself! Practice is the best way to learn.

If you don’t have your own backend server, just use Reddit – their URLs will return JSON if you append “.json” to the end, e.g. www.reddit.com/r/reactjs.json.

Make a tiny React + Redux app that displays the posts from /r/reactjs.

Where and When to Fetch Data With Redux was originally published by Dave Ceddia at Dave Ceddia on February 02, 2018.

CodeProject

Immutable Updates in React and Redux

Dave Ceddia — Wed, 29 Nov 2017 14:11:06 +0000

How do you update state when you are not allowed to change it?

Immutability is kind of hard to wrap your head around at first. It seems like a paradox. Changing the data without changing the data? Huh?

On top of that, writing code to do immutable state updates is tricky. Below, you will find a few common patterns.

Try them out on your own, whether in the browser developer console or in a real app. Pay particular attention to the nested object updates, and practice those. I find those to be the trickiest.

All of this actually applies to React state too, so the things you learn in this guide will apply whether you use Redux or not.

Finally, I should mention that some of this code can become easier to write by using a library like Immutable.js, though it comes with its own tradeoffs. If you recoil at the syntax below, check out Immutable.js.

The Spread Operator

These examples make heavy use of the spread operator for arrays and objects. It’s represented by ... and when placed before an object or array, it unwraps the children within.

// For arrays:
let nums = [1, 2, 3];
let newNums = [...nums]; // => [1, 2, 3]
nums === newNums // => false! not the same array

// For objects:
let person = {
  name: "Liz",
  age: 32
}
let newPerson = {...person};
person === newPerson // => false! not the same object

// Internals are left alone:
let company = {
  name: "Foo Corp",
  people: [
    {name: "Joe"},
    {name: "Alice"}
  ]
}
let newCompany = {...company};
newCompany === company // => false! not the same object
newCompany.people === company.people // => true!

When used as shown above, the spread operator makes it easy to create a new object or array that contains the exact same contents as another one. This is useful for creating a copy of an object/array, and then overwriting specific properties that you need to change:

let liz = {
  name: "Liz",
  age: 32,
  location: {
    city: "Portland",
    state: "Oregon"
  },
  pets: [
    {type: "cat", name: "Redux"}
  ]
}

// Make Liz one year older, while leaving everything
// else the same:
let olderLiz = {
  ...liz,
  age: 33
}

The spread operator for objects is a stage 3 draft, which means it’s not officially part of JS yet. You’ll need to use a transpiler like Babel to use it in your code. If you use Create React App, you can already use it.

Recipes for Updating State

These examples are written in the context of returning state from a Redux reducer: pretend that the state = {whatever} at the top is the state that was passed in to the reducer, and then the updated version is returned underneath.

Applying to React and setState

To apply these examples to plain React state, you just need to tweak a couple things:

return {
  ...state,
  updates here
}

// becomes:
this.setState({
  ...this.state,
  updates here
})

Here are some common immutable update operations:

Updating an Object

const state = {
  clicks: 0,
  count: 0
}

return {
  ...state,
  clicks: state.clicks + 1,
  count: state.count - 1
}

Updating a Nested Object

const state = {
  house: {
    name: "Ravenclaw",
    points: 17
  }
}

// Two points for Ravenclaw
return {
  ...state,
  house: {
    ...state.house,
    points: state.house.points + 2
  }
}

Updating an Object by Key

const state = {
  houses: {
    gryffindor: {
      points: 15
    },
    ravenclaw: {
      points: 18
    },
    hufflepuff: {
      points: 7
    },
    slytherin: {
      points: 5
    }
  }
}

// Add 3 points to Ravenclaw,
// when the name is stored in a variable
const key = "ravenclaw";
return {
  ...state,
  houses: {
    ...state.houses,
    [key]: {
      ...state.houses[key],
      points: state.houses[key].points + 3
    }
  }
}

Add an element to the beginning of an array

const array = [1, 2, 3];
const newItem = 0;
return [
  newItem,
  ...array
];

Add an element to the end of an array

const array = [1, 2, 3];
const newItem = 4;
return [
  ...array,
  newItem
];

Add an element in the middle of an array

Pro tip: Write unit tests for these things. It’s easy to make off-by-one errors.

const array = [1, 2, 3, 5, 6];
const newItem = 4;
return [ // array is new
  ...array.slice(0, 3), // first X items unchanged
  newItem,
  ...array.slice(3) // last Y items unchanged
];

Change an element in the middle of an array

This is the same pattern as adding an item, except that the indexes are different.

Pro tip: Write unit tests for these things. It’s easy to make off-by-one errors.

const array = [1, 2, "X", 4];
const newItem = 3;
return [ // array is new
  ...array.slice(0, 2), // first X items unchanged
  newItem,
  ...array.slice(3) // last Y items unchanged
];

All Done

Was this helpful? Did I miss a pattern you wanted to see? Leave a comment below.

Immutable Updates in React and Redux was originally published by Dave Ceddia at Dave Ceddia on November 29, 2017.

CodeProject

How Does Redux Work?

Dave Ceddia — Sun, 29 Oct 2017 19:49:54 +0000

After learning a bit about React and getting into Redux, it’s really confusing how it all works.

Actions, reducers, action creators, middleware, pure functions, immutability...

Most of these terms seem totally foreign.

So in this post we’re going to demystify how Redux works with a simple example. As in the last post, I’ll try to explain Redux in simple terms before tackling the terminology.

If you’re not yet sure what Redux is for or why you should use it, read this post first and then come back here.

First: Plain React State

We’ll start with an example of plain old React state, and then add Redux piece-by-piece.

Here is a counter:

And here’s the code (I left out the CSS to keep this simple, so it won’t be as pretty as the image):

import React from 'react';

class Counter extends React.Component {
  state = { count: 0 }

  increment = () => {
    this.setState({
      count: this.state.count + 1
    });
  }

  decrement = () => {
    this.setState({
      count: this.state.count - 1
    });
  }

  render() {
    return (
      <div>
        <h2>Counter</h2>
        <div>
          <button onClick={this.decrement}>-</button>
          <span>{this.state.count}</span>
          <button onClick={this.increment}>+</button>
        </div>
      </div>
    )
  }
}

export default Counter;

As a quick review, here’s how this works:

The count state is stored in the top level Counter component
When the user clicks “+”, the button’s onClick handler is called, which is bound to the increment function in the Counter component.
The increment function updates the state with the new count.
Because state was changed, React re-renders the Counter component (and its children), and the new counter value is displayed.

If you need more detail about how state changes work, go read A Visual Guide to State in React and then come back here. Seriously: if the above was not review for you, you need to learn how React state works before you learn Redux.

Quick Setup

If you’d like to follow along with the code, create a project now:

Install create-react-app if you don’t have it (npm install -g create-react-app)
Create a project: create-react-app redux-intro
Open src/index.js and replace it with this:

import React from 'react';
import { render } from 'react-dom';
import Counter from './Counter';

const App = () => (
  <div>
    <Counter />
  </div>
);

render(<App />, document.getElementById('root'));

Create a src/Counter.js with the code from the Counter example above.

Now: Add Redux

As discussed in Part 1, Redux keeps the state of your app in a single store. Then, you can extract parts of that state and plug it into your components as props. This lets you keep data in one global place (the store) and feed it directly to any component in the app, without the gymnastics of passing props down multiple levels.

Side note: you’ll often see the words “state” and “store” used interchangably. Technically, the state is the data, and the store is where it’s kept.

As we go through the steps below, follow along in your editor! It will help you understand how this works (and we’ll get to work through some errors together).

Add Redux to the project:

$ yarn add redux react-redux

redux vs react-redux

Wait – 2 libraries? “What’s react-redux,” you say? Well, I’ve kinda been lying to you (sorry).

See, redux gives you a store, and lets you keep state in it, and get state out, and respond when the state changes. But that’s all it does. It’s actually react-redux that lets you connect pieces of the state to React components. That’s right: redux knows nothing about React at all.

These libraries are like two peas in a pod. 99.999% of the time, when anyone mentions “Redux” in the context of React, they are referring to both of these libraries in tandem. So keep that in mind when you see Redux mentioned on StackOverflow, or Reddit, or elsewhere.

Last Things First

Most tutorials start by creating a store, setting up Redux, writing a reducer, and so on. Lots must happen before anything appears on screen.

I’m going to take a backwards approach, and it will take just as much code to make things appear on screen, but hopefully the motivation behind each step will be clearer.

Back to the Counter app, let’s just imagine for a second that we moved the component’s state into Redux.

We’ll remove the state from the component, since we’ll be getting that from Redux soon:

import React from 'react';

class Counter extends React.Component {
  increment = () => {
    // fill in later
  }

  decrement = () => {
    // fill in later
  }

  render() {
    return (
      <div>
        <h2>Counter</h2>
        <div>
          <button onClick={this.decrement}>-</button>
          <span>{this.props.count}</span>
          <button onClick={this.increment}>+</button>
        </div>
      </div>
    )
  }
}

export default Counter;

Wiring Up The Counter

Notice that {this.state.count} changed to {this.props.count}. This won’t work yet, of course, because the Counter is not receiving a count prop. We’re gonna use Redux to inject that.

To get the count out of Redux, we first need to import the connect function at the top:

import { connect } from 'react-redux';

Then we need to “connect” the Counter component to Redux at the bottom:

// Add this function:
function mapStateToProps(state) {
  return {
    count: state.count
  };
}

// Then replace this:
// export default Counter;

// With this:
export default connect(mapStateToProps)(Counter);

This will fail with an error (more on that in a second).

Where previously we were exporting the component itself, now we’re wrapping it with this connect function call.

What’s `connect`?

You might notice the call looks little… weird. Why connect(mapStateToProps)(Counter) and not connect(mapStateToProps, Counter) or connect(Counter, mapStateToProps)? What’s that doing?

It’s written this way because connect is a higher-order function, which is a fancy way of saying it returns a function when you call it. And then calling that function with a component returns a new (wrapped) component.

Another name for this is a higher-order component (aka “HOC”). HOCs have gotten some bad press lately, but they’re still quite useful, and connect is a good example of a useful one.

What connect does is hook into Redux, pull out the entire state, and pass it through the mapStateToProps function that you provide. This needs to be a custom function because only you will know the “shape” of the state in Redux.

connect passes the entire state as if to say, “Hey, tell me what you need out of this jumbled mess.”

The object you return from mapStateToProps gets fed into your component as props. The example above will pass state.count as the value of the count prop: the keys in the object become prop names, and their corresponding values become the props’ values. So you see, this function literally defines a mapping from state into props.

Errors Mean Progress!

If you’re following along, you will see an error like this in the console:

Could not find “store” in either the context or props of “Connect(Counter)”. Either wrap the root component in a , or explicitly pass "store" as a prop to "Connect(Counter)".

Since connect pulls data from the Redux store, and we haven’t set up a store or told the app how to find it, this error is pretty logical. Redux has no dang idea what’s going on right now.

Provide a Store

Redux holds the global state for the entire app, and by wrapping the entire app with the Provider component from react-redux, every component in the app tree will be able to use connect to access the Redux store if it wants to.

This means App, and children of App (like Counter), and children of their children, and so on – all of them can now access the Redux store, but only if they are explicitly wrapped by a call to connect.

I’m not saying to actually do that – connecting every single component would be a bad idea (messy design, and slow too).

This Provider thing might seem like total magic right now. It is a little bit; it actually uses React’s “context” feature under the hood.

It’s like a secret passageway connected to every component, and using connect opens the door to the passageway.

Imagine pouring syrup on a pile of pancakes, and how it manages to make its way into ALL the pancakes even though you just poured it on the top one. Provider does that for Redux.

In src/index.js, import the Provider and wrap the

import { Provider } from 'react-redux';

...

const App = () => (
  <Provider>
    <Counter/>
  </Provider>
);

We’re still getting that error though – that’s because Provider needs a store to work with. It’ll take the store as a prop, but we need to create one first.

Create the Store

Redux comes with a handy function that creates stores, and it’s called createStore. Yep. Let’s make a store and pass it to Provider:

import { createStore } from 'redux';

const store = createStore();

const App = () => (
  <Provider store={store}>
    <Counter/>
  </Provider>
);

Another error, but different this time:

Expected the reducer to be a function.

So, here’s the thing about Redux: it’s not very smart. You might expect that by creating a store, it would give you a nice default value for the state inside that store. Maybe an empty object?

But no: Redux makes zero assumptions about the shape of your state. It’s up to you! It could be an object, or a number, or a string, or whatever you need. So we have to provide a function that will return the state. That function is called a reducer (we’ll see why in a minute). So let’s make the simplest one possible, pass it into createStore, and see what happens:

function reducer() {
  // just gonna leave this blank for now
  // which is the same as `return undefined;`
}

const store = createStore(reducer);

The Reducer Should Always Return Something

The error is different now:

Cannot read property ‘count’ of undefined

It’s breaking because we’re trying to access state.count, but state is undefined. Redux expected our reducer function to return a value for state, except that it (implicitly) returned undefined. Things are rightfully broken.

The reducer is expected to return the state. It’s actually supposed to take the current state and return the new state, but nevermind; we’ll come back to that.

Let’s make the reducer return something that matches the shape we need: an object with a count property.

function reducer() {
  return {
    count: 42
  };
}

Hey! It works! The count now appears as “42”. Awesome.

Just one thing though: the count is forever stuck at 42.

The Story So Far

Before we get into how to actually update the counter, let’s look at what we’ve done up til now:

We wrote a mapStateToProps function that does what the name says: transforms the Redux state into an object containing props.
We connected the Redux store to our Counter component with the connect function from react-redux, using the mapStateToProps function to configure how the connection works.
We created a reducer function to tell Redux what our state should look like.
We used the ingeniously-named createStore function to create a store, and passed it the reducer.
We wrapped our whole app in the Provider component that comes with react-redux, and passed it our store as a prop.
The app works flawlessly, except the fact that the counter is stuck at 42.

With me so far?

Interactivity (Making It Work)

So far this is pretty lame, I know. You could’ve written a static HTML page with the number “42” and 2 broken buttons in 60 seconds flat, yet here you are, reading how to overcomplicate that very same thing with React and Redux and who knows what else.

I promise this next section will make it all worthwhile.

Actually, no. I take that back. A simple Counter app is a great teaching tool, but Redux is absolutely overkill for something like this. React state is perfectly fine for something so simple. Heck, even plain JS would work great. Pick the right tool for the job. Redux is not always that tool. But I digress.

Initial State

So we need a way to tell Redux to change the counter.

Remember the reducer function we wrote? (of course you do, it was 2 minutes ago)

Remember how I mentioned it takes the current state and returns the new state? Well, I lied again. It actually takes the current state and an action, and then it returns the new state. We should have written it like this:

function reducer(state, action) {
  return {
    count: 42
  };
}

The very first time Redux calls this function, it will pass undefined as the state. That is your cue to return the initial state. For us, that’s probably an object with a count of 0.

It’s common to write the initial state above the reducer, and use ES6’s default argument feature to provide a value for the state argument when it’s undefined.

const initialState = {
  count: 0
};

function reducer(state = initialState, action) {
  return state;
}

Try this out. It should still work, except now the counter is stuck at 0 instead of 42. Awesome.

Action

We’re finally ready to talk about the action parameter. What is it? Where does it come from? How can we use it to change the damn counter?

An “action” is a JS object that describes a change that we want to make. The only requirement is that the object needs to have a type property, and its value should be a string. Here’s an example of an action:

{
  type: "INCREMENT"
}

Here’s another one:

{
  type: "DECREMENT"
}

Are the gears turning in your head? Do you know what we’re gonna do next?

Respond to Actions

Remember the reducer’s job is to take the current state and an action and figure out the new state. So if the reducer received an action like { type: "INCREMENT" }, what might you want to return as the new state?

If you answered something like this, you’re on the right track:

function reducer(state = initialState, action) {
  if(action.type === "INCREMENT") {
    return {
      count: state.count + 1
    };
  }

  return state;
}

It’s common to use a switch statement with cases for each action you want to handle. Change your reducer to look like this:

function reducer(state = initialState, action) {
  switch(action.type) {
    case 'INCREMENT':
      return {
        count: state.count + 1
      };
    case 'DECREMENT':
      return {
        count: state.count - 1
      };
    default:
      return state;
  }
}

Always Return a State

You’ll notice that there’s always the fallback case where all it does is return state. This is important, because Redux can (will) call your reducer with actions that it doesn’t know what to do with. In fact, the very first action you’ll receive is { type: "@@redux/INIT" }. Try putting a console.log(action) above the switch and see.

Remember that the reducer’s job is to return a new state, even if that state is unchanged from the current one. You never want to go from “having a state” to “state = undefined”, right? That’s what would happen if you left off the default case. Don’t do that.

Never Change State

One more thing to never do: do not mutate the state. State is immutable. You must never change it. That means you can’t do this:

function brokenReducer(state = initialState, action) {
  switch(action.type) {
    case 'INCREMENT':
      // NO! BAD: this is changing state!
      state.count++;
      return state;

    case 'DECREMENT':
      // NO! BAD: this is changing state too!
      state.count--;
      return state;

    default:
      // this is fine.
      return state;
  }
}

You also can’t do things like state.foo = 7, or state.items.push(newItem), or delete state.something.

Think of it like a game where the only thing you can do is return { ... }. It’s a fun game. Maddening at first. But you’ll get better at it with practice.

All These Rules…

Always return a state, never change state, don’t connect every component, eat your broccoli, don’t stay out past 11… it’s exhausting. It’s like a rules factory, and I don’t even know what that is.

Yeah, Redux can be like an overbearing parent. But it comes from a place of love. Functional programming love.

Redux is built on the idea of immutability, because mutating global state is the road to ruin.

Have you ever kept a global object and used it to pass state around an app? It works great at first. Nice and easy. And then the state starts changing in unpredictable ways and it becomes impossible to find the code that’s changing it.

Redux avoids these problems with some simple rules. State is read-only, and actions are the only way to modify it. Changes happen one way, and one way only: action -> reducer -> new state. The reducer function must be “pure” – it cannot modify its arguments.

There are even addon packages that let you log every action that comes through, rewind and replay them, and anything else you could imagine. Time-travel debugging was one of the original motivations for creating Redux.

Where Do Actions Come From?

One piece of this puzzle remains: we need a way to feed an action into our reducer function so that we can increment and decrement the counter.

Actions are not born, but they are dispatched , with a handy function called dispatch.

The dispatch function is provided by the instance of the Redux store. That is to say, you can’t just import { dispatch } and be on your way. You can call store.dispatch(someAction), but that’s not very convenient since the store instance is only available in one file.

As luck would have it, the connect function has our back. In addition to injecting the result of mapStateToProps as props, connect also injects the dispatch function as a prop. And with that bit of knowledge, we can finally get the counter working again.

Here is the final component in all its glory. If you’ve been following along, the only things that changed are the implementations of increment and decrement: they now call the dispatch prop, passing it an action.

import React from 'react';
import { connect } from 'react-redux';

class Counter extends React.Component {
  increment = () => {
    this.props.dispatch({ type: 'INCREMENT' });
  }

  decrement = () => {
    this.props.dispatch({ type: 'DECREMENT' });
  }

  render() {
    return (
      <div>
        <h2>Counter</h2>
        <div>
          <button onClick={this.decrement}>-</button>
          <span>{this.props.count}</span>
          <button onClick={this.increment}>+</button>
        </div>
      </div>
    )
  }
}

function mapStateToProps(state) {
  return {
    count: state.count
  };
}

export default connect(mapStateToProps)(Counter);

The code for the entire project (all two files of it) can be found on Github.

What Now?

With the Counter app under your belt, you are well-equipped to learn more about Redux.

“What?! There’s more?!”

There is much I haven’t covered here, in hopes of making this guide easily digestible – action constants, action creators, middleware, thunks and asynchronous calls, selectors, and on and on. There’s a lot. The Redux docs are well-written and cover all that and more.

But you’ve got the basic idea now. Hopefully you understand how data flows in Redux (dispatch(action) -> reducer -> new state -> re-render), and what a reducer does, and what an action is, and how that all fits together.

I’m putting together a new course that will cover all of this and more. If you want to know when that’s available, drop your email in the box below and I’ll give you a shout.

How Does Redux Work? was originally published by Dave Ceddia at Dave Ceddia on October 29, 2017.

Forem: Dave Ceddia

Implementing a Mockup: CSS Layout Step by Step

A Small Layout Example

First Step: Identify the Pieces

Second Step: Draw Boxes Around Stuff

A Note on Semantic HTML

Default Styling of Elements

Step Three: More Boxes

How Flexbox Works

Why Flexbox Instead of Grid?

Step Four: Apply Flexbox

Direction: Row or Column?

Content Should Take More Space

margin vs padding

Separation of Concerns

Removing the List Style

Spread out the Buttons

Draw the Rest of the Owl

Icon Buttons

How to Get Better at CSS

The Path to Becoming a Front End Developer in 2019

Learning is a Puzzle

Learn in Isolation

Break it down: Full Stack React App

Learn Each Skill on Its Own

A Web Development Learning Plan

A Bit of Command Line

Version Control with Git

The Languages of the Web

Learn to Debug

Learn How The Web Works

Learn a Framework

Begin (or continue) Today!

React Project Ideas, and How to Invent Your Own

Invent Your Own Project Ideas

What Do You Want To Learn?

Minimize and Simplify

Brainstorm Project Ideas

Go Forth And Build Things

Redux vs. The React Context API

A Motivating Example

Using Redux to Improve Data Flow

connect is pure

Easy Debugging with Redux

Customize Redux with Middleware

How to Use the React Context API

Provider and Consumer are a Pair

Context Holds No State

Consumer Uses the Render Props Pattern

Provider Accepts One Value

Context API is Flexible

Turn the Consumer into a Higher-Order Component

Hold State in the Provider

Pass Actions Down Through Context

Should You Use Context, or Redux?

Perfect Pulled Pork with React Native, Expo, and Express

Grand Plans: The System Layout

React Native

Expo

Install Expo on Computer and Phone

Create the Project

File Structure

Using the Camera

Permission Granted

Live Camera View

Finally: Taking a Picture

Taking Photos On a Timer

Start Another Timer

The Express Server

Uploading the Pictures

Time to cook some pulled pork!

Takeaways

Recipes, Tools, Code…

Why Not To Modify React State Directly

Recap

Where to Initialize State in React

2 Ways to Initialize State

Inside the Constructor

Is a constructor required?

Directly Inside the Class

`connect` is pure

What’s `connect`?