Forem: Zac Haluza

An Intro to Redux

Zac Haluza — Wed, 10 Mar 2021 02:30:08 +0000

This article was originally published at haluza.dev

What you'll get out of this article:

Learn why developers use external libraries to manage state in React
Understand the fundamentals of Redux
Apply Redux concepts to a simple counter app
Learn how Redux Toolkit simplifies Redux setup

This article is for you if:

You're familiar with the basics of React
You know how to manage React state with hooks and/or state objects
You're new to state management libaries like Redux and MobX

If you're wondering why this article discusses vanilla Redux and not Redux Toolkit, please read my explanation in the afterword.

Introduction
Why Do We Need Redux?
How Does Redux Work?
Understanding Redux in an App
- Actions & Action Creators
- Reducers
- Store
- Connecting the App to the Store
Summary
Next Steps
- Read "You Might Not Need Redux"
- Build an App With Redux
- Explore Redux Toolkit
Afterword: Why This Article Uses Vanilla Redux

Introduction

State management is one of the core concepts of React. It's also one of the most complicated. This isn't necessarily because managing state in React is tricky; rather, there are so many different ways to do it!

In this article I'm going to assume that you're comfortable managing state within a component, but are relatively new to Redux.

At the simplest level, Redux lets you do two things:

Manage state from a single location in your app
Access this state anywhere in your app, without passing it from component to component

To understand why this is so important, let's take a moment to imagine we've been hired to create a new hit app.

Why Do We Need Redux?

Our product manager wants us to build an app called Counter. It's fast, sleek, and consists of a single component. (Think of how small the bundle size is!)
Check out the code below, or click here to view this as an app on CodeSandbox.

export default function App() {
  const [count, setCount] = useState(0);
  const increment = () => {
    setCount((prevCount) => prevCount + 1);
  };
  const decrement = () => {
    setCount((prevCount) => prevCount - 1);
  };
  const reset = () => {
    setCount(0);
  };
  return (
    <div className="App">
      <h1>Counter - No Redux</h1>
      <div className="counter">
        <button onClick={decrement}>-</button>
        {count}
        <button onClick={increment}>+</button>
      </div>
      <button onClick={reset}>Reset</button>
    </div>
  );
}

Inside this tiny App component, we're creating a single count state for our counter, initializing it to 0, and defining methods to increment, decrement, and reset it.

Then we're implementing the counter inside the same component.

If your React apps are all as simple as this one, you'll never need to use a state management solution like Redux. However, I can all but guarantee that you'll work on an app in which useState or setState alone won't cut it.

Example 2: Complex Counter

Turns out our counter app was massively popular — it's time to introduce the
world to Counter 2.0!

Here's the mockup our product manager just gave us. Note that it's a little more complicated than what we were working with before:

To save you some stress, we aren't going to code this app out. Instead, I want you to think of the different types of state that we would need to manage inside this app. Off the top of my head, here are the key types of state we would need to manage:

All of the counters in the app, as well as their current values. We could store the counter values inside an array to keep track of the counters more easily.
Login-related info, such as the user's name, so we could display it in the UI.
The current color theme (light mode or dark mode)

Previously, we stored all of our state logic inside our App.js file. Now, however, our state is a little bigger. Below you'll see our current state represented as an object. Why did I use an object? Keep that question in mind as you read on.

const initialState = {
  username: '',
  counters: [0, 17],
  colorTheme: 'light',
};

Well, that doesn't seem so bad. But hold on — don't we also need to include methods to trigger state changes?

const setUsername = (username) => {
  // logic to set the username when someone logs in
}
const addCounter = () = => {
  // logic to add a counter
}
const removeCounter = (index) => {
  // logic to remove a counter at a certain index
}
const increment = (index) => {
  // logic to increment a specific counter
}
const decrement = (index) => {
  // logic to decrement a specific counter
}
const reset = (index) => {
  // logic to reset a specific counter
}

We've just defined the basic business logic for our application. We already have some problems.

Our App.js component is going to get crowded if we move it all there.
It's going to get even more crowded if we start adding more state and logic to our app.
We'll also need to pass our state and methods down to our components. And if we nest components inside other components (for example, App -> CounterContainer -> Counter), we run the risk of introducing prop drilling into our app.

Wouldn't it be easier if we had one central place to store our state and our state-related methods, like adding counters and changing the color theme? And wouldn't it also be great if we could grab state and methods directly from this central store, instead of passing them through component after component?

This is where Redux comes in.

How Does Redux Work?

Counter 2.0 shows us some very common state management issues that can occur in
React apps when they grow more complex. Redux helps solve these problems by
handling state management in a very opinionated and clearly defined flow.

