DEV Community: ryanharris.dev

Using ternaries for variable assignment in Python

ryanharris.dev — Tue, 25 May 2021 00:14:23 +0000

One of my favorite "tricks" as a programmer is to condense conditional logic (i.e. if/else blocks) into one line when assigning variables. The ternary operator makes this possible.

If you come from a JavaScript background like I do, you may have seen this done before with a question mark.

const isSuccess = data.response ? true : false

Essentially, this means if data.response is defined we should assign isSuccess the value of true. Otherwise, we'll set it to false.

Recently, I used a ternary operation in Python for the first time. While it, ultimately, works the same way I found the slight difference between languages interesting.

To recreate the snippet above in Python, we could write:

is_success = True if data.response else False

In this case, the right-side of the assignment leads with the "truthy" value, as opposed to the value we're checking. It's not a big difference, but worth noting the difference in API.

The ? operator has a special place in my heart because I've used it so much. However, Python's ternary operator syntax is probably easier to read for beginners.

React Hooks Revisited: useDebugValue

ryanharris.dev — Fri, 18 Sep 2020 12:59:41 +0000

#TIL

I'll be honest: before working on this series, I had never heard of useDebugValue (or seen it in a codebase).

Unlike the hooks we've covered thus far, useDebugValue is not intended to add functionality to your applications. Instead, as the name suggests, it is used as a debugging tool and can help developers troubleshoot issues in their custom React hooks.

We don’t recommend adding debug values to every custom Hook. It’s most valuable for custom Hooks that are part of shared libraries. ~ React docs

Though it doesn't effect your application logic in anyway, this hook can negatively effect performance in certain cases if you're not careful (more on this later).

Anatomy of useDebugValue

First things first, let's see what useDebugValue looks like in action:

In the snippet above, we've defined our own custom hook, useDate (more about these in an upcoming article). Currently, the hook fires once on App's initial render -- due to the empty dependency array -- and displays it on the page.

Note that we're also using a useDebugValue hook within useDate, which takes a single value and then displays it in the React DevTools. In the screenshot below, you can see how the snippet above would look in your browser.

Formatting useDebugValue

useDebugValue also takes an optional second argument, which can be used to format the hook's display value. In this case, the function's signature would look like this:

useDebugValue(date, date => date.toDateString().toUpperCase())

The hook works the same way it does without the second argument, however, it's output now looks like this:

Notes about the formatting function

As I mentioned in the intro, while this hook does not effect how your application works, it can effect performance if the logic within the formatter function is expensive.

Luckily, the React team built in a safeguard for this and, as it says in the documentation, the function will only be executed when you are inspecting your hooks within the dev tools.

Though use-cases for a complex formatter function may be few and far between, be careful about the logic you house within it so as to avoid unintended performance issues.

Real-world use case

Odds are you won't be using useDebugValue too much in your day to day work unless you're building custom hooks or an open source library.

Since custom hooks are built using the standard hooks provided by React, useDebugValue is primarily a nice solution to help you debug the internals of your hook implementation in the React Dev Tools pane, as opposed to adding console.log() calls everywhere.

React Hooks Revisited: useReducer

ryanharris.dev — Thu, 17 Sep 2020 13:11:50 +0000

An update on state

Throughout this series, all of the code snippets and sandboxes we've created have used useState to manage our component data. However, React offers us an additional hook to use for storing data: useReducer.

While useState allows us to store and set a single value, useReducer helps us work with more complex or structured data by allowing us to store and manipulate related values alongside one another.

Anatomy of useReducer

Like useState, useReducer returns an array with two values:

The current state
A function used to update the state

const [value, setValue] = useState(null)

const [state, dispatch] = useReducer(reducer, initialState)

The useReducer hook takes up to three arguments:

Reducer function -- This function describes how our state should be updated based on the action that was dispatched.
Initial state -- This value defines the hook's initial state and works similiarly to how we provide the useState hook a default value when instantiating it.
Initialization function -- This argument is optional and is useful for...

...calculating the initial state outside the reducer. This is also handy for resetting the state later in response to an action. ~ React docs

Difference from useState

To best illustrate the difference in how useReducer and useState update their state values, respectively, let's take a look at them side by side. The snippet below shows the code you'd need to use to instantiate and update a state value using both hooks:

// useState
const [name, setName] = useState("")
setName("Ryan")
console.log(name) // 'Ryan'

// useReducer
const initialState = {
  name: "",
}

function reducer(state, action) {
  switch (action.type) {
    case "update-name":
      return {
        name: action.value,
      }
  }
}

const [state, dispatch] = useReducer(reducer, initialState)
dispatch({ type: "update-name", value: "Ryan" })
console.log(state.name) // 'Ryan'

The first difference here is that while useState is storing a string, useReducer's initial value is an object. In this case, it has a single key (i.e. name), however, we can always add more keys to the state as we build out our UI.

Secondly, while useState's setter function updates its value directly, useReducer dispatches an action. The reducer function then determines what type of action was fired and, subsequently, how to update its state.

Note: If you haven't used it in the past, this is pretty much how Redux works.

In practice

In the sandbox below, I've built a form for scheduling an appointment. Though there are multiple inputs with different types, all of the values are related to one another as they are in the same <form>.

Instead of storing each input value in its own useState hook, we can store and manage all of the values in our form using a single useReducer. In this case, its state is an object with many keys, each representing a different value we want to store. Personally, this reminds me a bit of this.state in class components before we had hooks.

In App.js, we've defined our initial state like this:

const blankForm = {
  name: "",
  email: "",
  date: "",
  time: "",
  feeling: "3",
}

const [formState, dispatch] = useReducer(reducer, blankForm)

