React's useEffect hook is an important tool for managing side effects in your functional components.

In this post, we'll look at when your effects run.

Effects run on the initial render

Every effect runs at least once when your component first renders. In the example below, the log statement in the useEffect hook executes without you having to do anything:

Effects run every render if there are no dependencies

In the previous example, we passed an empty array as the second argument to the useEffect hook. This argument is called the dependency array. The array controls when the effect runs after the first render.

If you don't pass a second argument to the useEffect hook, your effect will run on every render. In the example below, the log statement runs every time you click the Force Rerender button:

Effects run when dependencies change

If you want to be more selective about when your effect runs, you need to use the dependency array argument. The way it works is that the values in the dependency array are compared every render. If a value at a given position changes, the effect is executed again.

Let's take a look at an example:

// First render
useEffect(() => {}, [1, 2]);

// Second render
useEffect(() => {}, [1, 3]);

1. Dependency array on the first render: [1, 2]

2. Dependency array on the second render: [1, 3]

The first element (1) is the same between renders, but the second element (2 and 3) is different. The effect is re-executed because the value changed for the second element in the dependency array.

In the example below, we have a count variable managed by React state. Every time you click the Count button, the value is incremented, and the component re-renders.

Since the count variable passed to the useEffect dependency array changes between renders, the log statement will run.

Now what if we click the Force Rerender button instead?

This button doesn't update the count variable. Even though the component re-renders, the value passed to the useEffect dependency array is the same. In this case, the log statement won't run.

Try it out!

Non-primitive data types are compared by reference

One thing to keep in mind is that any non-primitive data type passed to a dependency array is compared by its reference.

This means that even if a value looks the same, if the underlying reference changes, React will execute the effect.

For example, the two functions below may look the same, but from JavaScript's perspective, they have two different function references:

const fnOne = () => true;
const fnTwo = () => true;
fnOne === fnTwo // false (different references)

Here are a few data types where this applies:

• Functions

• Objects

• Arrays

We can see this play out in the example below.

Since the logger function is recreated every render, the underlying reference will be different.

This time, since we pass the logger in the dependency array, the Force Rerender button will cause the log statement to run again:

Create stable references to prevent effects from running

We can pass stable references to our dependency arrays to solve this problem.

For functions that are created in a React component, this usually means wrapping it with the useCallback hook.

The useCallback hook takes a function as its first argument and a dependency array as the second argument. On the initial render, a new function is created. However, every other render will return the same function if the elements in the dependency array are the same.

The useCallback dependency array follows the same rules as the useEffect dependency array.

This time the logger function is wrapped with the useCallback hook, so we get a stable reference between renders and the Force Rerender button won't cause the log statement to run again:

Effects can have cleanup functions

Another important part about effects is that they have optional cleanup functions. If you return a function in an effect, React will execute it before executing the next effect. In other words, it'll look something like this:

1. The effect runs on the initial render

2. A value in the dependency array changes

3. The cleanup function from the first effect runs

4. The next effect runs and returns a new cleanup function

In the example below, you'll notice that a Clean up Count log statement runs before the next Count log statement every time you click the Count button.

And that's it!

A quick look at when React's useEffect hook runs.

Understanding when the useEffect hook runs will help you manage side effects predictably and efficiently, ensuring that your React components behave as expected!

Sandpack is a lightweight code playground built by the CodeSandbox team.

With Sandpack, you can compose built-in and custom React components to create unique experiences for your end users.

In this post, we're going to focus on the built-in SandpackPreview component.

The Sandpack Preview Component

The Preview component is your window into Sandpack's bundling process. It shows you how your UI looks. Not only that, but it also supports live updates when you make changes in an Editor component:

How to support browser navigation.

Just like a regular browser, the Preview component has a search bar. You can enable it with the showNavigator prop. You don't need to use the search bar, but it can be useful when building a demo that involves routing:

In the example above, we're using React Router. We've defined a root route at / and another route at /secret. By default, the app is on the / route which shows a page with the text "Hello world!".

Try using the search bar to navigate to the /secret route. The page should update and show the text "Hello Secret!" now!

Great! But what if we want the app to start on the /secret route instead of the / route?

Well, that's easy too!

You can use the startRoute prop like below:

You can add custom actions to your Preview component.

The Preview component supports custom actions. The idea is that you can use a custom action to provide additional functionality to your playground. Let's say I wanted a way to toggle the search bar in the previous example.

We can combine React state with a basic toggle button to accomplish this:

You can use refs to interact with the Sandpack client.

Let's say I'm building a demo to showcase Tailwind CSS.

I want to include a button to add or remove Tailwind from the page. This will make it easier to compare the UI with and without Tailwind. An easy way to add Tailwind to a Sandpack instance is to pass the CDN to Sandpack as an external resource.

But how do you update the external resources?

We can't do this with just a custom action. Instead, we can pass a React ref to the Preview component. The Preview component uses React's useImperativeHandle hook to attach a handler function that returns the underlying Sandpack client to the ref.

We can use the Sandpack client to update the external resources and refresh the Preview:

This pattern is useful because it automatically refreshes the Preview with the new resource.

In fact, this is a pattern I follow in Kempo:

Note: Kempo lets you build embeddable Sandpack instances.

And that's it!

Hopefully, this helps you use Sandpack's Preview component more effectively!

State management is a critical part of most front-end applications. In React, you have a few mechanisms to track state, but two common ones are the useState and useRef hooks.

If you're not familiar with these hooks, it can be confusing to know when to use each one. In this post, we'll compare the useState and useRef hooks and build some basic intuition around when to choose each one.

The useState hook lets you add state to functional components.

The useState hook is the basic building block to manage state for functional components. The hook returns a tuple where the first element is the state and the second element is a function to update that state.

The key part of the updater function is that it's designed to trigger a re-render. When a React component re-renders, the JSX is recalculated and the underlying HTML is updated to reflect any state changes.

As you click the button in the example below, you'll notice that:

1. The count variable is incremented

2. The component re-renders

3. The HTML changes

Great!

We can manage state in React now, but how does useRef come into play?

The useRef hook lets you track state that isn't needed for rendering.

Just like the useState hook, the useRef hook lets you track state. The hook returns an object with a current property that contains the state. To update the state, you just need to update the current property.

The key difference is that any update to this state won't trigger a re-render.

Here's a similar example as above, but with the useRef hook instead. There's also a button to force the component to re-render.

When you click the count button, notice how the state doesn't update. This is because updates to useRef values don't trigger re-renders.

That said, the underlying state is still updating.

But how do we prove that?

Well, if we use the other button to force a re-render, you'll notice that the button's value changes based on the current state tracked by the useRef hook:

Note: Because updates to useRef values don't trigger re-renders, you want to make sure you don't use a ref's value in your JSX. I know I'm breaking that rule above, but the example is just for demonstrative purposes.

Ok! So we want to use a ref when we track state that doesn't trigger a re-render. But what kind of state shouldn't trigger a re-render?

Let's take a look at a couple of examples.

How to scroll an element into view.

It's common to track DOM elements with the useRef hook. If you pass your ref variable to an element's ref prop, React will automatically set your variable's current property to the DOM element.

Once you have access to the DOM element, you can do various things like reset a form input or scroll an element into view.

In the example below, we have a dummy recipe blog post. Like most recipe blog posts these days, there's content before the recipe that provides some background about the dish.

