Forem: Chris Held

Custom Error classes with Apollo Server

Chris Held — Tue, 18 Jul 2023 14:47:37 +0000

Recently, I was tasked with upgrading an older version of apollo-server-express with the newer @apollo/server package. apollo-server-express is approaching end of life this year and we wanted to take advantage of all of the new features apollo had introduced in the last two years. While there were several differences involved in the upgrade, one particular change caught our attention—the removal of support for custom error classes that we had used extensively used in our application. The challenge we faced was to find a solution that allowed us to seamlessly transition to the new version without disrupting our existing users.

In the previous version, we handled unauthorized access much like the following code snippet:

if (!hasAccess) {
    // Removed!
    throw new ForbiddenError("You don't have access");
}

The recommendation from the apollo upgrade docs was to replace these instances with GraphQLError, like so:

if (!hasAccess) {
    throw new GraphQLError("You don't have access", extensions: { code: 'FORBIDDEN' });
}

While this technically resolved our problem, it felt cumbersome to add the extensions property to all our old errors. However, we found a simple and elegant solution inspired by Apollo's previous approach: extending GraphQLError to create our own custom errors.

To accomplish this, we defined our custom error classes as follows:

export class AuthenticationError extends GraphQLError {
  constructor(message: string) {
    super(message, {
      extensions: {
        code: 'UNAUTHENTICATED',
        http: {
          status: 401,
        },
      },
    });
  }
}

export class ForbiddenError extends GraphQLError {
  constructor(message: string) {
    super(message, {
      extensions: {
        code: 'FORBIDDEN',
        http: {
          status: 403,
        },
      },
    });
  }
}

Creating our own custom errors allows us to encapsulate setting and sending extensions in one place, which ensures we’re consistent with how we’re responding to these errors. As an added bonus it gave us an opportunity to send down a 401 or 403 status code when throwing the appropriate error, which had been requested by a few of our clients.

This turned what could have been a lot of work into a really straightforward upgrade path. By simply updating the imports, we were able to resolve the majority of our issues while maintaining the same functionality. This meant that consumers of our API wouldn't need to make any changes to adapt to our system, ensuring a smooth transition.

useHug: Creating custom React Hooks 🥰

Chris Held — Sun, 14 Feb 2021 15:16:01 +0000

Building custom hooks is a great way to encapsulate behaviors and reuse them throughout your application. To demonstrate this, we're going to build out the idea of "hugging" elements of our UI. Our huggable behavior will:

Change the mouse cursor on hover (we want our user to know what needs a hug).
Scale the element down on click (this is a firm hug, some squishiness is expected).
Change the mouse cursor while clicking (to show our appreciation).

I find the first step to making something reusable is to use it once, so let's implement this in a component:

import React, { useState } from "react";
import { animated, useSpring } from "react-spring";

const Huggable = () => {
  const [hovering, setHovering] = useState(false);
  const [pressed, setPressed] = useState(false);
  const animationProps = useSpring({
    transform: `scale(${pressed ? 0.8 : 1})`
  });
  const onMouseEnter = () => setHovering(true);
  const onMouseLeave = () => {
    setHovering(false);
    setPressed(false);
  };
  const onMouseDown = () => setPressed(true);
  const onMouseUp = () => setPressed(false);

  let className = "huggable";

  if (pressed) {
    className += " hugging-cursor";
  } else if (hovering) {
    className += " huggable-cursor";
  }

  return (
    <animated.div
      className={className}
      onMouseEnter={onMouseEnter}
      onMouseLeave={onMouseLeave}
      onMouseDown={onMouseDown}
      onMouseUp={onMouseUp}
      style={animationProps}
            role="button"
    >
      Hug me!
    </animated.div>
  );
};

export default Huggable;

There are a few things going on here so we'll take a closer look:

const [hovering, setHovering] = useState(false);
const [pressed, setPressed] = useState(false);

There are two states that we want to track here, is the user hovering and have they pressed the button.

const animationProps = useSpring({
  transform: `scale(${pressed ? 0.8 : 1})`
});

We take advantage of react-spring's useSpring hook to create an animation. We could also use CSS transforms here but react-spring does a lot of math for us to give us really good looking animations without much work.

const onMouseEnter = () => setHovering(true);
const onMouseLeave = () => {
  setHovering(false);
  setPressed(false);
};
const onMouseDown = () => setPressed(true);
const onMouseUp = () => setPressed(false);

These event handlers will be used to manage our hovering / pressed state, which in turn will drive our behavior.