Here's how Redux's "one-way data flow" works. Just soak it in — it's OK if it doesn't make sense yet.

Let's translate this image into a series of written steps. For now, let's imagine that we've implemented Redux inside a simple counter app, like Counter 1.0.

This is what happens when a user clicks on the button to increment the counter from 0 to 1.

The app dispatches an action. The action is a function called increment.
The action is sent to the store, which holds the app's state inside an object.
The store updates the state using a reducer function (more on that later).
- In this case, the count state is increased to 1.
The store sends the updated state back to the UI. The counter now displays 1 instead of 0.

Actions, stores, reducers... This is getting extremely abstract. To make these concepts more tangible, let's see an how Redux works inside a React app.

Understanding Redux in an App

Remember Counter 2.0? Our product manager decided to scrap it because it was too complicated. Now they want us to build the much simpler and much prettier Counter 3.0. Oh, and they want us to use Redux!

Here's what the finished app looks like. Before moving on, poke around inside the app and get a feel for its functionality. Inside the redux directory, you'll find some files with familiar sounding names, like reducer.js, actionCreators.js, and store.js.

We're going to explore the following concepts inside the Counter 3.0 app:

Reducers
Actions (and action creators)
Store

Let's take a look at that Redux flow diagram again. It's important to keep these concepts in mind as you explore the app.

Actions & Action Creators

Before I explain what an action or an action creator is, let's look at a simplified version of the actionCreators.js file.

export const incrementCounter = () => {
  return {
    type: 'INCREMENT_COUNTER',
  };
};

export const decrementCounter = () => {
  return {
    type: 'DECREMENT_COUNTER',
  };
};

export const resetCounter = () => {
  return {
    type: 'RESET_COUNTER',
  };
};

export const setCustomCount = (customCount) => {
  return {
    type: 'SET_CUSTOM_COUNT',
    payload: customCount,
  };
};

Here we've created functions to define four events we can trigger with our app:

Increment the count
Decrement the count
Reset the count
Set the count to a custom number

Each of these events corresponds to a button in the app.

These functions are called action creators. Each action creators returns an object called an action.

There are two basic types of actions.

The first contains only a type property. Think of it as the action's
label.

{
  type: 'INCREMENT_COUNTER';
}

The second contains a type property as well as a payload property.

{
  type: "SET_CUSTOM_COUNT",
  payload: 67
}

The name payload is an apt description. It's the value(s) we want to use when we update the state. In the case of our SET_CUSTOM_COUNT action, we're updating the count state to 67.

Why don't any of our other actions contain payloads? Simple: they don't need them. We'll see why when we learn about reducers next.

Where do we trigger our reducers? Right inside the app. Here's the code for our "increment" button:

<button onClick={() => dispatch(incrementCounter())}>+</button>

We'll discuss the dispatch method later. But in a nutshell, here's what happens when a user clicks the + button to increment the counter.

The incrementCounter function (action creator) is executed.
incrementCounter returns an object with a type property of INCREMENT_COUNTER. This object is our action.
The action is sent to the reducer.

Reducer

This is where it starts to come together.

What's the reducer? It's simply a function that controls your app's state.

It's often written as a switch statement, as is the one in this app, but that's simply a common convention, not a requirement.

Here's what our reducer looks like:

const initialState = {
  count: 0,
};

export default function counterReducer(state = initialState, action) {
  switch (action.type) {
    case 'INCREMENT_COUNTER':
      return {
        count: state.count + 1,
      };
    case 'DECREMENT_COUNTER':
      return {
        count: state.count - 1,
      };
    case 'RESET_COUNTER':
      return {
        count: 0,
      };
    case 'SET_CUSTOM_COUNT':
      return {
        count: action.payload,
      };
    default:
      return state;
  }
}

That's a lot to take in. Let's walk through this chunk of code step by step.

First, we define our initialState as an object above the reducer.
Next, the reducer function accepts two parameters: state and action.
- state - the initialState object is this parameter's default value.
- action - this refers to whatever action that was just returned by the action creator.
We create a switch statement. Inside this statement, we return an object depending on the action's type property.

If a user opens the app and chooses to increment the counter, what happens?

The app dispatches the incrementCounter action creator:

const incrementCounter = () => {
  return {
    type: 'INCREMENT_COUNTER',
  };
};

The incrementCounter action creator returns an object (an action) with a type property of INCREMENT_COUNTER.

{
  type: 'INCREMENT_COUNTER';
}

Our reducer function is invoked, accepting initialState and the action object as parameters. In pseudocode, it looks something like this:

const initialState = {
  count: 0,
};