Wouldn't it be nice if there were a button that let you skip all that extra information and jump straight to the good stuff?

Let's see how we might be able to do that with the useRef hook.

Note: I used ChatGPT to generate a dummy recipe blog post, so apologies if there are mistakes in the content.

Notice how we're passing the recipeRef to the h2 element Creamy Spinach and Mushroom Alfredo Pasta. React automatically sets the current value of our ref to the h2 DOM element. With that in place, we can use the ref to scroll the element into view when the button is clicked.

Easy!

How to build a countdown timer.

Another good use case for the useRef hook is to keep track of an interval ID that's returned from a setInterval call.

Let's say we had a countdown timer that shows the countdown in seconds. The easiest way to build this would be to use the useState hook to show the current timer value and then update the state every second.

That part is easy.

But what if we wanted a way to start and stop the timer? This is a little bit more tricky. The good news is that we can use the useRef hook for this. We can keep track of an interval ID when the timer starts and use it to clear the interval when the timer stops.

Let's see what that looks like:

Note: When we update the count, we're using a functional update because the function we pass to setInterval will have a stale version of the count variable due to its closure.

When to use each hook.

Hopefully, the examples above will help you build intuition around when to use each hook. But as a general rule of thumb use the useState hook when you want your component to re-render and the useRef hook when you don't want your component to re-render.

I've been using code playgrounds in my blog posts for a while now. They're a great way to make the content more engaging and informative.

The easiest way to do this is to embed something like CodeSandbox or StackBlitz into the post. That said, while these tools are amazing, they're not perfect. There's not much room to customize the experience per playground.

Luckily, the CodeSandbox team thought of this and released Sandpack!

Sandpack lets you build lightweight customized coding experiences.

Sandpack is an open-source project that lets you build playgrounds powered by the same bundler that CodeSandbox uses. The difference is that you have far more control over the look and feel of your playground.

Sandpack consists of two main packages:

1. sandpack-client: a small package that lets you hook into the Codesandbox bundler

2. sandpack-react: a set of React components that make it easy to interact with a Sandpack client

For this post, we're going to focus on the sandpack-react package because it abstracts away a lot of the manual steps involved when using the sandpack-client package directly.

How do you build a basic Sandpack playground?

The easiest way to build a Sandpack playground in React is to use the core Sandpack component:

Sweet!

Our playground has a basic editor and preview, but how does it get its content? All we're returning is <Sandpack template="react" />, but somehow, the playground is showing a "Hello World" application.

Sandpack comes with predefined templates.

You may have noticed we're passing a template prop to the Sandpack component. This is where the magic happens. Sandpack has a few templates baked into it for common frameworks like React and Vue.

In this case, because I set the template to react, we get this basic "Hello World" React app.

Note: Try changing the template above to "vue" and see what happens.

Ok!

So a "Hello World" app might seem cool, but it doesn't feel very useful. The built-in templates are a great starting point, but if you want to use Sandpack in your blog, you probably want your playground to show different code examples.

You can configure Sandpack's default files.

The good news is that Sandpack makes it easy to override the default template configuration. You can pass a set of files to the component that will be used to initialize the Sandpack instance:

The /App.js file in our files prop overwrites the built-in /App.js file.

One thing to keep in mind is that the key (i.e. file name) should be the relative file path you want to override or include. You can find the default files of a template in the Sandpack GitHub repo.

Note: Here's the list of files for the React template we're using.

Use the package.json file to add npm packages to your playground.

A code playground wouldn't be that useful if it didn't support using third-party packages. With Sandpack, you can do this with the package.json file. Override the default file and include whatever npm packages and versions you want.

Here's an example using a few Material UI packages to build an App Bar component:

Note: This was adapted from the Material UI App Bar documentation.

So what else can we do?

I promised you customization, right?

You can apply custom themes to your Sandpack instance.

If you're feeling adventurous, you can build a theme using the Sandpack theme builder. That said, Sandpack has several pre-defined themes in the sandpack-themes package. To use them, you just have to install the package and choose the theme you want.

Here's an example using the Gruvbox Dark theme:

Changing the theme is just the tip of the iceberg. There are way more things you can customize with Sandpack. All the examples we've looked at so far use the Sandpack component.

While this component is the easiest way to get started, Sandpack also gives us access to lower-level components to build even more unique experiences.

Create unique experiences using Sandpack's building blocks.

There are quite a few components that you can use, but here are a few core ones you'll probably reach for most often:

1. SandpackProvider (Essential): This component is required when using other low-level components. It uses React context to provide the other components with Sandpack's internal state.

2. SandpackLayout: This component wraps other components like the Editor or Preview and gives the playground a basic responsive design.

3. SandpackPreview: This component displays the bundled code in an iframe.

4. SandpackCodeEditor: This component lets you update the code.

Let's see these components in action:

Each button in the example above changes how our playground looks. For example, the Flipped button swaps the order of the Editor and Preview components.

This is huge!

Sandpack's building blocks let you create any experience you can imagine.

How to build a custom Sandpack component.

If Sandpack's built-in components aren't enough, you can build your own components too! Sandpack has several hooks you can use to build these custom components.

Let's say you don't like Sandpack's default code editor. No problem! With a little bit of code, you can swap it out for something else.

Here's an example of how to use the popular Monaco editor:

Sandpack's useActiveCode hook returns the current code and a function to update the code. We pass both to the Monaco editor which uses them to update Sandpack's internal state which is reflected in the Preview.

We're also using the useSandpack hook to provide a key to the Monaco editor so that the editor state is reset when the file changes.

How am I using Sandpack in my blog?

This may be obvious, but all the Sandpack examples above require us to write React code. If you have control over your blog's code, installing and using Sandpack is straightforward. However, if your blog is hosted on a platform like Hashnode (like this blog), you won't be able to write code directly in a post.

So how am I able to get around this?

That's where Kempo comes into play.

I wanted a way to use Sandpack in my own blog, so I built an application that lets you configure Sandpack instances. All the examples above are Sandpack instances that are demoing Sandpack.

In other words, it's Sandpack instances all the way down!

I know what you're thinking.

Aren't we right back to using something like CodeSandbox to embed code playgrounds into our blogs?

I will admit that this is somewhat true, but there are some major differences. Kempo is built around configuring Sandpack. The goal is to use Sandpack's features without having to write code to configure and style Sandpack directly.

Just like Hashnode takes away the need to build a blogging platform so you can focus on your content, Kempo takes away the need to manually configure Sandpack so you can focus on your demos.

There are still improvements to be made, but for now, I think these are the main benefits:

1. Lightweight

2. Custom themes

3. Flexible components

4. Custom layouts for different screens

Note: You can learn more in my post where I introduce Kempo.

If you can use Sandpack directly in your blog then that's great, but if you're writing on a platform like Hashnode, Kempo might be a good fit.

If you do try using Kempo, let me know how it goes!

Either way, I hope this post gets you excited about Sandpack!

I did too!

My website is served at https://thesshguy.com, but I also wanted https://www.thesshguy.com to work.

The Problem with Two Versions

The first thing I tried was to add A and AAAA DNS records for both versions. While that does work, there's a problem with this approach. Google and other search engines get confused because it looks like there are two versions of my website.

When Google tries to index my website, there's no clear answer to which is the canonical version.

So what can we do instead?