let className = "huggable";

if (pressed) {
  className += " hugging-cursor";
} else if (hovering) {
  className += " huggable-cursor";
}

We set a className here dynamically based on our pressed / hovering state. This is used to control some basic styles as well as custom cursors when hovering. This might have been a little easier had I used JSS or styled components, but this served my needs just fine and will hopefully make sense to a wider audience.

return (
    <animated.div
      className={className}
      onMouseEnter={onMouseEnter}
      onMouseLeave={onMouseLeave}
      onMouseDown={onMouseDown}
      onMouseUp={onMouseUp}
      style={animationProps}
            role="button"
    >
      Hug me!
    </animated.div>
  );

Finally, our markup. Not much to see here as we're just passing down the props we defined above, but it's worth pointing out the animated tag, which is required by react-spring.

Here's what we've got so far:

Not bad! Now let's try and isolate what we want to encapsulate in a hook. We know this should be applicable to any element, so we won't want to use any of the markup. That leaves the state management, event handlers, the animation, and our classes:

const [hovering, setHovering] = useState(false);
const [pressed, setPressed] = useState(false);
const animationProps = useSpring({
  transform: `scale(${pressed ? 0.8 : 1})`
});
const onMouseEnter = () => setHovering(true);
const onMouseLeave = () => {
  setHovering(false);
  setPressed(false);
};
const onMouseDown = () => setPressed(true);
const onMouseUp = () => setPressed(false);

let className = "huggable";

if (pressed) {
  className += " hugging-cursor";
} else if (hovering) {
  className += " huggable-cursor";
}

If we copy that into it's own function it looks something like this:

const useHug = () => {
  const [hovering, setHovering] = useState(false);
  const [pressed, setPressed] = useState(false);
  const style = useSpring({
    transform: `scale(${pressed ? 0.8 : 1})`
  });
  const onMouseEnter = () => setHovering(true);
  const onMouseLeave = () => {
    setHovering(false);
    setPressed(false);
  };
  const onMouseDown = () => setPressed(true);
  const onMouseUp = () => setPressed(false);

  let className = "";

  if (pressed) {
    className += "hugging-cursor";
  } else if (hovering) {
    className += "huggable-cursor";
  }

  //TODO: return...?
};

All that's left now is what we want to return. This is an important decision as it defines what consuming components can do with our hook. In this case, I really want a consumer to be able to import the hook as one object and spread it over an html element, like so:

const huggableProps = useHug();

return <a href="/contact" {...huggableProps}>Contact Us</a>

This makes our hook easy to consume and use while keeping some flexibility in case an element wants to pick and choose what events to use. In order to do that we have to leave off our state variables, since they aren't valid properties for html elements. This is what our return statement winds up looking like:

return {
  onMouseDown,
  onMouseEnter,
  onMouseLeave,
  onMouseUp,
  className,
  style
};

Now that we've got our hook, the only thing left to do is to use it:

export default function App() {
  const { className, ...hugProps } = useHug();
  const buttonHugProps = useHug();
  return (
    <div className="App">
      <animated.section className={`huggable ${className}`} {...hugProps}>
        I like hugs!
      </animated.section>

      <br />
      <br />
      <animated.button {...buttonHugProps} type="button">
        buttons need hugs too
      </animated.button>
    </div>
  );
}

In the above example we've implemented our useHug hook in two ways, by taking all of the props and spreading them out over an element, and another by separating out the className prop and using that to compose a css class with our consuming element's existing className. We also make use of the animated tag to ensure our app animates correctly with react-spring.

Although this example may seem kind of silly, a lot of the process for extracting logic into a custom hook would remain the same, no matter what you're building. As you identify patterns in your code it's a good practice to look for ways you can abstract application logic or behavior in the same way you would abstract a common UI element like a modal or input. This approach can help set you up for success as your application grows over time and prevent future developers (or future you) from reinventing the wheel on something you've already implemented a few times.

If you'd like to see the full code, here it is on codesandbox. Feel free to fork it and play around, I'd love to see what you come up with!

React: Prototyping with Apollo Client Schemas

Chris Held — Sun, 02 Aug 2020 19:04:41 +0000

Building a prototype is a great way to validate an idea, or to gather feedback from users without taking on the risk of having to build out an entire application. In this tutorial we'll take a look at Apollo Client and how we can leverage a client side schema to set us up for success when we're ready to build out an API to talk to our front end.