const incrementAction = { type: 'INCREMENT_COUNTER' };

counterReducer(initialState, incrementAction);

The reducer looks at the action's type property and sees if it matches any of its cases. Bingo - we hit the INCREMENT_COUNTER case.

switch (action.type) {
  case 'INCREMENT_COUNTER':
    return {
      count: state.count + 1,
    };

  // other cases here...

  default:
    return state;
}

The reducer returns an object with a single property, count. To calculate the value, it grabs the current value of count from the current state object (which is 0 now) and adds 1 to it.

{
  count: 1;
}

Hold on — that looks a lot like our initialState object!

// Our initial state object
const initialState = {
  count: 0,
};

// The object returned by the reducer
{
  count: 1;
}

That's right. The reducer returns the updated state. In more technical terms, it replaces the previous state object with a new state object containing updated values. This is because Redux state is immutable (key interview term!). You should never directly modify your Redux state inside your reducer. Instead, you should return a brand new object, like we do here.

This updated state object is now available for our app to use. But how does our app have access to the state?

It's time to learn about the store.

Store

Here's what Counter 3.0's store looks like. Brace yourself... it's 4 lines of code.

import { createStore } from 'redux';
import counterReducer from './reducer';

const store = createStore(counterReducer);

export default store;

Still, we only need to look at one line:

const store = createStore(counterReducer);

A Redux store is simply an object that holds your app's state. Your app
should only contain one store. This is a HUGE part of what makes Redux an appealing state solution. Your store becomes a single source of truth for your app's state.

Remember the phrase "single source of truth." It's an easy way to sum up the benefits of Redux. Plus, it's another great phrase to use in interviews.

In the line of code above, Redux's createStore function takes in your reducer and uses it to construct the store object.

As your app grows more complex, you may want to create multiple reducers. If we add a to-do feature to our counter app, creating a separate toDoReducer where
we store our state and methods for our app's "to-do" functionality.

Fortunately, the Redux library provides a combineReducers function that lets you feed a multilayered reducer to your store.

We're almost there! We've built our action creators, reducer, and store. Now we just need to give our app access to the store and the state inside it.

Connecting the App to the Store

There are only two steps left:

Wrap our store around our entire app, using a special wrapper component called Provider.
Hook our components into the store with... Redux hooks!

Hang in there. This is the home stretch!

Wrapping the Store Around Our App

For these last few steps, we're going to use a few features that the React Redux library gives us. The first one is called Provider, and it's a component that we wrap around our entire app. We use it in the index.js file.

Here's the index.js file of a typical React app.

import ReactDOM from 'react-dom';

import App from './App';

const rootElement = document.getElementById('root');
ReactDOM.render(<App />, rootElement);

Here's what the same file looks like when we implement the Provider component.

import ReactDOM from 'react-dom';
import { Provider } from 'react-redux';
import store from './redux/store';

import App from './App';

const rootElement = document.getElementById('root');
ReactDOM.render(
  <Provider store={store}>
    <App />
  </Provider>,
  rootElement
);

This file suddenly got a lot more busy. The key difference is this chunk of code:

<Provider store={store}>
  <App />
</Provider>

We're providing the entire app with access to our Redux store. And this is a big thing. It means that regardless of where we are in our app — even if we're inside a component nested a dozen layers down — we can reach directly into the store without even leaving that component.

We no longer need to pass down all our state as props.

Accessing State From Inside a Component

Finally, let's look at two hooks: useSelector and useDispatch.

useSelector lets us access state values inside our store (like our count state).
useDispatch lets us "dispatch" action creators to our reducer. In other words, it lets us trigger state changes, like incrementing a counter.

Think of useSelector as a noun (e.g. count) and useDispatch as a verb (e.g. incrementCounter).

Inside our app's Counter.js file, we implement both of these hooks.

import React from 'react';
import { useSelector, useDispatch } from 'react-redux';
import {
  incrementCounter,
  decrementCounter,
  resetCounter,
} from '../redux/actionCreators';

const Counter = () => {
  const count = useSelector((state) => state.count);
  const dispatch = useDispatch();

  return (
    <div className="counter">
      <div className="counter-top">
        <button onClick={() => dispatch(decrementCounter())}>-</button>
        <p>{count}</p>
        <button onClick={() => dispatch(incrementCounter())}>+</button>
      </div>
      <button onClick={() => dispatch(resetCounter())}>Reset</button>
    </div>
  );
};

export default Counter;

At the top of the Counter component, we do two important things:

Use the useSelector hook to access the value of the count property inside our store's state object, and then save it inside a constant named count.
Invoke the useDispatch hook. The result, which we save as the constant dispatch, is a reference to the dispatch function in the Redux store.