Improve Things with Redirects

Since we have two versions, we can redirect one to the other to improve things. This tells web crawlers which version is the main one. I used a Cloudflare rule to redirect the www version to the non-www version.

Note: I had to include DNS records and add a redirect rule for things to work correctly.

Here's how you can do it too.

Steps to Set Up the Redirect

Note: Make sure to use your own website in place of mine.

1. Log into your Cloudflare account

2. Go to Rules > Redirect Rules

   

3. Click Create rule under Single Redirects

4. Name your rule (I named mine "WWW to Non WWW")

5. Set up a custom filter like this:

   • Field: Hostname

   • Operator: equals

   • Value: www.thesshguy.com

   • URL redirect Type: dynamic

   • Expression: concat("https://thesshguy.com", http.request.uri.path)

   • Status Code: 301 (permanent redirect)

Here's what my rule looks like:

And that's it!

Now your www version will redirect to the non-www version. Hopefully, this helps you set up your own Cloudflare redirects!

The introduction of hooks made state management much easier in React.

With the useState hook, you're given a tuple where the first element is the current state and the second element is a function used to update that state. For primitive types like strings, using this hook to manage the state is straightforward.

But what about complex data types, like arrays?

The main thing to remember when working with arrays in React is that you don't want to mutate the array. React can't detect the change, so your UI won't update how you expect it to:

In this example, each button is supposed to double the value shown. But when you click the Mutate Array button, nothing seems to happen. This is because we're mutating the state and then calling setList with the same array reference. Because the reference is the same, React thinks the array hasn't changed and bails out of the re-render.

This is an optimization that React does internally where if you pass the same state as the current state to the updater function, React ignores the update.

Note: If you click the Mutate Button a few times and then click the Update Button, you'll notice that the value more than doubles. This is because both buttons reference the same list variable.

Technically the Mutate Button does update the value, React just doesn't know about it until the Update Button is clicked and setList is called with a new array reference.

So how do you handle this?

When updating arrays in React state, create a new array.

Instead of mutating the existing array, use it as the starting point to create a new array.

Let's take a look at a few examples:

How to add an element to an array

function ListOfNumbers() {
    const [list, setList] = useState([1]);
    return (
        <div>
            {/**
              * It's not a good practice to use the index
              * as the key, but hey this is just an example.
              */}
            {list.map((item, index) => <span key={index}>{item}</span>)}
            <button onClick={() => setList([...list, Math.random()])}>
                Add Item
            </button>
        </div>
    );
}

In this example, when you click the button element, we:

1. Create a new list

2. Spread the existing list into the new list

3. Append a random number to the end of the list

The spread operator is a quick way to create a new array using the values of an existing array.

How to remove an element from a list

function ListOfNumbers() {
    const [list, setList] = useState([1, 2, 3, 4]);
    return (
        <div>
            {list.map((item, index) => <span key={index}>{item}</span>)}
            <button onClick={() => setList(list.slice(1))}>
                Remove First Item
            </button>
        </div>
    );
}

This time when the button is clicked, we slice off the first element. The slice array method returns a copy of the original array, which makes it safe to use with React state.

Note: On the other hand, the splice array methodmutates the existing array and is therefore not a good fit for React state management.

How to update elements in an array

Let's say we have a list of numbers and want to double each array element when you click a button. In this case, we can use the map function to handle this:

function ListOfNumbers() {
    const [list, setList] = useState([1, 2, 3, 4]);
    return (
        <div>
            {list.map((item, index) => <span key={index}>{item}</span>)}
            <button onClick={() => setList(list.map(item => item * 2))}>
                Double Items
            </button>
        </div>
    );
}

What if we wanted to update a specific array element? Luckily you can use the map function for this too!

function ListOfNumbers() {
    const [list, setList] = useState([1, 2, 3, 4]);
    return (
        <div>
            {list.map((item, index) => <span key={index}>{item}</span>)}
            <button onClick={() => {
                setList(list.map(
                    (item, index) => index === 2 ? item * 2 : item
                ));
            }}>
                Double Items
            </button>
        </div>
    );
}

Notice how we're checking the index in our map function and we only double the item if it's the 3rd element (arrays start with the index 0).

How to safely mutate an array

Let's say you're trying to update your array and the easiest option to solve your problem is to reach for a built-in utility that mutates your array. For example, maybe you want to reverse the order of your array using the reverse array method. Since I said don't mutate your arrays, what should you do?

Make a copy of your array first!

The easiest thing to do is to use the spread operator to create a new copy of the array first. After you make the copy, you're free to mutate it however you want:

function ListOfNumbers() {
    const [list, setList] = useState([1, 2, 3, 4]);
    return (
        <div>
            {list.map((item, index) => <span key={index}>{item}</span>)}
            <button onClick={() => {
                const listCopy = [...list];
                listCopy.reverse(); // It's safe to mutate the copy
                setList(listCopy);
            }}>
                Reverse Items
            </button>
        </div>
    );
}

While the approach above will work in most cases, there's one major flaw.

The spread operator only creates a shallow clone of the original array. In other words, if you have an array of objects, each object within the cloned array will still reference the same object as the original array.

So how do you update objects within an array?

You do the same thing you did to update the array. You make a copy of the object you want to update using the spread operator:

function ListOfPeople() {
    const [list, setList] = useState([
        { id: 1, name: 'Jack' },
        { id: 2, name: 'Jill' }
    ]);

    return (
        <div>
            {list.map((item) => <span key={item.id}>{item.name}</span>)}
            <button onClick={() => {
                // This creates a new object for each item,
                // copies the old object, and updates the name.
                setList(list.map(item => ({
                    ...item,
                    name: item.name.toUpperCase()
                })));
            }}>
                Capitalize Names
            </button>
        </div>
    );
}

Awesome!

Now let's put all that together and take a look at a live running example:

The useState hook is a basic building block for state management in React.

Using the hook is pretty straightforward. The function returns a tuple with the current state and a function to update the state. Here's a basic example:

In this example, we're managing state for a comment variable. We use the state to populate the input and then use the setComment state updater to update the state when the input changes (i.e. you type into the input field).

Ok!

So managing state seems pretty easy, but what if you want to run some code whenever your state changes? Luckily React has you covered!

The useEffect hook runs when its dependencies change

We can use the useEffect hook for this exact purpose. The hook takes a list of dependencies as its second argument and executes the effect whenever a dependency changes.

In other words, you can pass the state variable to the dependency list and execute your code in the effect.

Here's what that might look like:

This time, as you type into the input above, there's an effect that runs anytime the comment variable updates. This effect logs the input field's value every time it changes. This is a pretty basic example, but it shows you how to run code when your state changes.

Combining useState and useEffect in React can be super helpful!

These hooks make it easy to manage state and run code when things change. With these tools, you can build apps that work well and do what you expect. It's simple and effective!

Before indexing a page, Google needs to crawl your website.

Google uses bots called crawlers to find pages to index. Once the crawler finds your page, the next step is to index it.

During the indexing process, Google parses your page's HTML. During this step, the HTML is inspected for semantic issues or invalid HTML tags. These issues might be fixed, but in some cases, HTML tags might be dropped entirely if they're in the wrong place.

With this said, it's important to keep in mind that properly structured HTML is essential for effective indexing.

Google analyzes content and collects signals