Apollo Client is a tool used to manage your client side data. It's typically paired with Apollo Server but it will work with any GraphQL server implementation, which makes it great for prototyping. Even if we choose a different GraphQL implementation for our server like Absinthe later, we can still keep our front end queries as long as the schema is defined the way we're expecting.

For our demo we're going to create an app that will return some information about our user's location based on their IP Address. Let's get started!

First we'll spin up a react app and install apollo:

npx create-react-app apollo-client-schema-demo
cd apollo-client-schema-demo
npm i
npm install @apollo/client graphql

First let's create a component to display our user's information. We don't really need to worry about where the data is coming from right now so we'll use static data. Create an IPInfo.js file that looks like this:

import React from "react";

const IPInfo = () => {
  const data = {
    ipAddress: "1.1.1.1",
    city: {
      name: "Sheboygan",
      population: 123456,
    },
    country: {
      name: "USA",
      population: 123456,
    },
  };

  return (
    <main className="App">
      <h1>Howdy!</h1>
      <p>Your IP Address is {data.ipAddress}</p>
      <p>
        {`Your city, ${data.city.name}, has a current population of
         ${data.city.population}`}
      </p>
      <p>
        {`Your Country, ${data.country.name}, has a current population of
         ${data.country.population}`}
      </p>
      <p>Cool, huh?</p>
    </main>
  );
};

export default IPInfo;

Let's also edit our App.js file to show this component:

[...]
function App() {
  return (
      <div className="container">
        <IPInfo />
      </div>
  );
}
[...]

...and edit our App.css file slightly to clean it up:

body {
  margin: 2rem;
}

.container {
  max-width: 800px;
  margin: auto;
}

If we run npm start, we should be greeted with something like this:

Now we need to set up an apollo client. Add the following to App.js:

import { ApolloClient, ApolloProvider, InMemoryCache } from "@apollo/client";

const client = new ApolloClient({
  uri: "https://48p1r2roz4.sse.codesandbox.io",
  cache: new InMemoryCache(),
});

This sets up an instance of ApolloClient. The uri we chose is from the Apollo Documentation and can be used as a placeholder until we have a real server to point to. The contents of the server don't really matter since we'll only be pointing at our client schema, but it is a required field when instantiating a client.

In order to tie our app to apollo, we need to wrap it in an instance of ApolloProvider. To do that we'll need to edit our App component:

function App() {
  return (
    <ApolloProvider client={client}>
      <div className="container">
        <IPInfo />
      </div>
    </ApolloProvider>
  );
}

If we refresh we shouldn't see any difference since we aren't actually querying for anything. To do that without having an actual server to call, we can define typeDefs in our app and pass them in to our client instantiation. Let's make some modifications to App.js:

import React from "react";
import "./App.css";

import {
  ApolloClient,
  ApolloProvider,
  InMemoryCache,
  gql,
} from "@apollo/client";
import IPInfo from "./IPInfo";

const typeDefs = gql`
  extend type Query {
    client: Client!
  }

  extend type Client {
    ipAddress: IPAddress!
  }

  extend type IPAddress {
    address: String!
    city: City
    country: Country
  }

  extend type City {
    name: String!
    population: Int
  }

  extend type Country {
    name: String!
    population: Int!
  }
`;

const client = new ApolloClient({
  uri: "https://48p1r2roz4.sse.codesandbox.io",
  cache: new InMemoryCache(),
  typeDefs,
});

function App() {
  return (
    <ApolloProvider client={client}>
      <div className="container">
        <IPInfo />
      </div>
    </ApolloProvider>
  );
}

export default App;

Here, we're defining typeDefs and creating a client query and some types to support it, then passing that in to our client constructor. Now we can use apollo's useQuery hook to fetch the results of that query, even though we still haven't written anything to resolve it and we haven't build out a server. Let's do that in IPInfo.js:

import React from "react";
import { useQuery, gql } from "@apollo/client";

const CLIENT_QUERY = gql`
  {
    client @client {
      ipAddress {
        address
        city {
          name
          population
        }
        country {
          name
          population
        }
      }
    }
  }
`;