That's all we need to work with our store!

For the useDispatch hook, we do need to import any actions we're going to use, so we can invoke it as such:

<button onClick={() => dispatch(incrementCounter())}>+</button>

We can also pass a payload to the action creator if needed:

<button onClick={() => dispatch(setCustomCount(419))}>
  Set Counter to 419
</button>

And...that's it! We've hooked our app up to our Redux store.
Here's the link to the finished app, in case you don't want to scroll all the way back up to the sandbox.

And here's the code!

For a more detailed look at useSelector and useDispatch, please refer to the React Redux documentation:

Summary

We covered a massive amount of ground in this article.

Here are the key concepts we covered:

Redux is a state management library that acts as the single source of truth for your app's state-related logic.
To implement Redux, you should implement the following in your app:
- Action creators: functions that are dispatched when your app triggers an action.
- Every action creator returns an action, an object with instructions for updating the state.
- Reducers: functions that take a state object and action as parameters, and return an object containing the app's updated state.
- Store: An object containing the entirety of your app's Redux state.
To give your app access to the store, wrap it inside a Provider component.
Use the useSelector and useDispatch hook to access state and dispatch action creators from inside any component inside your app.

If you're feeling lost, that's normal. It took me at least three separate tries to understand Redux well enough to implement it in a tiny app.

If you're having trouble with these concepts, take some time to check out the excellent explanations provided in the official Redux documentation.

Next Steps

As you're getting more comfortable with Redux, I highly recommend that you do the following:

Read "You Might Not Need Redux"

Dan Abramov is famous for creating Redux and working on Create React App and React hooks. He also wrote a very insightful article called
You Might Not Need Redux.

Redux is a great tool to have, but it's just that — a tool. You shouldn't use it if you don't need it. For smaller apps, React state may be enough. For larger apps, you may find yourself using a mixture of Redux state for data used globally and React state for more localized state.

Build an app with Redux

I want you to implement Redux in a React app. I recommend keeping the app as simple as possible; this will let you focus more on the implementation of Redux, as opposed to React itself.

Some ideas:

Build a score counter for a sports game (any sport of your choice). Give users the option to add points for either team. You can even include a winning condition (one team wins when they attain a certain number of points).
Build your own counter, using Counter 3.0 (the one we just finished going over) as a reference.
Up for a challenge? Create a simplified ecommerce app with a shopping cart that displays items as you click on them.

Feel free to use this sandbox as a reference. It's our counter from before, to include some best practices that are explained in the comments.

Explore Redux Toolkit

I mentioned Redux Toolkit at the very beginning of this post. Once you're comfortable with how Redux works, you should make an effort to move to Redux Toolkit. It simplifies a lot of the code that we just wrote. After working with vanilla Redux, you'll see the benefits immediately.

Redux Toolkit was built by the Redux.js team and is described as "the official, opinionated, batteries-included toolset for efficient Redux development" on the library's site.

As someone who cut their teeth on Redux and then moved to Redux Toolkit, trust me when I say it's the way that any team should work with Redux logic.

But wait - if Redux Toolkit is the modern Redux implementation you should use, why did we spend an entire article using vanilla Redux?

Afterword: Why This Article Uses Vanilla Redux (Instead of Redux Toolkit)

I believe that the basic Redux.js library provides the most direct way to learn how Redux works. With Redux Toolkit, you're able to leverage many new APIs that improve on Redux's functionality. However, to really grasp what these improvements are doing, and why they're so important, you need a firm understanding of how Redux works.

For instance, Redux Toolkit's createSlice API is one of my favorite features, as it removes the need to create a separate file for your action creators - it automatically generates them from your reducer. To really understand how powerful this is, you should have a solid understanding of what action creators and actions are.

In other words:

Vanilla Redux lets you learn Redux with the smallest amount of abstractions
Redux Toolkit builds on the original Redux library with more powerful APIs, and you should use it once you understand how Redux works

It's also worth mentioning that some teams with older codebases may still be using the older version of Redux, just as many React codebases will feature
class-based state instead of hooks (or a mixture of the two). While this shouldn't be your motivation for learning vanilla Redux, it's definitely a side benefit that makes you more versatile.

We've covered so much knowledge in this post. Take a break and let it sink in before you do anything else!

NPM Cheatsheet for React & Express

Zac Haluza — Sat, 28 Mar 2020 19:57:04 +0000

Whenever I start a new project, I often find myself copying my setup boilerplate from past projects. I'm sure I'm not the only one.

