How to Manage State by Using the React Context API

When I work on large-scale applications, I use Redux for state management. However, when it comes to building smaller applications and smaller personal projects, Redux can feel cumbersome. So, what’s the best light-weight solution for state management of these smaller applications? React hooks work really well for smaller applications, but sometimes you need to share state between components, and passing that state through components via props can get a little clunky. That’s where React Context comes to the rescue.

By utilizing the React Context API, you can avoid prop drilling. It also helps keep your components cleaner and simpler.

Let’s walk through what this would look like if we’re adding React Context to an application. First, I like to organize my context within a contexts folder within the src directory. Then I create a context file where all the global state will live. For this example, let’s call the file ItemContext.js:

import { createContext, useState } from "react";
import PropTypes from "prop-types";
const ItemContext = createContext();
const ItemProvider = ({ children }) => {
  const [items, setItems] = useState([]);
  const addItem = (item) => {
    const index = items[items.length - 1].id + 1;
    item.id = index;
    const updatedItems = [...items, item];
    setItems(updatedItems);
  };
  const editItem = (id, item) => {
    const index = items.findIndex((e) => e.id === id);
    const updatedItems = [...items];
    updatedItems[index] = item;
    setItems(updatedItems);
  };
  const removeItem = (id) => {
    const updatedItems = [...items];
    setItems(updatedItems.filter((item) => item.id !== id));
  };
  const context = {
    addItem,
    editItem,
    items,
    removeItem,
  };
  return <ItemContext.Provider value={context}>{children}</ItemContext.Provider>;
};
export { ItemContext, ItemProvider };
ItemProvider.propTypes = {
  children: PropTypes.object,
};

Next, within the src directory, if you don’t already have a hooks directory, create one where we’ll add a new hook file, useItemContext.js:

import { useContext } from "react";
import { ItemContext } from "../contexts/ItemContext";
const useItemContext = () => {
  return useContext(ItemContext);
};
export default useItemContext;

This file probably looks fairly small, but it will help us cut back on copying and pasting the same lines of code when we want to reference this global state. Now, when we want to access the global state or update the state via various components, we can do so by importing the context hook:

import useItemContext from "../hooks/useItemContext";
const ExampleComponent = () => {
  const { addItem, editItem, removeItem } = useItemContext();
  const handleAdd = (item) => {
    addItem(item);
  };
  const handleRemove = () => {
    removeItem(item.id);
  };
  const handleSave = (item) => {
    editItem(item.id, item);
  };
  return (
    {Add your presentation logic here}
  );
};
export default ExampleComponent;

A Brief Overview of React.js

React is a user interface library that was developed at Facebook. React is written in different components and follows the principles of immutable data. It’s often used in enterprise applications, and it makes creating single page applications easier since they have a higher speed thanks to the virtual DOM. This means it writes to the browser DOM only when it is needed, instead of re-rendering an entire view when a change is made.

Virtual DOM

React creates an in-memory DOM where it only renders different parts of the DOM when a change occurs.

JSX

React utilizes JSX, which is a JavaScript extension syntax that allows you to quote HTML.

Babel

Babel is a transpiler that transpiles JavaScript code. It works for JSX as well as ES6 and beyond. Babel converts React’s JSX and ES6 to something the browser can use.

Components

React applications consist of a collection of components. Components are small user interface elements that display data as it changes over time. Used together, these components create entire user interfaces.

Component Lifecycle

Component lifecycles allow you to add libraries and load data at specific times. They also help improve the speed of an application, with lifecycle methods that you can override to run code a specific times in the process.

Mounting methods are called when an instance of a component is being created:

  • getInitialState()
  • componentWillMount()
  • componentDidMount()

Updating methods occur when a change happens to props or state:

  • componentWillReceiveProps()
  • shouldComponentUpdate()
  • componentWillUpdate()
  • render()
  • componentDidUpdate()

Unmounting methods are called when a component is being removed:

  • componentWillUnmount()

 

Deploying a React App to GitHub Pages

Earlier today, I worked on putting together this Sticky Note App, in an effort to get more comfortable with React.js. The application uses React.js, React DOM, and React Draggable.

After completing my application, I was about to tackle deployment with Heroku, since I’ve become pretty familiar with deploying various applications that consist of different stacks on Heroku.