const IPInfo = () => {
  const {
    data: {
      client: { ipAddress: { address, city = {}, country = {} } = {} } = {},
    } = {},
    loading,
    error,
  } = useQuery(CLIENT_QUERY);

  if (loading) {
    return (
      <p>
        Hmm...{" "}
        <span role="img" aria-label="thinking emoji">
          🤔
        </span>
      </p>
    );
  }

  if (error) {
    return (
      <p>
        Ruh Roh{" "}
        <span role="img" aria-label="sad emoji">
          😫
        </span>
      </p>
    );
  }

  return (
    <main className="App">
      <h1>Howdy!</h1>
      <p>Your IP Address is {address}</p>
      <p>
        {`Your city, ${city.name}, has a current population of
         ${city.population}`}
      </p>
      <p>
        {`Your Country, ${country.name}, has a current population of
         ${country.population}`}
      </p>
      <p>Cool, huh?</p>
    </main>
  );
};

export default IPInfo;

We've changed a lot here, so let's step through.

First we define our graphql query. Nothing very special there if you're familiar with graphql, but note the @client directive. That tells apollo that this doesn't exist on the server, so there's no need to ask the server for this.

In the actual component code we take advantage of apollo's useQuery hook to make our query:

  const {
    data: {
      client: { ipAddress: { address, city = {}, country = {} } = {} } = {},
    } = {},
    loading,
    error,
  } = useQuery(CLIENT_QUERY);

This gives us all the data we need to power our form, plus a few variables to manage different query states. Our markup has remained largely the same, though we did add a bit to handle loading and error states.

If we refresh our page, we'll see a whole lot of nothing:

Why is that? Well, in our client schema we only defined the shape of our data, but not it's contents. To do that we need to create a resolver. Let's add one right underneath our schema in App.js:

const resolvers = {
  Query: {
    client: () => ({
      ipAddress: {
        address: "172.220.20.36",
        city: {
          name: "Sheboygan",
          population: 48895,
        },
        country: {
          name: "United States of America",
          population: 325145963,
        },
      },
    }),
  },
};

const client = new ApolloClient({
  uri: "https://48p1r2roz4.sse.codesandbox.io",
  cache: new InMemoryCache(),
  typeDefs,
  resolvers,
});

Don't forget to add your resolvers object to your client.

In our resolver, we defined what should be returned when something calls the client query. We could make this more random if we wanted, but this will suit our prototype just fine. Now if we refresh we see the data from our resolver:

Let's say in parallel we did some research and found out there was a site, everbase.co, that had a schema that perfectly matched our client query. What a coincidence! All we have to do now is update our client url and remove the @client directive from our query and voila, we have an app connected to real data.

By doing the work of setting up our client and mocking our queries out up front, we wind up laying a lot of infrastructure necessary to complete our application when the time comes. If you'd like to see our demo in action it can be found here, or you can check out the source here. If you'd like to do some further research the Apollo docs are a great resource. Thanks for reading!

Contact Forms with Netlify Serverless Functions

Chris Held — Tue, 23 Jun 2020 12:30:11 +0000

In this tutorial we're going to go over how we can quickly and easily stand up a site to collect form data using Netlify Forms. Instead of having to set up our own database or lean on a 3rd party integration, we can add some tags in our html, deploy to Netlify, and watch the magic happen. We don't even have to write any javascript!

To get started, let's setup a folder with a basic index page for our site. Create a folder called netlify-demo and create an index.html file inside. We'll include the styles inline to keep things simple and in one file:

<!DOCTYPE html>
<html>
  <head>
    <title>Big Thing - Sign Up!</title>
    <meta charset="UTF-8" />
    <style>
      main {
        margin: auto;
      }
      body {
        display: flex;
      }
      form {
        display: flex;
        flex-direction: column;
        margin: auto;
      }
      input,
      button {
        padding: 15px 8px;
        margin: 4px 0px;
        font-size: 16px;
      }
      input {
        flex: 1;
      }
      button {
        flex: 1;
        background-color: #555555;
        border: none;
        color: white;
        text-align: center;
        text-decoration: none;
        display: inline-block;
        font-size: 16px;
        cursor: pointer;
      }
      h1 {
        text-transform: uppercase;
        text-align: center;
      }
    </style>
  </head>

  <body>
    <main>
      <h1>Big things are coming</h1>
      <form method="POST">
                <input required name="email" type="email" placeholder="Enter your email..." />
        <button type="submit">Subscribe for Updates</button>
      </form>
    </main>
  </body>
</html>

In order for Netlify to see our form and know to collect it's data, there are a few alterations we have to make to our form element:

      <form name="contact" method="POST" netlify>
        <input required name="email" type="email" placeholder="Enter your email..." />
        <button type="submit">Subscribe for Updates</button>
      </form>

Let's take a closer look at the form element:

<form name="contact" method="POST" netlify>