That's why I put together a quick cheatsheet that includes some of the most essential NPM packages to install for apps built with React and Express. Although this setup is mainly geared towards CRUD apps, you can also reference individual sections (such as the React and Redux parts).

Your preferred setup may differ from mine, so if you feel I've neglected some of your favorite NPM packages (or if you disagree with some of my choices), feel free to let me know in the comments!

Unless otherwise noted, each package can be installed as such: npm install NAME

Back End

Express Setup
OPTIONAL Express Packages
Database Setup
- PostgreSQL
- MongoDB

Front End

React Setup
- Webpack
- OPTIONAL for Webpack
- React
- OPTIONAL for React
Redux Setup
OPTIONAL for Redux

Back End

Express Setup

express
cookie-parser
- Parses cookie header and populates req.cookies with an object keyed by the cookie names.
nodemon (dev dependency)
- Restarts server after any changes are made, unlike the standard node command, which does not respond to changes made after running.
- Use in your start script like so: nodemon server.js
- Not strictly necessary, but will greatly improve your efficiency as a developer.
bcrypt
- Popular authentication tool for hashing and verifying passwords (and other information)
- Feel free to use other authentication solutions like Passport.js
Note: body-parser is deprecated. The json and url-encoded functionality can be performed with native Express methods:

  app.use(express.urlencoded({ extended: true }));
  app.use(express.json());

OPTIONAL Express Packages

concurrently
- Used to run multiple npm commands simultaneously.
- Not necessary in UNIX-like environment (e.g. Macs), which can chain commands with & (run all commands in parallel) or && (waits for the previous command to finish before running)
dotenv
- Loads environmental variables from a .env file into process.env
- Useful for keeping private info (e.g. API keys) out of public repos
- Usage example:
- Store an API key as a variable in .env.
- Add .env to your .gitignore file so the file isn’t added to your repo.
- With dotenv installed, you can access that API key variable by referencing process.env, e.g. process.env.VARIABLE

Database Setup

PostgreSQL

node-postgres
- Note: install with npm install pg!
- Lets node.js (and Express) interact with a PostgreSQL database

MongoDB

mongoose
- Robust wrapper for MongoDB that handles validation, casting, and business logic boilerplate.
- One of Mongoose's central features is its ability to create schemas for MongoDB collections.

Front End

React Setup

You can ignore this section if you're using create-react-app!

Webpack

Install all webpack-related packages as dev dependencies.

webpack
webpack-cli
- Webpack's official CLI (command line interface), providing access to many convenient commands, such as creating a new webpack configuration or migrating a project from one version to another.
webpack-dev-server
- Provides a development server for webpack, complete with live reloading
- Recommended NPM script: "start:dev": "webpack-dev-server"
@babel/core
- Babel compiler core
@babel/preset-env
- A smart preset that lets you use the lastest JavaScript features without worrying about which syntax transforms and browser polyfills your target environments require.
@babel/preset-react
- A Babel preset for all React plugins
babel-loader
- Lets you transpile files using Babel & Webpack
css-loader
- Interprets @import and url() in CSS files
style-loader
- Injects CSS into the DOM

OPTIONAL for Webpack

sass-loader
- Loads Sass/SCSS files and compiles them to CSS.
- Only necessary if you're using Sass... which you should probably use.

React

react
react-dom
- Serves as the entry point to the DOM and service renderers for React. Should be paired with the generic react package above.

OPTIONAL for React

react-router-dom
- Performs client-side routing without the need to contact the server.
- Lets you use React Router in a web setting (react-router-native is also available for React Native).
- Read more on the official site.
node-sass
- Natively and automatically compiles .scss files to CSS.
- Lets you directly use .scss files in React, which is awesome.

Redux Setup

redux
react-redux
- Note that it's necessary to also install the React-specific version of Redux, since Redux can be used with a variety of frameworks — and even Vanilla JS.

OPTIONAL for Redux

Note: Both Thunk and Saga are used to let Redux perform asynchronous actions. You can choose one or the other, although Thunk is by far the more popular option.

For Redux Thunk:

redux-thunk
- An in-depth introduction to thunks in Redux

For Redux Saga:

redux-saga
- From the official site: "You might've used redux-thunk before to handle your data fetching. Contrary to redux thunk, you don't end up in callback hell, you can test your asynchronous flows easily and your actions stay pure."

These packages may be required for Redux saga to function properly:

regenerator-runtime
- Standalone runtime for Regenerator-compiled generator and async functions
core-js
- Modular standard library for JavaScript

Did I miss anything? Let me know below!

Global Styling in React Native

Zac Haluza — Sat, 01 Feb 2020 15:59:03 +0000

If you've spent any time with React Native, you've surely noticed that all styling is done with JavaScript, not CSS.