The indexing process also involves steps to analyze the textual content, key content tags, attributes, images, and videos on your page. Google also collects signals that help determine your page's relevance and ranking in search results. Some of these signals include:

• Is a web page the canonical page

• What language is the page in

• How useable is the page

A canonical page is used to represent a group of duplicate pages.

Sometimes you might have duplicate or similar content on several pages. Google groups these pages through a process known as Duplicate Clustering and chooses one to be the canonical version that represents this cluster. Google indexes this canonical version, while the other versions may still be served in different contexts.

The quality of your page's content is key.

Once duplicate web pages are handled, Google will inspect the quality of the content on the page it's trying to index. If the quality of the content is poor, then Google may not index the page. In other words, indexing is not guaranteed. Only high-quality canonical pages are indexed.

Outside of ensuring your website has high-quality content, your pages might not be indexed based on other technical requirements. To be eligible for indexing, the following must be true for your page:

• The Googlebot crawler must not be blocked

• It must return an HTTP 200 status code

• The content must be indexable

Your page might be removed for spam policy violations.

It's important to ensure your content complies with Google's spam policies. The following can all get your pages removed:

• Cloaking: presenting different content to users and search engines

• Keyword Stuffing: filling a page with keywords or numbers to manipulate your ranking in Google Search

• Sneaky Redirects: redirecting users or search engines unexpectedly to show them different content than what they intended to see

Indexing is an important part of the SEO process. Understanding how to optimize this process, ensuring you produce high-quality content, and following best practices can improve your site's ranking on Google Search.

One of the new features in React 19 is the use API.

The basic idea is that the use API can fetch resources during React's render cycle. Instead of doing something like fetching data in an effect and updating the component state, we can get the data directly via the use API.

When paired with React's Suspense component, we can easily manage conditional rendering:

In the example above, the App component gets a getCommentsPromise, which is eventually passed to the use API in the Comments component. The promise takes some time to resolve, which means we should probably show a loading state.

The good news is that we don't have to manage this ourselves. Because the use API works seamlessly with the Suspense component, we can provide a fallback and things just work!

Context values can be conditionally loaded with the use API.

Normally, you would need to use the useContext hook to get the value of a Context provider. The problem with this approach is that this hook has to follow the Rules of Hooks.

The relevant rule is that we can't call a hook conditionally.

The use API, on the other hand, doesn't have this restriction. We are free to load a Context value however we want:

In this example, notice how the UserBanner component reads the UserContext value if the showUser prop is true. In other words, if this prop is false, then we don't call the use API.

This is the key difference!

If we were to use the useContext hook, then we wouldn't be able to do this. We would have to put the hook at the top of the component and always read the context value regardless of whether we use it in the final JSX.

How do you handle errors?

So what if the resource you're loading throws an error? Maybe there's an auth error or a timeout. The good news is that handling an error with the use API is straightforward!

You have two main options:

1. Use an error boundary

2. Catch the error and return a different value

Here's an example using an error boundary:

import { use, Suspense } from 'react';
import { ErrorBoundary } from 'react-error-boundary';

export function Comments({ getCommentsPromise }) {
  return (
    <ErrorBoundary fallback={<p>Oh no! Something went wrong!</p>}>
      <Suspense fallback={<p>Fetching Comments!</p>}>
        <Comment commentPromise={getCommentsPromise} />
      </Suspense>
    </ErrorBoundary>
  );
}

function Comment({ commentPromise }) {
  const comment = use(commentPromise);
  return <p>{comment}</p>;
}

The use API must be called within the render cycle.

One thing to keep in mind is that the use API has to be called in a component's render cycle. This is similar to hooks. The key difference is that you can leverage the use API conditionally. Outside of that, you can also easily manage loading and error states.

And that's it!

React 19's use API is a simple and powerful tool to handle loading data asynchronously, loading context values, and conditionally rendering JSX.

Crawlers find webpages and make them searchable.

Google enlists the help of specialized bots called crawlers to do this. Once the webpages are found, Google can index them and make them discoverable for other people through its search interface.

A crawler is an automated program that works by:

1. Browsing the internet

2. Downloading web pages

3. Extracting links for further crawling

The first step is URL discovery.

Google is constantly looking for new and updated pages to add to its list of known pages. It uses the following methods to do this:

1. Following links from already known pages

2. Using sitemaps submitted by website owners

The first method is pretty basic. Find a website and navigate to any links that the website has on it. The second method might not be familiar to you, but sitemaps play a significant role in helping Google discover your web pages.

A sitemap is a collection of URLs to pages on your site and can include additional metadata.

Sitemaps aren't mandatory, but they can drastically improve Google's ability to find your content. You can create and submit a sitemap to Google to ensure your pages are crawled and indexed efficiently.

How does Google's crawler work?

Google's crawler uses an algorithmic process to determine:

1. Which sites to crawl

2. How often to crawl a site

3. How many pages to fetch from a site

Google uses an algorithm to determine these things to avoid overloading a website's resources. Every website is different. A website's response times and overall quality of content determine the crawling behavior.

Once a URL is discovered, Google renders the page to view dynamic content.

After the crawler discovers a URL, it fetches the page and its resources to determine what's on it.

Part of this process involves displaying and executing the code returned to generate a visual representation of the website. The content on your page might load dynamically via JavaScript, so Google needs to render the page to see what a user would see.

The Google Search crawling process is key to getting your web pages found and searchable. By understanding how Google's crawler finds, fetches, and shows pages, and by using tools like sitemaps, you can boost your site's SEO and make it more visible in search results.

React 19's useOptimistic hook lets you update your UI to its expected state after an asynchronous action while the action is still in progress.

Imagine you have an app that lets you add comments to some published content. When you add a new comment, a network request is made to the server to create the comment in the app's database.

This process takes time, so you need to account for this in your UI state. The flow might look something like this:

1. Make a POST request to create a new comment

2. Show a loading spinner in your UI

3. After the POST request finishes, make a GET request to fetch the latest list of comments, which should include your new comment

4. Remove the loading spinner and show the updated comments

The useOptimisitic hook makes your UI feel snappier

Instead of showing a loading spinner and waiting for all your requests to resolve, you can use the useOptimistic hook to immediately add the comment. If the request fails, you can remove the comment and show an error message. The happy path feels much faster and it's easy to recover from the failure path.

The example below shows how this might work by combining the new useActionState hook with the useOptimistic hook.

If you're unfamiliar with how the useActionState hook works, you can learn more in my post about React 19 actions and form actions.

You'll notice we show a loading message when you submit a comment. But that's not the only thing we do. We also immediately show the comment in the comment section because we update the optimistic value. This optimistic value has an extra unsaved property that we use to style the comment differently.

Once the request finishes, we update the actual comments state which includes the newly created comment. This time, however, the comment isn't in an unsaved state, so it's styled normally.

To handle errors, we show a toast message and return the old list of comments. When the component re-renders, the useOptimistic hook will detect this, which will remove the optimistically added comment.

To try this out, you can pass the text error to the comment form.

And that's it! Hopefully, this post helps you build snappier UIs with React 19's new useOptimistic hook!

React 19 makes it way easier to manage state and data mutations! This is made possible with the introduction of "Actions" which are functions that use async Transitions.

Actions Reduce Boilerplate

Actions let us skip the manual process of handling pending states, errors, and optimistic updates. If you pass an async function to a transition, React can take over and manage all of this for you.