Each of the fields in the blankForm object represents and stores the value for an associated input in our form. Since the initial state of email is an empty string, the e-mail input will be blank on render as it reads its value from useReducer's state:

<input
  className="Form__input"
  name="email"
  type="email"
  value={formState.email}
/>

To make this work, we've also set our inputs' onChange handlers to dispatch specific actions in order to update the state. Here's what our e-mail input now looks like:

<input
  className="Form__input"
  name="email"
  type="email"
  value={formState.email}
  onChange={event => {
    dispatch({ type: "setEmail", value: event.target.value })
  }}
/>

In the snippet above, we're specifically dispatching the setEmail action. Inside of our reducer function, the switch statement looks for the case that matches the action.type and executes its logic to update state:

function reducer(state, action) {
  switch (action.type) {
    case "setName":
      return {
        ...state,
        name: action.value,
      }
    case "setEmail":
      return {
        ...state,
        email: action.value,
      }
    case "setDate":
      return {
        ...state,
        date: action.value,
      }
    case "setTime":
      return {
        ...state,
        time: action.value,
      }
    case "setFeeling":
      return {
        ...state,
        feeling: action.value,
      }
    case "reset":
      return blankForm
  }
}

For example, when setEmail is called the reducer returns a new object that contains all of the current state information, except it also updates the email field.

return {
  ...state,
  email: action.value,
}

Finally, since our useReducer hook's state has now been updated, the component will re-render and the <input />s all display their updated value from formState.

Notes about performance

As my friend Josef Aidt pointed out while reviewing an early draft of this article, our use case for useReducer in the sandbox above has certain performance implications. Since each input's onChange function fires each time an input's value changes, we are actually causing our component to re-render on each key press. This is alright for demonstration purposes, but is something to be aware of when building production apps.

Two ways we could avoid this are:

Adding a debounce to each input, so that we do not trigger a state update on each keypress.
Storing our input values in refs instead of useReducer as changing the value of a ref does not cause our component to re-render (see my useRef article for more on this).

Now, go forth and be performant!

React Hooks Revisited: useCallback

ryanharris.dev — Wed, 16 Sep 2020 12:17:01 +0000

Before you proceed...

If you haven't read my useMemo article yet, I highly suggest you go back and do so now! In that article, we covered important concepts like memoization, which we will continue discussing below.

Since useMemo and useCallback are similar (with one key difference), it will be important to understand how useMemo works before proceeding.

What's the difference?

Both useMemo and useCallback utilize memoization to optimize performance, however, there is a subtle difference between them. While useMemo returns a memoized value resulting from the logic contained within the hook's body, useCallback returns a memoized version of the function itself.

In the code block below, I've taken the useCallback example from the React docs and placed it next to its useMemo equivalent to better illustrate the difference:

// memoizedFunction is a function
const memoizedFunction = useCallback(() => {
  doSomething(a, b)
}, [a, b])

// memoizedFunction is the value returned from doSomething(a, b)
const memoizedValue = useMemo(() => {
  doSomething(a, b)
}, [a, b])

Here, useMemo and useCallback achieve the same thing: optimizing performance by returning cached values when a function has already been executed using the arguments it receives. Since they return different values, both hooks offer you a different way to leverage memoization based on your specific use-case.

In practice

useCallback is useful because you can assign a memoized function to a variable and pass it around your application. This allows you to avoid re-creating the caching mechanism that memoization uses to improve performance.

It also makes our lives easier because we do not need to duplicate useMemo logic in multiple places. We also don't need to import/export anything. Instead, we can just pass the memoized function as a prop and allow another component to consume it.

In the sandbox below, I've taken the code from our useMemo example and refactored it to use useCallback:

Like with useMemo, our useCallback hook is returning a memoized value. However, in this case, it is a memoized version of the anonymous function passed to it, not the function's return value.

For demonstration purposes, we have two map components on this page (i.e. MapOne and MapTwo), which render -- you guessed it -- maps. If we assume they both plot coordinates in the same way, we can now pass createMapCoordinates to both components, allowing them to utilize the memoized function internally without having to recreate it in both places.

const myFunction = () => {
  doStuff()
}

If you think about it, what we're doing here with useCallback isn't too much different from the snippet above since both of them create a variable and assign a function as its value. Our hook just memoizes the function so we can optimize our applications performance!

React Hooks Revisited: useMemo

ryanharris.dev — Tue, 15 Sep 2020 13:26:48 +0000

Up until this point in the series, I have been generally familiar with the hooks we've covered and have used them before at work. It wasn't until I recently started working in a new codebase that I came across useMemo. Not understanding how it worked or how to debug it was a large part of why I chose to write this series in the first place.

What is "memoization"?

If you look at the React docs, they say that the useMemo hook "returns a memoized value". Memoization was not a term I was familiar with when I first read that, so don't worry if you haven't heard of it either. We're in the same boat!

Memoization is an optimization strategy that returns cached values from functions that have previously been invoked with the same arguments. In other words, instead of recalculating its return value, the function will return a cached value. This is useful when you have functions doing memory intensive operations and want to minimize how often they're invoked.

Here's my mental model for how this works:

// Value must be calculated
add(1, 2)

// Value must be calculated
add(3, 4)

// Cached value returned
add(1, 2)

If you want to read more about memoization, checkout this article on Scotch.io by Philip Obosi. He takes a deeper look at memoization and how to implement your own memoized functions using plain JavaScript.

Anatomy of useMemo

As mentioned, the useMemo hook returns a "memoized value" and takes two arguments:

A function
A dependency array

Here's an example of how it looks directly from the React docs:

const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b])

If you have read my articles on useEffect and useLayoutEffect, you'll probably recognize this function signature. Just like those hooks, useMemo executes the logic inside the function passed to it only when one of the values in the dependency array changes. If no array is passed, useMemo will re-calculate its return value on every render.