For developers who are experienced with React (or web development in general) but not React Native, the idea of styling your components without the use of CSS classes may be frustrating.

I know it was for me.

In this post, I'm going to tackle the issue of implementing global styling in a React Native app.

Here are three ways to apply global styling to a React Native app:

Method 1: Custom Components

Method 2: Global Stylesheet

Method 3: Combine Both Approaches

Method 1: Custom Components

Since React is component-driven, the most intuitive way is to create custom components (e.g. custom text fields, custom buttons, etc.), define the styles within each component, and reuse these components throughout the app.

For example, to use a specific font color throughout the app:

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

const BlueText = props => {
  return(
    <Text style={{ ...styles.blueText, ...props.style }}>{props.children}</Text>
  );
};

const styles = StyleSheet.create({
  blueText: {
    color: 'blue'
  }
});

export default BlueText;

Note: By using the spread operator in the style property, we can overwrite any styling in this custom component when we actually implement the component.

For instance, in the app itself, we could directly overwrite the blue color property by adding some inline styling:

<BlueText style={color: 'red'}>Red Text!</BlueText>

Method 2: Global Stylesheet

Create a single stylesheet (e.g. in the constants folder) and manage all styles from inside there.

import { StyleSheet } from 'react-native';

export default StyleSheet.create({
  blueText: {
    color: 'blue'
  },
  redText: {
    color: 'red'
  }
});

Method 3: Combine Both Approaches

Since React is component-driven, it might make more sense to focus on creating custom components to manage global styles.

However, you can also use a global stylesheet in the same app for several reasons:

First, sometimes it doesn't really make sense to create a brand-new component. Adding a new style to your stylesheet (like a CSS class) and applying it to the component in question can be much more efficient in this case.
You may want to style a custom component in a slightly different way. You may want to do this multiple times, too, e.g. applying different font sizes (14, 16, 18, etc.) to buttons that are otherwise styled identically.
- In this case, it might make more sense to create smaller style objects in your global stylesheet (e.g. fontSmall, fontMed), handle the different property (or properties) in there, and then reference it in the style property of the custom component like so:

import GlobalStyles from './constants/GlobalStyles';
...
<Custom Button style={GlobalStyles.fontSmall} title='Tap Me' onPress={handlePress} />

(Remember, the styles from the global stylesheet are overwriting the default component styles because of how we used the spread operator when defining the style property in the custom component!)

How do you approach styling in React Native? Share your thoughts below!

JavaScript Unit Testing 101: Mocha & Chai ☕️

Zac Haluza — Tue, 03 Dec 2019 02:43:35 +0000

Note: this entire lesson (with testable files!) is available as a GitHub repo!

This post is a simple walkthrough and reference for anyone interested in
learning the basics of creating unit tests for JavaScript using Mocha and Chai.

Why Mocha & Chai?

In terms of technology, successful JS testing requires three things:

Testing environment/test runner
Testing framework
Assertion library Different frameworks assume different combinations of these roles. Possible combinations include…
Mocha JS (testing environment & framework) + Chai (assertion library)
Jest (all-in-one)
Jasmine (all-in-one)

This guide will use a combination of Mocha and Chai. However, these kinds of tests can also be run with other testing solutions like Jest. The approach is identical.

What's Test-Driven Development?

Test-driven development (or TDD) is a form of development in which developers write tests for their code before they actually write the code.

TDD utilizes "red-green testing": you initially write a test that will fail (red), then write and adjust your code so that the test passes (green).

Here are some of the benefits of TDD:

It’s more efficient
- You don’t have to write new tests or rewrite tests after making changes — because you’ve already written tests to anticipate the nature of your code
You write better code
- Since you plan everything out beforehand, your code is better organized
- It’s more testable — you don’t have to rewrite or refactor anything for tests
- Fewer bugs — you’ll catch them sooner, and you’ll also have regression testing built in (all the tests you’ve ever run will get re-run when you make a change)
You’ll have great code coverage
- Your tests are written to cover the general breadth of your code

Unit Testing Walkthrough

Intro

In the guide below, you'll conduct some basic unit tests. Unit tests focus on
individual parts of the code, and they're likely the most common types of tests you'll perform as a developer.

They're different from integration tests, which test whether a program or app functions properly as a whole.

Let's Get Started!

Setting up Mocha & Chai

First, set up a package.json file and import all needed dependencies.

npm init -y
npm i mocha chai --save-dev

Next, install Babel to make sure all JS is backwards compatible.

npm i @babel/core @babel/preset-env @babel/register --save-dev

Create a Babel file: .babelrc
This will make sure that Babel functions correctly.