The easiest way to do this in a component is with the useTransition hook:

In the example above, notice the Add Post button starts a transition when it's clicked which creates a new post. Because this is an asynchronous process, there's a bit of a delay. While the post is being created in the background, the isPending variable flips to true, which we use to show a loading state.

Introducing Form Actions

If the changes in the useTransition hook weren't cool enough, React 19 also has updates to make it easier to manage forms.

The new useActionState and useFormStatus hooks make it easier to work with form submissions. In the last example, we had a separate useState hook for the posts state and a useTransition hook to update the posts state. With form actions, these two things can be rolled into one:

Notice that we're passing a function to the form's action prop. Normally, this should be a string like POST. This might seem a little weird, but it lets us simplify common use cases.

Here's how it works.

The useActionState hook takes an "Action" and the initial state. The "Action" is an asynchronous function that takes the previous state and the formData and then returns the next state.

The useActionState hook returns the current state, a function to invoke the action, and an isPending state that's true when the Action is executing.

What if we want to know a form is submitting somewhere else in the React component tree?

This is where the useFormStatus hook comes into play. This works similar to Context values in React. Because the SubmitButton is nested inside the form element, we can use the hook to get the pending state of the Action. In this case, we disable the button while a post is created.

And that's it! A quick look at Actions and Form Actions. Hopefully this helps you take advantage of some really cool features in React 19.

The basic idea of a loader function is that it lets you fetch data before rendering your route.

In other words:

1. A user navigates to a page

2. A loader runs to fetch data for that page

3. The page’s component renders with the fetched data

React Router is built on browser standards

Loader functions are no exception! Since this is the case, it's common to return web Responses from a loader function. To make this easier, the library provides a json utility for when you need to return a JSON payload from a request.

Keep in mind that React Router works by intercepting requests made to your server and sending intercepted GET requests to your loader functions. From there, you have better control over the client-server interaction.

An example is worth 1000 words, so let's jump right in!

In the example below, we have a Home route and a Projects route. Each route has an associated loader function that returns a Response for that route.

As you click each link, notice the slight delay before the next page renders. This is from the sleep utility in each of the loader functions. In other words, the loaders return their data, and then the page is rendered.

To help demonstrate this, a loading message appears in the top right corner when any loader function is executing.

You've probably heard the term "pure function" before, but if not, it's a function that follows two principles:

1. No Side Effects: a pure function must not alter any objects or variables that exist before it's invoked

2. Deterministic: a pure function must always return the same output when given the same set of inputs

In other words, you can tell if a function is "pure" if it's consistent and doesn't affect anything outside its scope.

An add function is a basic example of a pure function:

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