However, this application was a lot simpler, so it seemed like using Heroku would have been a little excessive, especially since there’s no backend component for this application.

So I decided to tackle deploying the application via GitHub pages – which is already one of my favorite ways to deploy simple applications since I host all my repos there as well.

The first step I did, was use the create-react-app command in my terminal, where I then moved the various components of my simple React application. Then I followed the following steps:

Step 1

Edit package.json by adding a homepage

"homepage": "https://[insert username].github.io/[insert project repo name]"

Step 2

Run npm install --save-dev gh-pages

Step 3

Edit package.json by adding a predeploy and deploy script:

"scripts": {
"predeploy": "npm run build",
"deploy": "gh-pages -d build"
}

Step 4

Run: npm run deploy

And there you have it, a simple enough solution for deploying those simple enough React applications.

WDI Day Fifty-Four: Project Week 4, Part 2

Over the weekend I spent a good chunk of time working on my project. And then again all day today and tonight I alway hacked away at it. Unfortunately, I had to come to the conclusion that I need to start the whole project over tomorrow. Why, you may ask?

Well, I didn’t realize that working with HTML5 canvas and React would prove to be a bit complicated. I also realized that I don’t understand React as thoroughly as I’d like to in order to create a complete and polished product.

When it came down to it, it was more important to me that I build something new to add to my portfolio that I can be proud of. After project week, I can always explore React and the MEAN stack once more. And at that point in time, I can also take my time with my work without the pressure of a project deadline.

WDI Day Fifty-Three: Project 4 Kickoff

Today was our project 4 kickoff. The day started off with the instructors walking through project expectations and the submission process, as well as a general overview of what the project week will look like.

I decided I wanted to make a puzzle application, so the day was spent building out the core functionality in JavaScript. I also worked on planning out the wireframes and the ERD. It was pretty much a day of planning.

I’ve also decided to attempt to build the app in React with Express and Mongo DB. I’m not at all familiar with the deployment process for this particular stack, so we shall see how that goes. If I run into too many issues in the beginning, I might just build everything out with technologies I’m more familiar with so that I can have a polished app. I can always explore these more difficult frameworks later on with a different and simpler application.

WDI Day Fifty-Two: React Research

Today was more of an open-ended day. We had the option to work on a React JS lab or spend the day researching a technology of our choosing. I decided to do some serious document diving with React. Front-end frameworks are tough, especially for someone who is being exposed to them for the first time. So I did my best not to get frustrated when I wasn’t learning as quickly as I’d like to.

One thing that was pretty helpful was walking through the React Router tutorial. It gave me a better sense of how all the files are tied together in React, however, I still have a lot more practice to do before I feel fully comfortable with the framework.

WDI Day Fifty: Completed Lab & React Router and React with Backend

This morning our MEAN Stack and Web socket lab was due. I decided to work on something simple in order to help me get a better understanding of the technologies used, so I worked on a game of tic tac toe. Web sockets are pretty fascinating, and I hope to incorporate them into a few future projects.

tictactoe-screenshot

So far, the game doesn’t do everything that I’d like it to do. I haven’t used the database to persist the game data, so that’s one thing to add to my ‘to do’ list. I’d also like to add the following:

  • Prompting the user for their name
  • When users chat, having their names appear beside any remark made
  • Scoring

The rest of the day we did a code review of a React to do list application. React definitely seems a little easier than Angular to pick up, but I find myself wanting to spend a good chunk of time to building and piecing apart applications in order to get a better understanding of Angular as well as React.

WDI Day Forty-Nine: Intro to ES6 & React JS

We have a three day weekend coming up, which will be perfect for me to start working on more Angular tutorials and getting more comfortable with some of the concepts that we haven’t had much time to cover in class.

Today we reviewed some of the differences and problems solved with ES6 when compared to ES5. The class broke up into teams that worked on lesson plans for different ES6 topics. My group focused on getters and setters and template literals. Both seemed pretty interesting.

Later we reviewed React JS. From the brief introduction we received, I can tell already that I really like React’s error messages – they’re not as cryptic as Angular’s errors. Yet again, we only glazed over a few things, so this weekend I hope to delve deeper into it.