{
    "presets": ["@babel/preset-env"]
}

Setting Up Our Tests

Create a src folder. Inside it, create two files:

.js file: This will contain the JavaScript we want to test
test.js file: This will contain our tests

Following TDD principles, the .js folder will be blank. Create a basic test
inside the test.js folder:

import { expect } from 'chai';
import { getLetterCount } from './letter-count';

describe('getLetterCount - basic functionality', () => {
  it('returns an empty object when passed an empty string', () => {
    const expected = {};
    const actual = getLetterCount('');
    expect(actual).to.deep.equal(expected);
  });
});

Running Our Tests

Now run the test. First set up the testing script in the package.json file.

...
"scripts": {
"test": "npx mocha \"src/\*_/_.test.js\" --recursive --require @babel/register"
},
...

Next, run the test.

npm test

// or "npm run test"

Now, set up a function in the .js file that will make the test pass.

export const getLetterCount = string => ({});

Refining Our Tests

Now we need to add tests until we see failure again.

import { expect } from 'chai';
import { getLetterCount } from './letter-count';

describe('getLetterCount - basic functionality', () => {
  it('returns an empty object when passed an empty string', () => {
    const expected = {};
    const actual = getLetterCount('');
    expect(actual).to.deep.equal(expected);
  });
  it('return correct letter count for a word with only one of each letter', () => {
    const expected = { c: 1, a: 1, t: 1 };
    const actual = getLetterCount('cat');
    expect(actual).to.deep.equal(expected);
  });
});

Now let’s build out our function so it passes:

export const getLetterCount = string => {
  const letters = string.split('');
  let letterCount = {};
  letters.forEach(letter => {
    letterCount[letter]
      ? (letterCount[letter] += 1)
      : (letterCount[letter] = 1);
  });
  return letterCount;
};

This is good, but let’s make sure our test passes when we use more complex words, i.e. words with more than one of a certain letter.

import { expect } from 'chai';
import { getLetterCount } from './letter-count';

describe('getLetterCount - basic functionality', () => {
  it('returns an empty object when passed an empty string', () => {
    const expected = {};
    const actual = getLetterCount('');
    expect(actual).to.deep.equal(expected);
  });
  it('return correct letter count for a word with only one of each letter', () => {
    const expected = { c: 1, a: 1, t: 1 };
    const actual = getLetterCount('cat');
    expect(actual).to.deep.equal(expected);
  });

  it('return correct letter count for words with more than one of a certain letter', () => {
    const expected = { m: 1, i: 4, s: 4, p: 2 };
    const actual = getLetterCount('mississippi');
    expect(actual).to.deep.equal(expected);
  });
});

More Practice: isPalindrome

Now test and create a function called isPalindrome. It should take two arguments and return “true” if the arguments are palindromes of one another. As a bonus, have the function return “true” even if…

the arguments contain spaces
the arguments utilize different types of capitalization (e.g. "listen" & "SILENT")

Practice utilizing the principles described above to build out tests that cover any and all relevant use cases, including edge cases. Reference the repo files if you need a hint — note that your solution and test cases may differ depending on your approach (e.g. a much simpler solution would be to utilize Lodash).

What are your thoughts on unit testing and test-driven development? Do you test your code? Share your thoughts below!