This is where the Netlify magic goo is. Adding netlify will tell the Netlify servers to store submissions for our form. We've also added a name attribute so Netlify knows what to call it, and in case we ever have multiple forms on this page.

Now that our site is ready to go, let's get set up on Netlify. From your dashboard on app.netlify.com, drag your netlify-demo folder into the dropzone. This will spin up your site on Netlify. It should go pretty fast since we're just sending one static file.

After your site is uploaded you'll be taken to the site's page, which will have the url for your deployed site:

Head over to your site and fill out the form. You'll notice after you submit you receive a generic success modal saying your submission was received. Back on Netlify, if you select the 'Forms' tab, you'll see a list of active forms, with your contact form the only one in the list. If you click into the contact form you should see your submission.

This is already a very useful tool to capture data, but you can also set up notifications on form submission. From the Forms tab, select Settings and Usage and scroll down to the Form Notifications section. From there you can add email, slack, or webhook notifications that will alert you when you receive new submissions.

If you'd like to learn more about using forms with Netlify, check out their docs on the subject. There are good resources there if you're using something like Gatsby or React and want to utilize the same technique.

Javascript Logging Tips and Tricks

Chris Held — Thu, 21 May 2020 00:21:16 +0000

console.log and debugger are probably the most common examples of debugging front end applications. Though log is the most common console function, there are a few others that you can leverage in your application for more descriptive and useful logging. In this post I'm going to cover a few extra functions you may not know about in the console object.

Styled Logging

In addition to console.log, there are a few functions to make your logging more semantic. console.info, console.warn, and console.error can apply some extra styles to your log statements and make your code a little bit more descriptive:

Assertions

If you need to conditionally log an error, console.assert takes an expression and will log an error if the assertion is false.

Tables

If you're logging table data, instead of using console.log(data), consider using console.table(data). console.table optionally accepts a second argument that lets you specify what columns you'd like displayed.

Custom Styles

Info, warn, and error are a nice way to add some canned styles to your logging statements, but if you're looking for a little more control, console.log accepts a second argument that allows you to style your log statements using CSS:

If you'd like to learn more, the full MDN reference is a great resource.

Explaining Javascript Reduce

Chris Held — Thu, 14 May 2020 16:07:51 +0000

The javascript reduce function is a great way to keep your code immutable to prevent (or "reduce", har har) surprises later on, but the syntax is kind of arcane looking and most of the examples online are for extremely simple cases like aggregating numbers.

Let's say we have an array of objects that need its ids mapped to an array:

const selected = rows.map(row => row.id)

Now let's add another wrinkle. These rows can have any number of children, and their ids have to be added as well (let's save children of children and recursion for another post). One thing we could do is keep the original selected array and loop through rows to push children ids onto it:

let selected = [];
rows.forEach(row => {
  selected.push(row.id);
  if (row.children) {
    row.children.forEach(child => {
      selected.push(child.id);
    });
  }
})

That'll work, but we've got a nested loop there, and mutating the array could introduce bugs. Another option is to use javascript's reduce function:

      const selected = [
        ...rows.map(row => row.id),
        ...rows.reduce((accum, row) => (
            row.children ? [...accum, ...row.children.map(c => c.id)] : accum
          ), 
          []
        )
      ];