In the example above, the add function always returns the same result when you give it a specific set of inputs. 2 + 3 will always equal 5 (if for some reason it doesn't, then we probably have bigger problems).

React assumes functional components are pure

If your React components aren't pure functions, that'll likely lead to unpredictable and buggy applications. In other words, given the same set of props (i.e. inputs), your component should always return the same JSX (i.e. output).

Let's take a look at an example:

In the example above, the Banner component takes a name prop and displays a welcome message.

Given a specific value for the name prop, the JSX the Banner component returns will always be the same. If you pass the name Jack to the Banner component, it's impossible for the text to be anything other than Hello Jack!.

Impure components lead to inconsistent JSX

An impure component can lead to unexpected behavior:

This time, the Banner component takes a time variable defined outside of it and displays it along with the name. We use time % 12 to convert the time to a range between 1 - 12 and then add AM or PM to indicate whether it's morning or night.

However, because the first Banner component modifies the time component, the second Banner component shows AM instead of PM. When the first Banner component renders, it sets the time variable to 11 (i.e. 23 % 12 === 11), which the second Banner component then uses.

Note: If you run this with StrictMode enabled, it will actually show 11 AM for both Banners because React renders each component twice in a dev environment.

Access variables via props instead of via closures

In the example above, the Banner component has access to the time variable via a closure. Instead of doing this, you can fix the problem by just passing the time as a prop instead:

Mutating local variables is okay!

Remember, pure functions must not alter any objects or variables that exist before they're invoked. This means a pure function can update an object or variable that's created when it's invoked. In other words, you can update local variables all day long without making the function impure!

The following is perfectly acceptable:

type BannerProps = { name: string; time: number };

function Banner(props: BannerProps) {
    let time = props.time;
    if (time > 23) {
        time = 0;
    }

    const isPM = time > 11;
    time = time % 12;

    return (
        <p>
          Hello {props.name}, it's {time} {isPM ? "PM" : "AM"}!
        </p>
    );
}

In this example, if the time variable is greater than 23, we reset it back to 0. You can see that throughout the component, we're updating the time variable in several places. This is completely fine because the time variable was initialized inside the Banner component.

Why are pure components important in React?

Here are a few reasons why keeping your React components pure is beneficial:

1. Predictability: Pure components are predictable, making debugging easier.

2. Performance: Pure components are cacheable, which lets React optimize rendering (i.e. skip renders when inputs haven't changed).

3. Server-Side Rendering: Pure components are deterministic, so your server can reuse them for many requests.

4. Concurrent Mode: React can optimize rendering by pausing and resuming the render cycle without issues because pure components don’t rely on side effects.

It's important to make sure your components are pure. If you don't, your applications will be harder to maintain and less reliable in the long run!

Flexbox is a CSS layout module that helps you create responsive designs. When used with Tailwind, you can build these designs faster and more efficiently. In this post, we'll explore how to do that through interactive demos.

The first step to enable Flexbox is to use the flex class:

<div class="flex">
  <!-- Flex items go here -->
</div>

By default, Flexbox uses a row or horizontal layout, but if you want to be specific, you can use the flex-row class. To switch to a vertical layout, you can use the flex-col class instead.

Try swapping between the classes below to see how the layout updates:

Great!

Now we can control the direction our elements are placed on the page. But what if we want to move the elements along the main axis?

The main axis is horizontal for row and vertical for column

To do this, you can use one of the following classes: justify-start, justify-center, justify-end, justify-between, justify-around, or justify-evenly. Try changing the class below to see what happens:

Note: Try changing to a column layout above to see how it affects the main axis

Now that we can move the elements along the main axis, what about the cross axis? The cross axis is the other direction depending on which layout you choose. In other words, it's vertical for row layouts and horizontal for column layouts.

To position elements along this axis, you can use one of the following classes: items-start, items-center, items-end, items-baseline, or items-stretch. Try changing the class below to see what happens:

Note: Try changing to a column layout above to see how it affects the cross axis

Okay, great. So we can move our elements in two directions, but all the elements move together. What if we want to change the position of just one element?

Luckily this is easy to do with Flexbox. In Tailwind, you can position an element along its cross axis using these classes: self-auto, self-start, self-center, self-end, self-baseline, or self-stretch. Try changing the class on the second div below to see what happens:

Note: Flexbox doesn't support aligning a single item along the main axis. This is because Flexbox is always focused on moving the entire group of items.

Okay! Now let's look at how to control the size of child elements within a Flexbox container.

To control the flex-grow, flex-shrink, and flex-basis properties, use flex-grow-0, flex-grow, flex-shrink-0, flex-shrink, flex-none, flex-1, flex-auto, or flex-initial.

Here's an example of how the flex-shrink-0 property prevents the second div from shrinking below its width:

If you switch to flex-shrink, you'll notice that the second div becomes slightly smaller. If you want to make the div even smaller, you can use an arbitrary value like this: flex-shrink-[2].

Finally, if you want to alter how your Flexbox wraps, you can use flex-wrap, flex-wrap-reverse, or flex-nowrap. Try switching flex-wrap to flex-wrap-reverse to see how the page updates:

And that's it!

This was a quick overview of how to use Flexbox with Tailwind. Hopefully, this makes it easier for you to build awesome responsive designs using Tailwind!

Hey everyone!

I've been working on a side project called Kempo. It's a tool that lets you create custom coding playgrounds, which you can embed in blogs, documentation, or other teaching resources.

It's built on top of Sandpack

Kempo is powered by CodeSandbox's Sandpack live coding editor. Here is what it looks like:

So why not just use Sandpack or CodeSandbox directly?

For starters, Sandpack is an npm package that exposes a React component that lets you build these custom editors. The problem is that on a blogging platform like Hashnode, you don't have the flexibility to insert your own React components in your blogs. Even if you could, you'd have to spend time designing and customizing the editor experience.

On the other hand, while CodeSandbox does let you embed code playgrounds, you don't have much flexibility in terms of how your playground looks.

Kempo allows different layouts based on screen size

For example, on desktop screens, you might want to display an editor and a preview panel that are split vertically:

However, on a mobile screen, you might want to display the same content, but split it horizontally instead, since there is less screen space available:

Note: The examples above are designed to show different layout views and do not change based on screen size.

With Kempo, this is easy to do using Kempo's Layout Editor:

You can define different layouts for three screen sizes (small, medium, and large).

You can also use this feature to highlight different parts of your playground. For example, you might want to show the preview first, which you can do by setting it first in the Layout Editor:

Kempo supports different components

For now, Kempo supports the following Sandpack components:

1. Editor

2. Preview

3. Console

You've already seen the Editor and Preview components in the examples above. The Console is a lightweight version of the browser console that lets you print logs from your editor:

Try changing the log statement above to see how the logs update.

Kempo supports different themes

Kempo offers four built-in themes that let you customize your playgrounds to better suit your needs. You can choose your theme on the project settings page:

Here's an example of the Dracula theme:

And here's one with the Gruvbox (Dark) Theme:

Next Steps

While Kempo is still a work in progress, I plan to use it for my blog. I also plan to keep building in public and share more updates about the technical details behind its features and the challenges I encounter.

If you're interested in checking it out, you can get started at Kempo.io.

The modern web is full of spam bots.

Bots are automated "users" that are programmed for specific tasks. While some bots are good, such as bots designed to monitor website health, many bots are created for malicious reasons. For example, spam bots are created to post potentially harmful content wherever possible. This can lead to a strain on your server resources and lead to unnecessary data populating your databases.

Spam bots can achieve their goal by abusing HTML forms, which exist on almost every non-trivial website. This is how the bot might work:

1. It inspects the page and looks for HTML form elements

2. It populates dummy data into the input fields

3. It submits the form to the server

In other words, it mimics a normal user's behavior but provides information your application may not care about.

So what can we do to stop these bots?

Honeypot fields can trick spam bots

A honeypot field is a special input field hidden from real users, but visible to spam bots. These fields are hidden visually on the page and from screen readers, preventing most real users from filling them out. On the other hand, a spam bot works by inspecting the DOM and filling out any input fields it finds.

In other words, a spam bot will fill out fields even when it shouldn't be possible. This means all you need to do is reject any submissions on your server where the honeypot field was filled out.

In the example above, you can see that we have a hidden field that indicates you shouldn't fill it out. Normally, you wouldn't be able to see the field, but if you end up in a state where the field is visible, you'll know that you should leave it alone.

You might be thinking that this is too obvious and a spam bot would know not to fill out the field, but it turns out that most spambots aren't too sophisticated and this is usually enough to trick them.

And that's how honeypot fields work. The next time you want to stop spam on your website, try reaching for a honeypot!

A key part of building any non-trivial front-end application involves managing user interactions.

React applications are no exception. When a user performs an action, it triggers an event that can be handled. What sets React apart is the way it manages these events. Understanding these differences will make it easier to build interactive React applications.

Keep these 5 tips in mind when handling events in React:

TL;DR

1. Don't Execute Functions; Pass References.

2. Wrap Functions That Take Arguments.

3. Use CamelCase for Event Handler Props.

4. Events Bubble Upwards but are Captured Downwards.

5. Beware of Default Browser Event Handlers.

1. Don't Execute Functions; Pass References.

When you pass a function to an event handler, make sure you pass a reference to the function. A common problem I've seen is that a developer will execute the function instead of passing a reference:

const breakApp = () => { /* Stuff */ };

function MyComponent() {
    return <button onClick={breakApp()}>Push to Break</button>;
}

The breakApp function is executed immediately during MyComponent's render cycle instead of when the button is clicked. Unfortunately for your users, this means they don't get the satisfaction of getting to break the app themselves. They're stuck with a broken app from the start.

So how do you fix the app, so that your users can break the app?

Just don't execute the function.

Instead, pass a function reference to the event handler. This will give React a chance to remember the function and execute it sometime in the future:

const breakApp = () => { /* Stuff */ };

function MyComponent() {
    return <button onClick={breakApp}>Push to Break</button>;
}

Passing a function reference to the event handler is easy enough to do, but there's a small problem. What if you want to pass arguments to your function? Keeping with the theme above, let's say that breakApp shouldn't work 100% of the time.

Instead, we'll pass a random number to breakApp, and based on that number, the function will succeed or fail. Once again, we need to make sure to pass a function reference to the event handler, so this won't work:

const breakApp = () => { /* Stuff */ };

function MyComponent() {
    const rng = randomNumberGenerator();
    return <button onClick={breakApp(rng)}>Push to Break</button>;
}

Luckily, this is easy to fix.

All you have to do is...

2. Wrap Functions That Take Arguments.

You can't pass arguments to event handler functions.

At least not directly.

So now what?

Remember, you just need to pass a function reference to your event handlers for things to work correctly. So let's do that. Wrap your function that takes arguments with another function that just executes the first one.

Yes. Yes.

It's functions all the way down:

const breakApp = () => { /* Stuff */ };

function MyComponent() {
    const rng = randomNumberGenerator();
    const wrappedFunction = () => breakApp(rng);
    return <button onClick={wrappedFunction}>Push to Break</button>;
}

Instead of executing breakApp immediately, it's wrapped by another function called wrappedFunction. Since wrappedFunction doesn't take any arguments, we can safely pass it to the onClick event handler.

3. Use CamelCase for Event Handler Props.

Most JSX attributes use camel case, and event handlers are no exception. This is different than standard HTML which uses lowercase for event handler names. In other words, you want to make sure to write onClick with a capital C instead of onclick:

// Wrong! `onclick`
function BadComponent() {
    return <button onclick={breakApp}>Push to Break</button>;
}

// Right! `onClick`
function GoodComponent() {
    return <button onClick={breakApp}>Push to Break</button>;
}

This is an easy mistake to make when you first start writing React code. Luckily React will warn you when you make a mistake like this, so it should be easy to recover from.

4. Events Bubble Upwards but are Captured Downwards.

Great!

So now you know how to attach an event handler to an element. But what if you wanted to track events for a group of elements? While you could attach an event handler to each element, there's another way.

Events bubble up the component hierarchy.

This means when you click on an element, not only will React execute the element's onClick handler, but React will also execute every parent element's onClick handler.

Let's take a look at the example below.

Try clicking on each of the numbered blocks and also on the background.

Notice how there's only one event handler in the code above that's attached to the div element that wraps the button elements. Even though the buttons don't have onClick handlers, an event bubbles up to the parent element when you click one.

This lets us handle all the events in one place.

This behavior is consistent for all React events, except for the onScroll event.

So what if you don't want an event to bubble up to a parent element? Don't worry, React has you covered. All you need to do to opt out of this behavior is to stop the event from propagating:

This time, button one has its own event handler. When you click this button, the first thing we do is call event.stopPropagation(). This tells React to make sure it doesn't execute the onClick handler for any parent elements.

Now when you click button one, we only log the text in the button's handler.

But what if you still want the parent to respond to the button click?

In rare cases, you still might want to handle the button click from a parent handler.

Let's say you were using a 3rd party button component that calls event.stopPropagation() internally when clicked. In this case, you can't remove that code because you don't own it. In other words, there's no way for you to handle the click from a parent element...

...or is there?

You can capture the event.

React captures events down the element hierarchy.

You can attach special event handlers to your React components that let you handle an event even if a child element calls event.stopPropagation().

All you need to do is add the word Capture to the end of your event handlers. For click events, the handler is called onClickCapture. To understand why this works, we need to take a closer look at the order in which these event handlers are executed:

When you trigger an event (e.g. by clicking a button), it moves in the following way:

1. It moves down the element hierarchy, calling onClickCapture for every element

2. It calls the onClick event handler for the element you clicked

3. It moves up the element hierarchy, calling onClick for every element

This works because your code runs during step 1, but event.stopPropagation() prevents step 3.

Try clicking on the button in the example below. It should log the order of the event handlers.

5. Beware of Default Browser Event Handlers.

Some events have a default browser implementation.

If you're not careful, this can lead to some unexpected behavior. For example, most browsers refresh the entire page for the form element's onSubmit event.

For Single Page Applications, it's common to prevent this behavior and handle the submission yourself.

Luckily, it's easy to do this with React:

function MyForm() {
    function onSubmit(event) {
        event.preventDefault();
        // Do other form stuff after...
    }

    return (
        <form onSubmit={onSubmit}>
            {/* Form stuff goes here */}
        </form>
    );
}

The call to event.preventDefault() prevents the browser's default implementation.

In the example below, the second form prevents the browser's default implementation while the first form doesn't. Try clicking both submit buttons to see the difference.

When the first button is clicked, the entire page refreshes.

To make this more obvious, enter a value into the input field and then submit the form. When the page refreshes from the first button click, we lose the value stored in the input element.

preventDefault vs stopPropagation

One thing to keep in mind is that while it may seem like there's some overlap between preventDefault and stopPropagation, both methods have different purposes:

• preventDefault: This has to do with preventing the browser's event handlers

• stopPropagation: This has to do with preventing the developer's event handlers on a parent element

If you've written any code, you've probably come across control flow.

But what is it?

Here's what MDN says about control flow:

The control flow is the order in which the computer executes statements in a script.

So control flow describes what parts of your code run and in what order. Cool...but that's not that interesting. It would be more valuable if we could manipulate the control flow and change your code's execution order.

Luckily most programming languages have built-in ways to do this.

While React isn't a programming language in its own right, it relies heavily on the fundamentals of JavaScript. Understanding how JavaScript deals with control flow will help you write flexible React components that change how they render.

There are 3 core ways to control how your components render.

1. The if/else statement

The most common conditional is the basic if/else statement:

function myFunc(name) {
    if (name === 'thesshguy') {
        return 'Cool';
    }
    return 'Not Cool';
}

An if/else statement lets you return early when some condition is met. This same principle can be used in your React components. You can return different JSX elements based on the value of a prop:

Notice how we return different JSX based on the name prop.

Try changing the names to see what happens.

2. The ternary operator

If you've never seen a ternary operator before, it might look a little confusing at first.

The ternary operator takes three inputs and returns a single value. The three inputs are a condition, a truthy value, and a falsy value. Truthy and falsy just mean values that are considered true or false when converted to a Boolean.

All ternary operators follow the same format in JavaScript:

1. A condition followed by a ?

2. An expression to execute if the condition is truthy followed by a :

3. An expression to execute if the condition is falsy

Note: If that's still not clear, you can use the handy acronym W.T.F. to help you remember: what (cond) ? true : false.

function myFunc(name) {
    /*
     * W.T.F.
     * 1. What: name === 'thesshguy'
     * 2. True: 'Cool'
     * 3. False: 'Not Cool'
     */
    return name === 'thesshguy' ? 'Cool' : 'Not Cool';
}

If that sounds familiar, it should.

The ternary operator is often used as an alternative to the if/else statement.

Let's rewrite the example above using a ternary operator:

Easy!

But why would you ever choose to use the ternary operator? Is the only difference the syntax, or are there other benefits?

Great questions!

Ternary operators can be used in JSX

One drawback of the if/else statement is that it can't be used inside of JSX:

function MyComponent() {
    return (
        <div>
            {
                if (someCondition) {
                    return 'True';
                }
            }
        </div>
    );
}

The reason you can't do this has to do with how JSX is converted to HTML under the hood. If you want an in-depth explanation, you can read my post about how React converts JSX to HTML. If you want to skip that post (I totally understand if you do 🙂), here's a quick recap.

When your React code is built, the above gets converted to the following:

function MyComponent() {
    return React.createElement(
        'div',
        {},
        if (someCondition) {
            return 'True';
        }
    );
}

A JSX element's children are passed as arguments to React.createElement.

The issue is that an if/else statement can't be used as a value in JavaScript. It can't be passed as a function argument. Since it doesn't have a value, JavaScript can't do anything with it.

It's not a limitation with React, but rather a limitation with JavaScript.

On the other hand, a ternary operator can be used in JSX for the same reason. It resolves to a value that can be passed to React.createElement. This means the following will work:

Another benefit is that this pattern lets us DRY up our code. We don't need to repeat the <div></div> for both conditions.

3. The Logical AND (&&) operator

The final way to render things conditionally in React is with the Logical AND (&&) operator.

The Logical AND takes two inputs separated by the && operator. If the first value is truthy then the second value is returned. If the first value is falsy then the first value is returned:

function LogicalANDExample() {
    return true && 'Hello'; // returns 'Hello'
    return false && 'Hello'; // returns false
}

This same idea can be used to render JSX elements in a React component. If you make the second value a JSX element, you can conditionally render it based on the first value:

If props.name equals the string thesshguy, we return the JSX, otherwise, we return false.

It should be clear why the second div no longer shows up. The condition is false so we don't return the div in that case. But what about the value that we are returning?

What the heck happened to the false value and why didn't React render it?

React doesn't render (some) falsy values

Let's say you have a situation where you don't want to render anything.

React allows for this by letting you return certain falsy values. The most common value that's used for this is null:

function EmptyComponent() {
    return null;
}

function App() {
    // I do not render anything
    return <EmptyComponent />;
}

This is also the case for undefined and false, which is why in the example above, nothing is rendered for the second <CoolChecker name="otherguy" /> element.

What about 0?

One thing that trips up new React developers is the value 0. While it is**falsy*, when you use it as the first value of the Logical AND operator, React still* renders it:

This can be a bit confusing at first, but it makes sense why React would do this.

There are legitimate reasons why you'd want to render 0. For example, maybe you want to show a countdown on the page. If React didn't render 0, you'd have to convert it to a string first.

So how do you get around this issue?

The easiest way is to make sure you return false instead:

function RenderCount(props) {
  return props.count > 0 && <div>Count is {props.count}</div>;
}

One way to do that is with a comparison operator like greater than. Not only does props.count > 0 always return a boolean, it also makes the intention of the code more clear.

Win-Win!

Conditionals for JSX assignment

JSX isn't limited to return statements.

You can assign JSX to a variable. This lets you reuse the JSX in multiple places and keeps the code clean. Variable assignment can take advantage of all the conditional logic that's been mentioned above:

function MyComponent() {
    let first;
    if (someCond) {
        first = <div>The if/else statement is true!</div>;
    }

    const second = (
        <div>
            The ternary is {someCond ? 'true!' : 'false!'}
        </div>
    );

    const third = someCond && <div>The Logical AND is true!</div>;

    return (
        <div>
            {first}
            {second}
            {third}
        </div>
    );
}

What's great about all the examples above is that they rely on standard JavaScript functionality.

By learning how to manage control flow for your React components, you become a better JavaScript developer!

If you've done any UI development, you've probably had to build a list or two.

What do I mean by a list?

Let's take Twitter as an example.

When you log onto Twitter, you're presented with a feed that contains an endless list of Tweets. In other words, a list is a series of similarly structured content that's placed one after the other.

In this post, we'll take a look at how to build lists effectively in React.

The naive approach would be to hardcode each element in the list:

function Feed() {
    return (
        <div>
            <span>I am tweet 1</span>
            <span>I am tweet 2</span>
            <span>I am tweet 3</span>
            <span>I am tweet 4</span>
        </div>
    );
}

This approach has a few problems.

Duplicate code is error-prone and hard to read

The example above is simple.

You can add a new Tweet by creating a new <span /> element. But this isn't a real-world scenario. What do things look like when the JSX is a little more complex?

function Feed() {
    return (
        <div>
            <div>
                <span>@username</span>
                <span>I am tweet 1</span>
                <span>created timestamp</span>
                <div>
                    <span>Like</span>
                    <span>Retweet</span>
                </div>
            </div>
            <div>
                <span>@username</span>
                <span>I am tweet 2</span>
                <span>created timestamp</span>
                <div>
                    <span>Like</span>
                    <span>Retweet</span>
                </div>
            </div>
            <div>
                <span>@username</span>
                <span>I am tweet 3</span>
                <span>created timestamp</span>
                <div>
                    <span>Like</span>
                    <span>Retweet</span>
                </div>
            </div>
            <div>
                <span>@username</span>
                <span>I am tweet 4</span>
                <span>created timestamp</span>
                <div>
                    <span>Like</span>
                    <span>Retweet</span>
                </div>
            </div>
        </div>
    );
}

This code is a mess...and we're only 4 Tweets in!

Now if you try to copy the code to make a new Tweet, you're more likely to miss something. This code is also harder to maintain.

You can't hardcode JSX for dynamic data

It's clear the code above is too messy, but there's a more serious problem.

You may have already realized it, but for a website like Twitter, it's not possible to hardcode the JSX. Tweets are created dynamically. You won't have the information ahead of time to write the JSX.

Instead, the JSX is created on the fly from Tweets fetched from a database.

Using dynamic lists will solve both problems.

Great!

But how do you do that?

React doesn't have any built-in utilities to create lists. Instead, it's recommended you leverage standard JavaScript array methods. The most common method used is the map method.

But before we get to that, it's important to understand how React renders arrays:

Notice how the children passed to the div is an array that contains two JSX elements. React takes that array and dumps the children out in the browser. This lets us do some powerful things using array methods.

Map an array of data to JSX

With the map method, you can convert array elements into JSX. React can then take that array and render things properly:

In the example above, we map over a collection of Tweet data and return a new collection of JSX.

This code isn't duplicated, so it's easier to read and maintain. Another benefit is that we can load the Tweets dynamically from a database. As long as the Tweets are in the correct format, the code doesn't care how you get them.

Each child in a React list must have a unique key

If you take a look at the console in the example above, you'll see that React is throwing an error:

Warning: Each child in a list should have a unique "key" prop.

A key is a unique string or number.

React uses keys to correctly identify elements in an array. The elements are tracked so that React can make DOM updates (i.e. re-renders) efficiently. A bad key can lead to bugs when a list can be reordered (e.g. via sorting) or when elements can be added/removed from a list.

Let's look at a bug in action.

In the example below, we have two lists of boxes. Each box has an HTML input element and a number to identify it. Right above the boxes is a Shuffle button that re-orders the boxes.

The boxes in list one are using a unique key. The boxes in list two are using the array index for the keys. Since an array index isn't unique to a box, we've introduced a subtle bug when we try to shuffle the boxes.

Try it out for yourself and see if you can spot the issue.

The first thing to note is that the order of the boxes is changing in both lists. The issue is that only the first list is keeping track of the input elements correctly. Since you can't use an array index to uniquely identify a box, React can't update the DOM correctly.

How do you pick a good key?

Here are some basic things to keep in mind.

Choose a key based on your data source

• Data from a database → DB IDs

• Data locally →crypto.randomUUID()

Choose a unique key

A key must be unique so that React can differentiate between elements. While this must hold for sibling elements (i.e. elements in the same array), there's no requirement for keys to be unique across an entire app:

function List() {
    const items = [1, 2, 3];
    return (
        <>
            <div>
                List One
                {items.map(item => <span key={item}>{item}</span>)}
            </div>
            <div>
                List Two
                {items.map(item => <span key={item}>{item}</span>)}
            </div>
        </>
    );
}

The keys in List One and List Two aren't unique.

But that's not a problem because they're separate lists. As long as the keys are unique within a single list, React can handle things correctly.

Keys must be stable

React needs to be able to consistently identify elements. This isn't possible if the keys you use aren't stable. This means that your keys can't change.

function List() {
    const items = [1, 2, 3];
    return (
        <div>
            {items.map(item => (
                <span key={Math.random()}>{item}</span>
            ))}
        </div>
    );
}

In this example, Math.random ensures that we have unique keys. The issue is that the keys aren't stable. Every time the List component re-renders, Math.random runs again, and the keys change.

From React's perspective, these are different elements.

All React can do is remove the elements and recreate them. Compared to updating the elements in place, this is a more expensive operation.

Keys should go on top-level elements

When you map an array of data to an array of elements, it's important to put the key on the outermost element. React won't traverse the component hierarchy to find a key, so it won't be able to identify elements correctly.

function List() {
    const items = [1, 2, 3];

    // Wrong
    const listOne = items.map(item => (
        <div>
            <span key={item}>{item}</span>
        </div>
    ));

    // Right
    const listTwo = items.map(item => (
        <div key={item}>
            <span>{item}</span>
        </div>
    ));

    // ...render
}

The key has to go on the div instead of the span so that React can use it.