(Note: Much of the code referenced here has been adapted from the Unit Testing section of Shaun Wassel's JavaScript: Test-Driven Development (ES6) course on Lynda.)

Time Management for Self-Taught Coders

Zac Haluza — Thu, 24 Oct 2019 23:14:19 +0000

In this post, I’ll share a few effective time management strategies I’ve used through my self-taught coding journey. I’d like to hear your thoughts about time management in the comments!

A big part of being a developer is juggling priorities. This is true whether you’re working professionally or are looking for your first job.

If you’re self-taught, like me, you’ve been doing this since day one, managing your own schedule and your own curriculum.

As a self-taught (or is it self-teaching?) coder, you have to balance your time along with the new skills you need to learn and the current skills you need to solidify. And it’s really hard to get the balance right.

It’s even harder if you work a full-time job (like I do), or if you have kids, or if you have any other commitment that requires you to devote chunks of your day to non-coding priorities.

When I started coding, I tried a few different time management strategies, with varying degrees of success. I believe that each of these methods can be very helpful for up-and-coming coders, especially if you tailor and combine them to fit your personal learning style, daily routine, and skill level.

Feel free to share your own time management strategies in the comments! While this post is geared toward self-taught coders (primarily because of my own self-taught background), any thoughts on time management are welcome!

Strategy 1: Journaling

Very early into my coding journey, I started journaling my progress. After learning about the 100 Days of Code Challenge, I created a private GitHub repo and started recording my daily progress. I would write about what I learned that day, my thoughts about my progress, and anything else related to what I’d done that day.

As a beginner, I found it extremely helpful. It was really encouraging to look back a week or two and see how far I’d come since then. I’ve been coding for almost a year, and I still do my best to keep a daily journal, although it’s not my primary focus.

Strategy 2: Timekeeping

Once I had a decent grasp of the basics of HTML and CSS, I started balancing my time between coding static HTML/CSS layouts and learning the basic syntax of JavaScript. I used an app called Toggl to log my time for each activity. Toggl would tell me how long I had coded that day, and it would also tell me how much time I'd spent on each activity.

However, it wasn’t long before I had too many tasks to balance. I was building apps in React, learning Node.js and Ruby, and brushing up on my existing front-end skills. I needed a new system.

Strategy 3: Scheduling

Scheduling is by far the most effective strategy for me. I started self-scheduling a year or so ago, when I was studying for the FSOT (the Foreign Service Officer Test for entering the US State Department). I ended up passing the FSOT (although I decided against moving further ahead for a whole slew of personal and political reasons that I’ll omit here), so it certainly worked for me.

Every day, I wake up to a pre-written schedule of what I have to do that day. I don’t have to worry about timing myself. I just have to sit down in a chair and code for each block of time. It takes a lot of the worrying and guesswork out of my earlier strategies and adds a comforting framework to my studies.

Recently, I’ve split my mornings and evenings into chunks of 35 minutes. In my own variant of the Pomodoro method, I’ll work for 30 minutes and break for 5. Then I’ll switch on to the next task.

For instance, my schedule after dinner might look like this:

5:30-6:00 - Redux practice
6:05-6:35 - Dev.to blogging *(hey!)*
6:40-7:10 - Leetcode grind
7:15-7:45 - Node.js course
8:00-9:00 - Exercise (Alotting time to stretch, shower, etc.)

And so on. Yes, I eat dinner way too early.

As someone who’s actively looking for a development job, this strategy helps me make sure I’m balancing my time among all the different skills I’m working on. And as it so happens, I have a lot of skills to work on.

Your goals are probably different, so you can tweak this last strategy in a few different ways. For instance, you could increase the amount of time for each interval. You could merge time blocks if you’re working on a more intensive project, or if you’re making insane progress on one task. For instance, I had a major burst of inspiration for this post, and instead of devoting a single 30-minute block to writing, I rewrote and finished the whole thing in an hour!

Closing Thoughts

These are three time management strategies that have worked for me. Right now, I’m obsessed with scheduling, and I expect to continue refining this particular strategy with practice. I'd also love to hear about the time management strategies that have worked for you on your coding journey.

In my experience, success as a developer comes down to three main factors:

Identifying your goals
Putting in the effort
Managing your available time

These factors are symbiotic. Once you’re aware of your goals, you can decide how you want to split your time. If you’re working hard toward your goals, your objectives will adjust, and your personal schedule will also adjust. But in many ways, efficient time management is the hardest to implement properly, and it’s also the most important.

Forem: Zac Haluza

An Intro to Redux

Table of Contents

Introduction

Why Do We Need Redux?

Example 2: Complex Counter

How Does Redux Work?

Understanding Redux in an App

Actions & Action Creators

Reducer

Store

Connecting the App to the Store

Summary

Next Steps

Read "You Might Not Need Redux"

Build an app with Redux

Explore Redux Toolkit

Afterword: Why This Article Uses Vanilla Redux (Instead of Redux Toolkit)

NPM Cheatsheet for React & Express

Table of Contents

Back End

Express Setup

OPTIONAL Express Packages

Database Setup

PostgreSQL

MongoDB

Front End

React Setup

Webpack

OPTIONAL for Webpack

React

OPTIONAL for React

Redux Setup

OPTIONAL for Redux

Global Styling in React Native

Table Of Contents

Method 1: Custom Components

Method 2: Global Stylesheet

Method 3: Combine Both Approaches

Method 1: Custom Components

Method 2: Global Stylesheet

Method 3: Combine Both Approaches

JavaScript Unit Testing 101: Mocha & Chai ☕️

Why Mocha & Chai?

What's Test-Driven Development?

Unit Testing Walkthrough

Intro

Let's Get Started!

Setting up Mocha & Chai

Setting Up Our Tests

Running Our Tests

Refining Our Tests

More Practice: isPalindrome

Time Management for Self-Taught Coders

Strategy 1: Journaling

Strategy 2: Timekeeping

Strategy 3: Scheduling

Closing Thoughts