There's a lot going on here, so let’s step through:

      const selected = [
        ...rows.map(row => row.id)

This part is pretty straightforward, we create a new array and use the spread operator to put our original array there (since we still want all of the parent rows):

        ...rows.reduce((accum, row) => (
            row.children ? [...accum, ...row.children.map(c => c.id)] : accum
          ), 
          []
        )

This line is where we make use of the reduce function. Reduce loops over our array of rows and calls a function for each one. The function has two arguments, the current row object and an accum or “accumulator” parameter that is whatever was passed from the last invocation of the function.

In our function we’re checking if this row has children, and if it does we’re using the spread operator again to return a new array containing what we’ve accumulated thus far plus the ids of any of this row’s children. If there are no children, we just return what we were passed in as the first argument, since we want to keep potentially adding to that value.

Something that is often overlooked is the last argument passed to the reduce function is the initial state of the accumulator (an empty array in our above example). If it’s not initialized it starts as undefined, which can result in some errors or bizarre behaviors.

One last important point about reduce is that it can be hard to read and process mentally, especially when either a new person is taking over a feature / codebase or you're coming back to it after a long break. In the case here reduce solves our problem without causing too much mental overhead, but sometimes opting for another solution will make life much easier for future you.

React: Optimize Components with React.memo, useMemo, and useCallback

Chris Held — Sun, 10 May 2020 14:41:55 +0000

This article was originally posted on the Headway blog. Visit us at headway.io to see how we're making waves. 🏄‍♀️

In most cases, React performance is not something you need to worry about. The core library does a ton of work under the hood to make sure everything is rendering efficiently. However, occasionally you can run into scenarios where your components are rendering more often than they need to and slowing your site down.

‍

Let's look at an example:

const ListPage = ({data, title}) => (  
  <div>  
    <Header title={title}/>  
    <List listItems={data}/>  
  </div>  
)

‍

In this example, any changes to data will cause ListPage to re-render all of it's child components, including the Header component, even if title didn't change. The Header will render the same result given the same props, so any render with the same props is not necessary. In this case it's probably not a big deal, but if <Header/> was performing some expensive computation every time it rendered we would want to make sure it was only rendering when necessary.

‍

Thankfully, there are a few ways to optimize for this scenario.

‍

When using class based components, PureComponent will return the last rendered value if the passed in props are the same. There is also a shouldComponentUpdate function for more fine tuned control. When using functional components, React provides three methods of optimization that this article will be focusing on: React.memo, useMemo, and useCallback.

‍

React.Memo

React.memo is a higher order component that memoizes the result of a function component. If a component returns the same result given the same props, wrapping it in memo can result in a performance boost. Take our <Header/> example earlier.

‍

Let's say it looks something like this:

const Header = ({title}) => <h1>{title}</h1>

export default Header;

‍

We can see that this component isn't going to need to be rendered unless title changes, so it would be safe to wrap it in React.memo.

‍

const Header = ({title}) => <h1>{title}</h1>

export default React.memo(Header);

‍

Now, whenever Header is rendered, it will do a shallow comparison on it's props. If those props are the same, it will skip rendering and instead return it's last rendered value.

‍

A quick note about using memo and react dev tools. At the time of this writing, wrapping your component like this...

‍

const Header = React.memo(({title}) => <h1>{title}</h1>));

export default Header;

‍

...will cause your component to show up as Unknown in react dev tools. To fix this, wrap your component in memo after defining it, like we did previously:

‍

const Header = ({title}) => <h1>{title}</h1>;

export default React.memo(Header);

‍

useMemo

useMemo allows you to memoize the results of a function, and will return that result until an array of dependencies change.

‍

For example:

const widgetList = useMemo(  
  () => widgets.map(  
    w => ({  
      ...w,  
      totalPrice: someComplexFunction(w.price),  
      estimatedDeliveryDate: someOtherComplexFunction(w.warehouseAddress)  
    }),  
  ),  
  [widgets],  
);

‍

In this example, a component receives a list of widgets. The widgets coming into the component need to be mapped to include total price and an estimated delivery date, which uses some kind of complex and expensive function. If this component renders and the value of widgets is the same, there is no need to run those expensive functions again.

‍

Using useMemo will memoize the result, so if widgets haven't changed since the component's last render it will skip the function call and return what it got last.

‍

useCallback

useCallback can prevent unnecessary renders between parent and child components.

‍

Take this example:

const Parent = () => {  
  const [showExtraDetails, setShowExtraDetails] = useState(false);  
  return (  
    [...]  
    <Child onClick={() => { showData(showExtraDetails); }/>  
    [...]  
  );  
}

‍

This component will cause Child to re-render every time Parent does, even if Child is a PureComponent or wrapped in React.memo, because the onClick will be different every render. useCallback can handle this situation like so:

‍

const Parent = () => {  
  const [showExtraDetails, setShowExtraDetails] = useState(false);  
  const handleClick = useCallback(  
    () => {  
    showData(showExtraDetails);  
  },  
  [showExtraDetails],  
);  
  return (  
    [...]  
    <Child onClick={() => {handleClick}/>  
    [...]  
  );  
}

‍

Now handleClick will have the same value until showExtraDetails changes, which will reduce the number of times Child renders.

‍

Things to consider with optimization in React

A word of caution around premature optimization. React is typically fast enough to handle most use cases without resorting to any of these techniques. I would advise you to build your components without any optimization first, and look into adding performance enhancements only when necessary.

‍

Resources to learn more

If you'd like to explore these APIs further, here are some resources to help give you a better understanding.

React.memo

useMemo

useCallback

If you're looking to further optimize your React application, the react docs contain a great section on performance.