The difference here is that useMemo is not intended to cause side effects -- those should be handled in the appropriately named useEffect or useLayoutEffect hooks. useMemo simply calculates and returns a value based on the function and dependency array passed as arguments and helps handle expensive computations that may cause performance issues.

Optimization

According to the React docs, useMemo is meant to be a performance optimization. They suggest you get your code to work without useMemo and implement it after the fact.

One thing to note, however, is that you can't really guarantee that useMemo will return a cached value when expected. Read the following sentence carefully:

In the future, React may choose to “forget” some previously memoized values and recalculate them on next render, e.g. to free memory for offscreen components. ~ React docs

To keep things performant and properly manage memory, React may get rid of a cached value it's not actively using in order to save room for other operations. In some cases, that will cause useMemo to recalculate its return value even though it had been previously in our cache.

In practice

In the example below, I've created a demo to better illustrate how useMemo works. For our purposes, I have stubbed out some functions in order to make the example work properly; however, pay attention to the comments as they will provide further context.

Note: If you're unfamiliar with useEffect or useState, take a moment and check out the previous articles in this series before continuing. Otherwise, these should look pretty familiar to you.

Here, our <App /> component does three things:

Makes a call to the NASA API in a useEffect hook and fetches a list of NASA facilities, which we store in useState

useEffect(() => {
  fetch("https://data.nasa.gov/resource/gvk9-iz74.json")
    .then(res => res.json())
    .then(json => {
      setNasaLocations(json)
    })
    .catch(err => console.log("Error fetching data", err))
}, [])

Observes the <input /> in our return and stores its value in another useState hook

const [inputValue, setInputValue] = useState("")

<input
  name="search"
  type="search"
  onChange={event => setInputValue(event.currentTarget.value)}
/>

Passes a filtered array to <MapView /> via the coordinates prop, which represents location information for each facility

<MapView coordinates={mapCoordinates} />

Technically, we could achieve these three goals without using useMemo, however, the NASA API returns to us a list of 484 facilities, which we iterate over in createMapCoordinates().

This is expensive work, especially if the function runs frequently. On top of that, it calls another function for each item in the array (i.e. createCoordsForLocation()), which currently returns a plain JavaScript object.

function createCoordsForLocation(lat, long) {
  return {
    latitude: lat,
    longitude: long,
  }
}

But imagine that createCoordsForLocation() called a backend service for each item in the list to compute its geographic coordinates. This would make our already expensive createMapCoordinates() call that much more memory intensive. Since we need to do this to make our app function properly, we can leverage useMemo to optimize performance.

Let's look at our use case:

const mapCoordinates = useMemo(() => {
  return createMapCoordinates(inputValue, nasaLocations)
}, [inputValue, nasaLocations])

First, look at the dependency array (i.e. [inputValue, nasaLocations]). Like useEffect, this tells useMemo only to run when either of those values change. Right now, we only make a call for nasaLocations on initial render, so its value will only change once, which triggers the hook.

Our other value (i.e. inputValue), represents the value the user has entered in the <input />. Anytime the user adds or removes characters from the input, the inputValue will change in our useState hook and cause useMemo to run again.

The trick here is that since we filter our nasaLocations list based on the inputValue, we can use useMemo to reduce computations. Since the hook will return a cached value whenever it receives inputs it has used for computation before, we will avoid re-running all the logic in createCoordsForLocation() and createMapCoordinates() if the inputValue and nasaLocations array we're passing in have already been processed.

Of all the hooks we've covered thus far, useMemo is one of the harder ones to illustrate as its effect on your application is not necessarily visual, but performance based. Like the React docs say, get your application logic working without useMemo to confirm the proper functionality. Then, go through your component code and identify any expensive computations as these may be great candidates for useMemo!

In the next article, we'll be covering useCallback, which also leverages memoization, but is subtly different from useMemo. Stay tuned to find out how!

React Hooks Revisited: useContext

ryanharris.dev — Mon, 14 Sep 2020 17:11:41 +0000

Putting things in Context

Context is one of my favorite React APIs and has a wide variety of uses cases. I've previously written about redoing a search UI using refs and Context, as well as how to use the useRef hook. This time around, we're going to cover the useContext hook, which is now the way we use Context in function components.

I love the Context API because it allows you to compartmentalize aspects of your app's data within a sub-tree of components. Essentially, your child components can access data via the value prop provided by the Context.Provider. You can think of this like a store that's specifically scoped to this tree. The components wrapped by the Provider can choose whether or not they want to consume the data (i.e. Consumers) at all, which means you can avoid prop drilling. Here's a rough illustration:

In class components, we used a combination of <Context.Provider> and <Context.Consumer> tags to set up the relationship described above. However, in function components, the <Context.Cosumer> syntax has been replaced with the useContext hook.

For context (no pun intended), the snippets below show these two implementations of the same Context. Despite the syntax difference, the functionality is identical.

function NestedComponent() {
  return (
    <AppContext.Consumer>
      {value => 
        <p>{value}</p>
      }
    </AppContext.Consumer>
  );
}

export default class App extends React.Component {
  render() {
    return (
      <div className="App">
        <AppContext.Provider value={"Hello from App 👋"}>
          <ChildComponent>
            <GrandChild>
              <NestedComponent />
            </GrandChild>
          </ChildComponent>
        </AppContext.Provider>
      </div>
    );
  }
}

Anatomy of useContext

The useContext hook takes one argument, a Context object, and provides access to the values from the nearest Context.Provider above it in the component tree. Any component consuming data from the Provider will always re-render any time one of the values changes.

const AppContext = React.createContext();

function NestedComponent() {
  const appContext = useContext(AppContext);
  return <p>{appContext}</p>;
}

function App() {
  return (
    <div className="App">
      <AppContext.Provider value={"Hello from App 👋"}>
        <ChildComponent>
          <GrandChild>
            <NestedComponent />
          </GrandChild>
        </ChildComponent>
      </AppContext.Provider>
    </div>
  );
}

Notice that even though we're using the useContext hook, the way we define our context and Provider is exactly the same as our class example above. The provider works the same no matter which of the following consumption syntaxes you're using:

useContext()
<Context.Consumer>
Class.contextType

In practice

In the sandbox below, I have built out a component tree that represents a self-contained search widget using the SearchInput component we built in an earlier article covering the useRef hook.

For the purposes of this demonstration, we are mimicking an API call by loading data about breweries in Philadelphia from results.json directly into our Search component and displaying them as ResultCards in the SearchResults component. Then, whenever the text value in SearchInput changes, we filter our results to breweries who have names containing a string matching the input text.

Try it out for yourself below:

In Search, we have created a SearchContext by using React.createContext(). By doing this, we will be able to pass down context values to SearchResults and SearchInput without having to prop drill through our SearchWidget component. While we would only be passing props through one additonal component in this example, think about how effective this strategy would be for components nested even further!

To provide values to the children of Search, we are using the SearchContext.Provider to pass data via the value prop. We've constructed and are passing an object that has two values:

results - An array of objects representing breweries
setInputValue - The setter function from the useState hook in Search that we're using to store the text value from SearchInput (i.e. inputValue)

With the Provider set up, any of Search's descendant components can consume our context values using useContext.

const context = useContext(SearchContext);

In SearchInput, we use the setInputValue function passed down via our context to set the state of inputValue in Search whenever the user enters text in the <input />.

function handleInputChange(event) {
  context.setInputValue(event.currentTarget.value);
}

<input
  onChange={handleInputChange}
  ref={inputRef}
  type="search"
  className="SearchInput__input"
/>

By elevating this state to the Search component, we are able to use its value to filter our apiResults and pass down a new array (i.e. results) to the SearchResults component, which renders each item as a ResultCard.

Essentially, Context allows us to more easily centralize related logic and create a good data management system for this self-contained subtree of components. Theoretically, we could repurpose this widget pretty easily by using different API data and updating a few prop names. Pretty cool!

React Hooks Revisited: useRef

ryanharris.dev — Thu, 10 Sep 2020 11:56:07 +0000

What are refs?

If you read my last article, about the differences between useEffect and useLayoutEffect, you may remember seeing some code snippets that looked like this:

useEffect(() => {
  const greenSquare = document.querySelector(".App__square")
  greenSquare.style.transform = "translate(-50%, -50%)"
  greenSquare.style.left = "50%"
  greenSquare.style.top = "50%"
})

useLayoutEffect(() => {
  const greenSquare = document.querySelector(".App__square")
  greenSquare.style.transform = "translate(-50%, -50%)"
  greenSquare.style.left = "50%"
  greenSquare.style.top = "50%"
})

In these examples, we're directly accessing the DOM in order to select and manipulate an element (i.e. .App__square), which is considered an anti-pattern in React because it manages UI state via a virtual DOM and comparing it to the browser's version. Then, the framework handles the work of reconciling the two. However, there are cases where we need may need to break this rule. That's where refs come in.

While the React docs cite a few examples where using refs would be appropriate, including managing focus, triggering animations, and working with third party libraries, they also warn against overusing them.

Avoid using refs for anything that can be done declaratively. ~ React docs

For a practical example of how to use refs in your React app, checkout my previous article about rebuilding a search UI using refs and React Context. We'll also cover the ins and outs of Context in the next article in this series.

In the next section, we'll look more closely at the useRef hook and its syntax.

Anatomy of useRef

...useRef is like a “box” that can hold a mutable value... ~ React docs

The useRef hook only takes one argument: its initial value. This can be any valid JavaScript value or JSX element. Here are a few examples:

// String value
const stringRef = useRef("initial value")

// Array value
const arrayRef = useRef([1, 2, 3])

// Object value
const objectRef = useRef({
  firstName: "Ryan",
  lastName: "Harris",
})

Essentially, you can store any value in your ref and then access it via the ref's current field. For example, if we logged out the variables from the snippet above, we would see:

console.log(stringRef)
// {
//   current: "initial value"
// }

console.log(arrayRef)
// {
//   current: [1, 2, 3]
// }

console.log(objectRef)
// {
//   current: {
//     firstName: 'Ryan',
//     lastName: 'Harris'
//   }
// }

As I mentioned in the intro, refs are primarily used for accessing the DOM. Below is an example of how you would define and use a ref in the context of a class component:

class MyComponent extends React.Component {
  constructor() {
    super();
    this.inputRef = React.createRef();
  }

  render() {
    return (
      <div className="App">
        <input ref={this.inputRef} type="text" />
      </div>
    );
  }
}

To do the same exact thing using hooks, we would leverage useRef like you see in the snippet below:

function MyComponent() {
  const inputRef = useRef(null);

  return (
    <div className="App">
      <input ref={inputRef} type="text" />
    </div>
  );
}

Hopefully, those examples clearly illustrated how to define a ref. Just remember: refs are a "reference" to a DOM element -- it's right in the name!

refs also have another less-known use case. Since a ref's value can be any JavaScript value, you can also use refs as basic data stores. Usually, you would use useState for something like that, however, there are time where you want to avoid uneccessary re-renders but cache a value. Updating values in state cause a re-render each time, whereas updating refs do not cause the component to update. This is a subtle, but important distinction.

In practice

In the sections below, we'll walk through two examples that better illustrate how to use useRef both to access DOM elements and store values without causing our component to re-render.

Accessing DOM elements

For this example, I have built a small SearchInput component that uses the useRef hook in order to refer to the <input /> element rendered by our component:

In this specific case, our SearchInput component takes an autoFocus prop, which determines whether or not we want the <input /> to be focused automatically on mount. In order to do this, we need to use a web API (i.e. .focus()) and thus need to be able to directly refer to the HTML element on the page.

To get this to work, the first thing we need to do is create a ref and assign it to our element:

// This instantiates our ref
const inputRef = useRef(null);

// Inside our return, we point `inputRef` at our <input /> element
<input ref={inputRef} type="search" className="SearchInput__input" />

Now, our inputRef is pointing at the search input, so if we were to log out inputRef.current, we would see our <input />:

console.log(inputRef.current)
// <input type="search" class="SearchInput__input"></input>

With this wired up, we can now autofocus the input on mount, as well as add some styling to make our SearchInput component look more cohesive even though it is made up of multiple elements "under the hood". In order to handle the autofocus behavior, we need to use the useLayoutEffect hook to focus the input prior to the DOM painting.

Note: For more info on when to use useLayoutEffect vs. useEffect, check out my previous article in this series.

useLayoutEffect(() => {
  if (autoFocus) {
    inputRef.current.focus();
    setFocused(true);
  }
}, [autoFocus]);

By calling inputRef.current.focus(), we are setting the <input /> inside our component as the active element in the document. In addition, we're also updating our focused value stored in a useState hook in order to style our component.

const focusCn = focused ? "SearchInput focused" : "SearchInput";

Finally, I have also added an event listener using a useEffect hook in order to update our focus state based on mouse clicks both inside and outside of our component. Essentially, when the user clicks inside SearchInput, we call .focus() and update our focused state to true. Alternatively, when the user clicks outside the component, we call .blur() and set focused to false.

useEffect(() => {
  function handleClick(event) {
    if (event.target === inputRef.current) {
      inputRef.current.focus();
      setFocused(true);
    } else {
      inputRef.current.blur();
      setFocused(false);
    }
  }

  document.addEventListener("click", handleClick);
  return () => {
    document.removeEventListener("click", handleClick);
  };
});

While accessing DOM elements is a React anti-pattern (as discussed above), this example is a valid use case for refs because our goal requires the use of .focus(), which is only available to HTML elements.

Storing values without re-rendering

In this example, I want to illustrate the subtle difference between using useState and useRef to store values.

Here, we have two sections that have buttons, which allow us to increment/decrement our refValue or stateValue, respectively. When the page initally loads, each section is assigned a random hex value as its background-color. From then on, you will see the colors change whenever our App component re-renders.

Since updating state values cause a re-render, you should see the stateValue number update every time you click on of the buttons; however, if you click on the buttons for our refValue, nothing happens. This is because updating ref values does not cause a component to re-render. To demonstrate that the refValue is in fact changing, I have added console.log statements to the onClick handlers for both buttons.

While incrementing or decrementing the refValue will not cause our UI to update with the proper numeric value, when you change the stateValue our refValue will update and its section will have a new background color. This is because our ref section is re-rendered when the state value is updated since the parent component App has to go through reconciliation to bring the virtual DOM and browser DOM into sync with one another. This can be a great strategy for avoiding uneccessary renders in your application and improving its performance!

React Hooks Revisited: useLayoutEffect

ryanharris.dev — Wed, 09 Sep 2020 17:20:08 +0000

Last time, we learned about the useEffect hook, how it works and when to use it. If you have not read that article yet, I strongly suggest you go back and do so before proceeding any further. Much of what we will discuss below will be about the similarities and differences between useEffect and useLayoutEffect, which may not make much sense without having a good grip on the former.

useLayoutEffect and useEffect

The signature is identical to useEffect, but it fires synchronously after all DOM mutations. ~ React docs

While the underlying implementation and execution of these hooks does differ, you may notice that the code snippets below look quite similar. That's because these two hooks have the same function signature!

useEffect(() => {
  function getData() {
    // Define effect logic here
  }

  const apiData = getData()
  setData(apiData)
}, [])

useLayoutEffect(() => {
  function handleResize() {
    // Define effect logic here
  }

  document.addEventListener("resize", handleResize)
  return () => {
    document.removeEventListener("resize", handleResize)
  }
}, [])

To quickly recap, the anatomy of these hooks are comprised of three key pieces:

The effect
A dependency array
A cleanup function

Since we're already pretty familiar with how these hooks are composed, let's look a bit more about what makes them different.

Difference between useLayoutEffect and useEffect

As we saw above, these two hooks are quite similar in terms of their syntax and function signatures, however, the difference between them is quite subtle and has everything to do with timing.

The useEffect hook fires after render so as not to block the DOM from painting and effecting your application's performance. Due to this behavior, the React documentation advises that when writing new effects you start with useEffect and only reach for useLayoutEffect when absolutely necessary.

...we recommend starting with useEffect first and only trying useLayoutEffect if that causes a problem... ~ React docs

Unlike useEffect, useLayoutEffect fires after all DOM mutations but before the DOM paints. While this is the only difference between these two hooks, it is an important distinction because of when their effects are performed.

But when would you want to use one versus the other? The general rule of hand is as follows:

Use useLayoutEffect when reading, manipulating or observing the DOM
Use useEffect for all other effects that don't require interaction with the DOM

If you're still a bit confused, don't worry! It can be hard to wrap your head around not only the difference between these two hooks but their specific use cases, as well. Below, we'll look at a practical example, which will help illustrate the difference a bit more clearly.

In practice

In both of the examples below, we have a simple application that renders a few HTML elements, namely two divs and a main, which we can see in App.js:

return (
  <div className="App">
    <main className="App__main">
      <div className="App__square" />
    </main>
  </div>
)

Above each <App />'s return, you will see an effect defined with either useEffect or useLayoutEffect. The snippet below shows them side-by-side:

useLayoutEffect(() => {
  const greenSquare = document.querySelector(".App__square")
  greenSquare.style.transform = "translate(-50%, -50%)"
  greenSquare.style.left = "50%"
  greenSquare.style.top = "50%"
})

useEffect(() => {
  const greenSquare = document.querySelector(".App__square")
  greenSquare.style.transform = "translate(-50%, -50%)"
  greenSquare.style.left = "50%"
  greenSquare.style.top = "50%"
})

As I am sure you've noticed by now, the effect function passed to both hooks are exactly the same. Again, the big difference here is the timing of when these effects run.

To start, let's look at the sandbox using useEffect. You should see the purple circle appear in the top left-hand corner of the screen before it is quickly repositioned and moved to the center of the screen. This happens because useEffect runs after render, so the effect isn't executed till after the DOM paints, which is what causes the unwanted flash of content.

Now, let's look at the useLayoutEffect hook. If you refresh the page, you should always see the purple circle in the center of the screen and no longer see the circle get quickly repositioned. This is because useLayoutEffect runs before the DOM paints, so the circle has already been positioned correctly before we see the first visual representation of our page. In this example, it would be more appropriate to use useLayoutEffect because we would not want our users to see what looks like a visual bug.

Next steps

In the examples above, we are using vanilla JavaScript to access and modify the document, which is considered an anti-pattern in React. A more appropriate way to do this would be to use a ref instead of accessing the DOM directly. Luckily, we'll be covering that in the next article about useRef!

React Hooks Revisited: useEffect

ryanharris.dev — Tue, 08 Sep 2020 18:18:59 +0000

In my last article, we learned about one of the most commonly used hooks, useState. This time around, we are going to look at another commonly used hook: useEffect:

By using this Hook, you tell React that your component needs to do something after render. React will remember the function you passed (we'll refer to it as our "effect"), and call it later after performing DOM updates. ~ React docs

What are effects?

Effects, a shorthand for "side effects", represent component operations or actions that cannot be done during the render phase. Examples of this can include:

Fetching data from an API
Setting up data subscriptions or document event listeners
Manipulating the DOM

We can also further classify them into two categories:

Effects that require cleanup
Effects that don't

For example, if we attach an event listener to the document, we will want to remove it when the component unmounts as this will help with performance and avoid conflicting listeners. On the other hand, something like updating the document.title does not require any further work when the component unmounts.

To make cleaning up effects easy, the useEffect API allows you to optionally return a function from the hook, which does the work of removing listeners, subscriptions, etc. Previously, you would've needed to leverage both the componentDidMount and componentDidUnmount lifecycle methods to achieve this whereas useEffect allows us to take care of it all at once.

Anatomy of useEffect

Now that we've talked about what useEffect does, let's take a look at the syntax:

useEffect(() => {
  // 2. This function body is your effect
  window.addEventListener("resize", handleResize)

  return () => {
    // 1. Optionally clean up effects inside this function
    window.removeEventListener("resize", handleResize)
  }
}, []) // 3. Conditionally execute based on dependencies array

If this syntax looks a bit strange, don't worry. We'll break down each piece before moving on to some practical examples. Let's start with the optional cleanup function since we were just talking about it.

1. Cleanup

Inside our effect, we can optionally return a function. This function will perform any cleanup work we want to happen when this component unmounts. In our example, we are removing the event listener from the window to make sure it doesn't keep listening/firing after the component is no longer in the DOM.

2. The effect

The first argument useEffect takes is a function. This function is your effect and defines the work you want to do whenever the component mounts. In this case, we are simply adding an event listener to the window that executes the handleResize function on resize.

3. Dependency array

The optional second argument in this example is what's known as the "dependency array". Essentially, leveraging this array allows you to control the conditional execution of the effect based upon changing prop or state values in the component. We will talk about this more in-depth in the next section.

What is the dependency array?

By default, effects run after every completed render, but you can choose to fire them only when certain values have changed. ~ React docs

As I mentioned above, the dependency array is an optional secondary argument passed to the useEffect hook. Its purpose is to allow you to more easily control the execution of your effects based upon the values within you component. In class components, we would most likely need to use the componentDidUpdate lifecycle method to achieve the same results, which would've looked something like this:

componentDidUpdate(prevProps, prevState) {
  if (prevState.cardTypes !== this.state.cardTypes) {
    // Your effect logic would live here
  }
}

Using the dependencies array we can do things like:

Fire the effect everytime the component renders

useEffect(() => {
  const cardTypes = fetchCardTypes()
  setCardTypes(cardTypes)
})

Fire the effect only upon the first render

useEffect(() => {
  const cardTypes = fetchCardTypes()
  setCardTypes(cardTypes)
}, [])

Fire the effect only when certain prop or state values have changed

useEffect(() => {
  const cardTypes = fetchCardTypes()
  setCardTypes(cardTypes)
}, [cards])

One thing to note here is that while you can also use if statements within your useEffect hooks to conditionally execute logic, you cannot wrap hooks in if statements. Part of how React keeps effects predictable is to run them all upon render. Skipping effects like this is considered bad practice, so don't do it!

In practice

In the sandbox below, I've create a small application that leverages useEffect in numerous ways in order to serve us information about the latest weather on Mars. Elon Musk, eat your heart out!

For simplicity's sake, I've created two components: App and WeatherDisplay. The former handles fetching our data from the Nasa API and our application logic, whearas the latter simply displays the data we've passed down to it as props. Because of that, all of our useEffect hooks live inside of App.

As you will notice, we actually have three useEffect hooks inside of our component, which may seem a bit strange, but is the whole idea of hooks! This allows us to compartmentalize our component logic and more easily reason about the effects they trigger. In this example, our three hooks are doing the following:

Hook #1 sets the title of our document on every render using the value of our day state
Hook #2 fetchs our API data only on the first render as we don't want to make be making continually API calls as the component updates
Hook #3 parses the proper data object based on the value of day any time the value of day or data change

Each of these hooks is using a diffrent variation of the optional dependency array we discussed earlier. Look at the code a bit more closely -- do you know why each array looks the way it does?

Don't worry if you're still a bit confused because learning to "think in hooks" can take some time. The best way to get more comfortable with them is to use them, so feel free to fork the sandbox above and play around with the code. As a good place to start, try removing the dependency array from Hook #2 completely. What happens?

With an empty dependency array, the effect makes a request for our API data on mount and this only happens once. Previously, we would componentDidUpdate and compare the components prevProps to it's current props and use that to determine if there was work to be done. Now, with useEffect, we no longer have to do this and can just define what prop values we care about and run the effect only when one of them changes. We'll talk more about this more later in the series.

If we remove the dependency array altogether, the effect runs on every render, which means we're making API calls every time the component re-renders. Since something simple like changing state (ex. clicking on the Today or Yesterday buttons) causes a re-render, we'd essentially fetch data everytime the user clicked one of the buttons. This is not good for application performance, nor your API bill.

Ultimately, hooks are meant to compartmentalize application logic to make them easier to re-use and reason about. useEffect is no different. Like all hooks, it runs on every render by default, but unlike other hooks, provides a way to conditionally control our logic execution (i.e. the dependency array). While useEffect is often described as componentDidMount, componentDidUpdate and componentWillUnmount altogether, I would try to avoid thinking about hooks in terms of their equivalent lifecycle methods. Instead, identify the effects that need to take place in your component, determine how often your would like the effect to run and cleanup your work (if needed) when the component unmounts.

Try adding useEffect to your next component. Maybe you'll get hooked.

React Hooks Revisited: useState

ryanharris.dev — Mon, 07 Sep 2020 17:34:21 +0000

One of the first hooks you'll probably encounter is useState, which replaces the setState() function used to update state in class components. The big difference here, however, is that useState allows function components to have multiple state values as opposed to one monolithic object. The snippet below illustrates this idea (don't worry about the syntax as we'll be covering that below):

// Class component state
class Cart extends React.Component {
  constructor(props) {
    super(props)

    this.state = {
      apples: 10,
      oranges: 25,
      peaches: 40,
    }
  }
}

// Function component using hooks
function Cart(props) {
  const [apples, setApples] = useState(10)
  const [oranges, setOranges] = useState(25)
  const [peaches, setPeaches] = useState(40)
}

Not too crazy, right? In this example, all of our values are numbers but the value stored in useState can be any JavaScript type, including:

Strings
Booleans
Objects
Arrays
Numbers
null

Anatomy of useState

Let's take one of the previous examples and look at it a bit more closely.

const [apples, setApples] = useState(10)

First, let's look at what is happening on the right side of this expression. Here, we have the value of 10 being passed as the only argument to our useState hook. This sets its initial value to 10.

On the left-hand side of the assignment, we are destructuring two values returned from useState as an array: apples and setApples. The first (i.e. apples), represents the current value of this state. In this case, the value would be 10.

The second value in the array (i.e. setApples) is a setter function that allows you to update the value of apples by calling setApples(200), which would update apples to be equal to 200.

While you can technically give these setter functions whatever name you want, the common convention is to prepend the value's name with set (ex. setApples).

In practice

To better illustrate the mental model of having multiple states instead of one, I built a simplified version of an e-commerce cart.

The first instance is a function component using three useState hooks to manage the quantity values of how many apples, oranges and peaches are in the user's cart. The second is a class component that is still using setState().

As you can see, both components do the same things: keep track of how many of each item a user wants and increment/decrement that value based on button presses.

Take a look at the code and see which one you prefer. While hooks may still be new to you, can you see any benefits from using them?

React Hooks Revisited: Introduction

ryanharris.dev — Mon, 07 Sep 2020 17:33:06 +0000

Hooks are functions that let you “hook into” React state and lifecycle features from function components ~ React docs

Introduced in React v16.8, the hooks API represents a change in how developers compose their components. Intended to compartmentalize blocks of functionality, they make reusing code across your application easier. They also mark a shift away from using class components and the use of lifecycle methods.

When hooks were first introduced at React Conf 2018, the React team explained the motivations behind them. Essentially, they wanted to solve many problems all at once:

It can be hard to re-use logic between components
Complex component files are huge
Understanding classes in JavaScript can be difficult to understand (for humans and compilers)

For a much more detailed explanation about the origin of hooks, make sure to check out the team's full talk featuring Dan Abramov, Sophie Alpert and Ryan Florence.

Goals for the series

When the hooks API moved out of beta, my team started using them almost immediately. However, most of the logic for the feature I was working on at the time was contained within class components still using lifecycle methods. When creating new components, I was using function components and hooks; however, the components usually weren't complex enough to leverage more than useState or useEffect.

Currently, I work in a codebase that was all written "post-class components" and I want to revisit (hence the title of this series) how they all work, as well as when to use them.

To do that, I've written an article about each hook in the standard React library. Each piece is linked below and will cover the hook in depth, including code samples illustrating how it works.

Redoing search UI with React Context and refs

ryanharris.dev — Thu, 10 Oct 2019 18:15:06 +0000

** Originally published on LogRocket

Recently, the product team at my company discovered the majority of our users were not utilizing filters when using our search interface.

After looking at our analytics, it became apparent users weren’t engaging with filters because they didn’t know they existed.

To fix this problem, we decided to rebuild our UI in order to highlight this functionality.

But building a new search interface came with its own set of problems. In our case, we had three main concerns:

By adding filter dropdown menus with nested inputs, we would need a way to easily manage focus.
With three filter menus, we needed a way to ensure only one menu was open at any given time.
When the user selected a filter from one of the menus, we needed to both close the menu and trigger a new search.

We achieved all of our objectives by using React’s Context API in conjunction with refs to create a centralized system for managing menu states and input focus.

In this article, we’ll cover the following:

Context: basic usage and strategies for injecting data anywhere in your component tree

Refs: what they are and why our use case calls for them

Context

The official Context API was added to React in v16.3 and is intended to avoid what is commonly known as prop drilling, or manually passing props down a component tree.

While there is nothing wrong with this approach, it can be unwieldy when dealing with complex component hierarchies, especially if some components don’t care about the data and are simply passing it on.

In order to use the Context API, you need to create a Context.Provider that takes a value prop representing all the data you want to inject into the child components that need it.

Before the advent of Hooks, you would do this by using an associated Context.Consumer, but in the post-Hooks world, we can leverage the useContext Hook to subscribe a component to the closest Provider above it in the component tree.

In this case, Context provides a way to keep track of which menu should be open in our parent component, and then passes that value down to its children who, in turn, conditionally render the appropriate dropdown.

The key here is that our Context also passes down a setter function. This is important because it allows the components consuming our context value to then update the state in our parent component, which causes the tree to re-render with the new menu now visible.

By using the pattern described above, we can similarly manage the focus state of the various inputs in the search bar and filter menus.

Refs

While they have been part of React for a while, refs can still be somewhat confusing even for more experienced developers.

Essentially, React provides a special ref attribute that can be applied to any element (JSX or HTML).

Depending on what type of element you assign it to, the ref provides access to that class instance or DOM element, respectively.

// Applying a ref directly to an HTML element
<input
  className="AuthorFilterMenu__filter-input"
  ref={authorFilterInputRef}
  placeholder="Filter by author..."
  value={filterInputValue}
  type="search"
  onInput={event => {
    setFilterInputValue(event.currentTarget.value);
  }}
/>

// Applying a ref to a React component instance
<AuthorFilterMenu ref={authorFilterInputRef} />

Though our use case requires us to go down this road, it is important to note that refs are a React antipattern because they allow direct DOM access. React does not really intend for developers to do this, so when using refs you should proceed with caution.

Alternatively, React is designed to have events update the virtual DOM (a snapshot of the document object model kept in memory,) and allow the framework to update the page as needed in a process known as reconciliation.

This not only makes React more performant by reducing the work done to update the page, but it also makes for a more consistent user experience.

For us, we need to directly access the three inputs in our component tree in order to use the browser’s .focus() method. Since we need to change focus states for our inputs based on user interaction, it makes sense to keep this logic in our parent component, too.

We’ll create three different refs in our parent component that will point to the following:

The input in our search bar
The input in our first filter menu (ex. Author)
The input in our second filter menu (ex. Year)

Using our Context, we can then pass these refs down to our child components. In the child component, we destructure the appropriate ref off the component’s props object and assign it directly to our HTML input:

// Provide value in App.jsx
<section className="App__search">
  <SearchContext.Provider
    value={{
      openMenu: openMenu,
      toggleOpenMenu: toggleOpenMenu,
      addAuthor: addAuthor,
      addYear: addYear,
      selectedAuthors: selectedAuthors,
      selectedYears: selectedYears,
      authorFilterInputRef: authorFilterInputRef,
      searchBarRef: searchBarRef,
      yearFilterInputRef: yearFilterInputRef
    }}
  >
    <SearchBar />
  </SearchContext.Provider>
</section>

// In AuthorFilterMenu.jsx, we grab the ref from the searchContext
function AuthorFilterMenu(props) {
  const contextValue = React.useContext(SearchContext);
  const {
    addAuthor,
    openMenu,
    selectedAuthors,
    authorFilterInputRef
  } = contextValue;
}

// And then we apply it to the <input>
return (
  <div className={menuCn}>
    <input
      className="AuthorFilterMenu__filter-input"
      ref={authorFilterInputRef}
      placeholder="Filter by author..."
      value={filterInputValue}
      type="search"
      onInput={event => {
        setFilterInputValue(event.currentTarget.value);
      }}
    />
    <ul className="AuthorFilterMenu__list">{createMenuItems()}</ul>
  </div>
);

Now, whenever one of the child components calls our menu state setter function to toggle a menu, we can add logic to also update which input is in focus.

For example, if one of our filter menus is open and then closes, we would want to refocus the search input bar to allow the user to continue their query.

One thing to note here is that function components don’t play well with refs.

In order to pass a ref into a function component, you will need to use React.forwardRef, which creates a new component that receives a ref attribute and then passes it on to another component below.

For a more detailed look at how to use forwardRef, check out the official React docs.

Conclusion

While Context is a relatively new API and refs are somewhat of an antipattern, they compliment each other well in this case. By combining the two together, we are able to create a more straightforward way of managing both display and focus states within our new search interface.

While we didn’t use any stores in this example, you could easily wire one up and include it in this data flow.

For example, in the project I built at work, my parent component was subscribed to a store that provided a list of the items to be rendered in our dropdown menus.

Once the parent received this data, it added it to our Context’s value prop and passed it down to the child components.

Ultimately, the ability to centrally locate logic in this way allows for a more consistent user experience.

By using Context, we easily decoupled our business logic and data fetching from the presentation and functionality of our UI components.

We also made our code easier for other developers to read in the future, which is never a bad thing!

For the full tutorial, check out this demo: