Forem: Charlie Carr

👨‍💻 🤖 Next 13 Overview & Building in Public 🛠️ 🚀

Charlie Carr — Thu, 10 Aug 2023 17:47:37 +0000

This blog post is reposted from my personal blog (check it out here for a better reading experience using MDX components).

This is the start of a new blog series that focuses on new Next.js features and building in public. Follow along with my GitHub repo and see the live app hosted on Vercel here.

Outline

Intro to Next.js 13 (13.4)
React vs. Next.js
Quick Highlights on Next 13
Building & Learning in Public
Feature Spotlight: Server Components
Feature Spotlight: App Router
Feature Spotlight: Data Fetching
Some Final Thoughts

Links to Code and Live App

Intro to Next.js 13 (13.4)

Next.js is a React framework for building full-stack web applications. Since its inception in 2016 by the team at Vercel, it has rapidly ascended the ladder of popularity in the world of web development.

Some of its key features include built in file-system routing, client and server side rendering, api routes, and automatic code splitting.

React developers opt for Next as it presents key benefits such as:

Performance optimizations and improved initial loading times - code splitting, incremental static regeneration, image optimizations
Additional SEO support - improved scoring
Stronger dev experience - not needing to add routing libs, no longer need to set up a separate backend server - as now both front end and back end live in Next

Next.js has been widely adopted by major corporations such as Netflix, TikTok, and Uber leveraging its capabilities to drive their web experiences.

In late 2022, Vercel released Next 13 bringing on major changes to support the new React 18 paradigm (client / server components) and most notably the introduction to the /app directory/router that was recently declared stable by the team this May.

This article (and those to follow in this series) will unpack these newer Next.js 13 features and other supplemental technologies through the lens of building a professional tennis web application.

But first.. React vs. Next.js

A quick table here to share for those who are looking to clearly compare React and Next.js as a quicker refresher before diving deeper.

x	React	Next.js
Definition	A JavaScript library for building user interfaces	Full stack React framework for the web
Rendering	Client Side rendering - larger bundle sizing on client	Sever Side Rendering / Static Site Generation make for very performant web apps - less JavaScript on client
Routing	No built in routing - must rely on external libs	Built in file system based routing
Code Splitting	No code splitting - poorer performance	Automatic code splitting
SEO Friendly	Slightly SEO friendly	Way more SEO friendly
Image Optimization	Not built in but can use external libs	Image optimizations with next/image component
Education / Community	Faster to pick up with larger community/documentation	Prior knowledge of React required with smaller community/documentation
Configurability	Basic adjustments needed for configurations	Everything can be configured with ease
Speed	Slower than Next	Faster than vanilla React
TypeScript	Supported	Supported

Quick Highlights on Next 13's New Features

New Features:

App Directory / Router - file based routing and colocation
React Server Components - async components
Layouts - new shared UI wrappers
Data Fetching - w/ caching, revalidation
Streaming - server sending smaller bits to client
Turbopack - new much faster build tool (alt to Webpack)
Toolkit Updates - image, font, link optimizations
OG Image Generation - open graph imgs for dynamic social cards
Middleware API - better dev exp and new functionality

In this article, I will introduce the major new capabilities of Next 13 and will dive deeper into more in future articles of this series.

Beginning this Blog Series and Building / Learning in Public

After building my latest freelance client’s web application with Next 13’s pages router, I decided to build my next independent application with the newly stable app router. As I follow the #buildinpublic community on Twitter and am a big fan of the Indie Hacking community, I came up with the idea to rather than build this independently for my own benefit to instead share my learnings along the way.

As I started mapping out this application, I came across shadcn/ui re-usable components and his example dashboard. I found an interesting dataset on tennis grand slam finals results and quickly spun up a Supabase Postgres DB with tables to serve the data for my own dashboard to display this data in interesting ways for tennis fans.

Over the coming days and weeks, I will continue building out this application and will be sharing my learnings and process along the way through these blog posts and tweets (my Twitter handle is @charcarr04). I will see how far I can take this leading up to this year’s US Open and hopefully refine some skills along the way and share with the dev community.

Feature Spotlight - Server Components

Before diving into Next 13.4, it is important to understand the new mental model of React 18’s client and server components. As discussed in the table above, the previous model of React (without added frameworks) was that everything was rendered on the client in SPAs. The creation of server components has created a hybrid approach where there are components that are rendered completely on the server and those that can be rendered on the client.

This new approach combines the rich interactivity of client-side apps with the improved performance of traditional server rendering.

The way I think about this is that everything is a server component unless it needs to be on the client (client interactivity (buttons/inputs), browser APIs, state / lifecycle methods - hooks, etc). This new paradigm reminds me of my earlier days learning to code with PHP. Now things like data fetching (discussed in more detail below) and other pieces of code that would traditionally bulk up the bundle size are moved to the server. This has positive results of more performant web applications including faster initial page load speeds.

import TourSelect from "./tourSelect";
import { ModeToggle } from "@/components/mode-toggle";

const DashHeader = () => {
  return (
    <header className="flex flex-col-reverse sm:flex-row w-full justify-between items-center">
      <h1 className="text-4xl sm:text-4xl font-bold tracking-tight  mt-4 sm:mt-0">
        Grand Slam Titles
      </h1>
      <div className="flex items-center gap-3">
        <TourSelect />
        <ModeToggle />
      </div>
    </header>
  );
};

export default DashHeader;

DashHeader is a server component as all components inside of /app are server by default. This component renders only static content from the server but has two client components inside of it.

"use client";

import {
  Select,
  SelectContent,
  SelectItem,
  SelectTrigger,
  SelectValue,
} from "@/components/ui/select";
import { atom, useAtom } from "jotai";

export const tourAtom = atom("mens");

const TourSelect = () => {
  const [tour, setTour] = useAtom(tourAtom);

  return (
    <Select value={tour} onValueChange={setTour}>
      <SelectTrigger className="w-[130px] text-xs">
        <SelectValue />
      </SelectTrigger>
      <SelectContent>
        <SelectItem value="mens" className="text-xs">
          Mens (ATP)
        </SelectItem>
        <SelectItem value="womens" className="text-xs">
          Womens (WTA)
        </SelectItem>
      </SelectContent>
    </Select>
  );
};

export default TourSelect;

Components can then be turned into "client components" by adding the ‘use client’ directive at top of the component. TourSelect uses client side state and has user interactivity for selecting the mens or womens tour to then display the appropriate tour data. These traits require it to be a client component.

Feature Spotlight - App Router

One of Next.js 13's most significant updates is the App Router, designed to be the long-term path for Next.js development. While the pages router isn't going anywhere (the Vercel team will still continue to support and add new features), they're nudging new projects towards embracing the App Router as it is the long term vision.

Understanding the App Router:

1. File-system based routing:

Just as with the pages router, each folder represents a route segment, directly correlating to a corresponding segment in the URL path. This extends even to nested routes within folders.

In my app router folder structure, I have the routes (admin, dashboard, player). I then colocate my files (components and hooks) for the specific routes and have more general components (ui, etc) that live outside of my app router. This is not the definitive way to set up the Next.js folder structure but just one way that has worked well for this tennis app.

2. File conventions:

As stated before, all files within the app router are by default server components. The most important file for each folder is the page.tsx. This creates the UI for a given route and also make those routes publicly accessible.

The second most important file is layout.tsx which is a UI component that is shared between multiple pages that serves as a wrapper for your page and other components. Layouts accept a children prop that will be populated with a child page for rendering.

Other files that are important to know include: loading, not-found, and error (may go into more detail on these in future blog articles).

3. Colocation:

This concept is foundational to the App Router (and probably my favorite aspect). It allows developers to house relevant files – be it components, styles, tests, or more – within these route folders. This was not possible in the pages directory as any file in pages is considered a route. Now, only the page.tsx files are publicly accessible, ensuring a neat and organized structure.

(*Note: Colocating your project files is not manditory and these files can live outside of /app if preferred)

Navigating the Routes:

Navigating within the App Router can be achieved in two distinct ways:

Link component: Acting as an extension to the traditional HTML <a> tag, this is the go-to method to navigate in Next.
useRouter hook: This hook (now imported from next/navigation) is useful for when programmatic route changes are necessary.

Performance – The Hybrid Approach:

The App Router marries the efficiency of server-side code splitting per route segment with the finesse of client-side route segment prefetching and caching. When a user ventures to a new route, there's no page reload - only the altered route segments get a makeover, offering a seamless and performant navigation experience.

Prefetching: This mechanism preloads routes in the background before they're actively visited. The Link component will auto-prefetch when they become visible in the user's viewport. And if you've got the itch to prefetch manually, router.prefetch() is at your service.
Caching: Say hello to Next's in-memory client-side cache, termed the Router Cache. As users navigate, the React Server Component Payload of prefetched and previously visited route segments are stored in this cache. This cache is used as much as possible - minimizing redundant server requests and data transfer, enhancing performance.

Dynamic Routes:

Dynamic routes take a bit of a different approach with Next 13’s app router. For scenarios where exact segment names come from dynamic data, you can enclose a folder's name in square brackets, for instance, [id] or [slug].

These Dynamic Segments and the generateStaticParams function used together statically generate routes at build time instead of on-demand at request time. This new function’s smart retrieval of data benefits applications with automatic memoization. This means a fetch request with the same arguments across multiple generateStaticParams, Layouts, and Pages will only be made once, which decreases build times.

import supabase from "@/utils/supabase";
import { notFound } from "next/navigation";
import { DataTable } from "../../components/data-table";
import { columns } from "../../components/columns";
import { getSlamInfo } from "@/app/dashboard/utils";
import BackButton from "../../components/back-btn";
import ProfileInfo from "../../components/profile-info";

export async function generateStaticParams(): Promise<any[]> {
  const { data: players, error } = await supabase
    .from("atp_players")
    .select("id");

  if (error) {
    console.error(error);
  }

  // Return empty array if no players
  if (!players) {
    return [];
  }

  return players.map(({ id }) => ({
    id,
  }));
}

export default async function Page({ params }: { params: { id: string } }) {
  const { id } = params;

  const { data: playerData } = await supabase
    .from("atp_players")
    .select()
    .eq("id", id)
    .single();

  const { data: playerResults } = await supabase
    .from("grand_slam_mens")
    .select()
    .or(`champion_id.eq.${id},runner_up_id.eq.${id}`)
    .order("year", { ascending: true })
    .order("major_number", { ascending: true });

  if (!playerData || !playerResults) {
    notFound();
  }

  const playerResultsWithMajorName = playerResults.map((result: any) => {
    const transformedMajor = getSlamInfo(result.major_number);
    result.major_number = transformedMajor.tournament;
    const seed_champ =
      result.seed_champion > 0 ? `(${result.seed_champion})` : null;
    const seed_runner_up =
      result.seed_runner_up > 0 ? `(${result.seed_runner_up})` : "";
    result.champion = `${result.champion} ` + seed_champ;
    result.runner_up = `${result.runner_up} ` + seed_runner_up;
    return result;
  });

  return (
    <div className="container mx-auto py-10">
      <BackButton />
      <h1 className="text-2xl sm:text-4xl font-bold tracking-tight mt-4">
        Grand Slam Titles:
        <span className="text-muted-foreground ml-4">
          {playerData.player_name}
        </span>
      </h1>

      <ProfileInfo playerData={playerData} playerResults={playerResults} />
      <DataTable columns={columns} data={playerResultsWithMajorName} />
    </div>
  );
}

This is a server component in my tennis app where I am dynamically generating the mens (ATP) players profile pages. I am using Supabase for my DB so instead of a fetch to my own backend I am querying the 'id' column of my 'atp_players' table. The generateStaticParams function creates all of the paths for each player based on their 'id' and then in my async server component I am retrieving this id from the params to query the player's additional profile data to render on the player profile page.

Feature Spotlight - Data Fetching

Next 13 provides new features for fetching data from the server. It has extended the native fetch Web API with additional caching and revalidation configurations. Each fetch request is memoized while rendering the React component tree.

My previous example with the server component from my dynamic mens players route is a good example of these async / await features in action.

export default async function Page({ params }: { params: { id: string } }) {
  const { id } = params;

  const { data: playerData } = await supabase
    .from("atp_players")
    .select()
    .eq("id", id)
    .single();

Rather than needing to use React lifecycle hooks and handle this on the client, server components simplify the data fetching process. Now you only need to mark the component as async and then await the fetched data directly in the component. This leads to much cleaner code and this would work the same way if I was using the fetch API instead of querying directly from Supabase.

Caching

Next.js automatically caches the returned values of the fetch request on the server. Data can then be fetched at build time or request time, cached, and reused on each data request.

Revalidation

When you are looking to return the latest data from the server Next provides the ability to customize revalidation. Revalidation will clear the cached data and refetch to ensure that the app is returning the most up to date information to its users. There are two main approaches for this - time-based revalidation (automatically revalidate data after a set time interval) and on-demand validation (manually revalidating data based on event - good for form submissions).

Some Final Thoughts

The new Next.js 13 features have been a great developer experience for me so far and I am looking forward to building and sharing more in my next article in the series.

Let me know in the comments what other Next 13 aspects you would like to see / other ideas for features of this app.

Stay tuned.

Charlie

My Website
My Blog
Original Post

6 Approaches for Data Fetching in React

Charlie Carr — Tue, 31 Jan 2023 00:29:11 +0000

Outline

Intro to Data Fetching in React
Simple Explanation of JavaScript Promises
Approach #1: Fetch API w/ Promise Methods
Approach #2: Axios Library w/ Promise Methods
Approach #3: Async Functions (async / await)
Approach #4: Creating ‘useFetch’ Custom React Hook
Approach #5: React Query Library
Approach #6: Redux Toolkit’s RTK Query
Some Final Thoughts

Link to Follow Along w/ Examples

GitHub Repository

Data Fetching in React

Data fetching is a core aspect of any React application. It is very important for React developers to understand the different data fetching approaches and which is most appropriate for their use case.

This article has a corresponding public GitHub repository that you can reference to better understand. The sample React app fetches data from an external API (random.dog) and renders a random picture of a dog on the webpage. Its goal is to be very simple to allow for easy comparison between the data fetching approaches.

But first, let's understand JavaScript Promises

Simply put, a promise is a JavaScript object that will produce a value sometime in the future. This usually applies to asynchronous operations (ex. data fetching).

A promise has three states:

Pending: where the promise is still in the works
Fulfilled: where the promise resolves successfully and returns a value
Rejected: where the promise fails with an error

If a promise is fulfilled or rejected it has settled. Promises have different methods for doing different things depending on the outcome. These methods will be discussed in greater detail in the next sections.

Approach #1 - Fetch API w/ Promise Methods

The Fetch API provides a global fetch() method that enables developers a straightforward approach to fetching data. Prior to fetch(), the conventional approach was using XMLHttpRequest(). (This approach is not included in this article as fetch() has replaced it with a more powerful and flexible feature set.)

The fetch() method requires one parameter, the URL to request, and returns a promise. The second and optional parameter, options, is an array of properties. The return value of fetch() can be either JSON or XML (either an array of objects or a single object). Without the options parameter, fetch() will always make a GET request.

This first approach is what you will typically see in simple use cases of data fetching and often the first result when navigating API documentation. As stated before, we are fetching data from an API that returns a random image of a dog and we then render that image on screen. Prior to making the request, we wrap the code inside a useEffect hook with an empty dependency array to run the fetch() method only when the component initially mounts.

Full Code for Approach #1

  useEffect(() => {
    fetch(URL)
      // syntax for handling promises
      .then((res) => {
        // check to see if response is okay
        if (res.ok) {
          // if okay, take JSON and parse to JavaScript object
          return res.json();
        }
        throw res;
      })
      //  .json() returns a promise as well
      .then((data) => {
        console.log(data);
        // setting response as the data state
        setData(data);
      })
      // if res is not okay the res is thrown here for error
      .catch((err) => {
        console.error(`Error: ${err}`);
        // setting the error state
        setError(err);
      })
      //  regardless if promise resolves successfully or not we remove loading state
      .finally(() => {
        setLoading(false);
      });
  }, []);

Inside the useEffect we call the fetch() method and pass in the URL for our API endpoint. In this approach we are using the .then(), .catch(), .finally() methods of a promise object (recall that fetch() returns a promise). We use the .then() method and pass in a callback function to check if the response is ok. If the response is ok, we take the JSON data that is returned and parse it into a JavaScript object with the .json() method. If the response is not ok, we throw an error.

Since the .json() method also returns a promise we can chain another .then() and pass a function that sets the state of the data to then be used elsewhere in the component. In our example, the external API returns an object with a url property (will be used as src of our image).

Continuing through the chain, the next section is the .catch() that schedules a function to be called when the promise is rejected. This also returns another promise where we can then chain the .finally() method that will be called regardless of if the promise is settled (either resolved or rejected). The .finally() method allows us to avoid duplicating code in both .then() and .catch(), making this a good place to remove the loading state in our example.

Approach #2 - Axios Library w/ Promise Methods

Axios is a popular HTTP client library that can be used for efficient data fetching. It can be easily installed via npm or other package managers into React applications. Using Axios is an alternative to the Fetch API and has some advantages if you do not mind installing an external library.

This second example will be very close to our code for the first example using the same promise methods for handling promise state and responses. Instead of using the fetch() method, after importing the Axios library into our component we can use the axios.get() method where we can pass in the URL to our external API endpoint. This will return a promise so we can take the same approach with the promise method chaining.

Full Code for Approach #2

useEffect(() => {
    axios.get(URL)
      // syntax for handling promises
      .then((res) => {
        console.log(res.data);
        // axios converts json to object for us (shortens our code)
        setData(res.data);
      })
      // axios takes care of error handling for us instead of checking manually
      .catch((err) => {
        console.error(`Error: ${err}`);
        // setting the error state
        setError(err);
      })
      //  regardless if promise resolves successfully or not we remove loading state
      .finally(() => {
        setLoading(false);
      });
  }, []);

The apparent differences between the code for the Fetch API and the code for this Axios approach is that with Axios we only need a single .then() as Axios converts the JSON to a JavaScript object for us (shortening our code). Additionally, we are no longer writing a conditional to throw errors manually because Axios throws 400 and 500 range errors for you (again shortening our code).

Approach #3 - Async Functions (async / await)

In this example we will be moving away from the promise chaining we have used in the previous two examples and instead introduce a more modern approach for writing asynchronous, promise-based code. This approach can be used with whatever fetching mechanism you choose but for this example we will be sticking with the Axios library.

This third example sets up the component in a similar way to the last example with importing the Axios library and then wrapping the code for fetching the data inside of a useEffect with an empty dependency array. Within the useEffect, we create an asynchronous function using the async keyword and then within the function have three separate sections - try, catch, and finally. This try/catch approach is used to handle errors in JavaScript. The code inside of the try block is executed first and if there are any errors thrown they will be ‘caught’ in the catch block and the code inside will be executed. Lastly, the finally block will always be executed after the flow passes through the try/catch.

Full Code for Approach #3

useEffect(() => {
    // create async function b/c cannot use async in useEffect arg cb
    const fetchData = async () => {
    //   with async/await use the try catch block syntax for handling
      try {
        // using await to make async code look sync and shorten 
        const res = await axios.get(URL);
        setData(res.data);
      } catch (err) {
        console.error(`Error: ${err}`);
        // setting the error state
        setError(err);
      } finally {
        setLoading(false);
      }
    };

    fetchData();
  }, []);

In this example, the try block creates a variable called res (short for response) that uses the async keyword. This allows the code to look synchronous (shorter and easier on the eyes). In this example the axios.get(URL) is being ‘awaited’ until it settles. If the promise is fulfilled, then we set the data into the state. If the promise is rejected (errors thrown), it moves into the catch block.

Approach #4 - Creating ‘useFetch’ Custom React Hook

The fourth approach is creating our own custom React hook called useFetch that will be able to be reusable across our app in different components and cut out the bulky fetching code from each component. This example is really just taking the fourth example (same technique of using the Axios library with async/await) and moving that code into its own custom hook.

To do this, we create a new file called useFetch.js. We then take all of the code within the useEffect from the last example as well as the different states we are tracking add it inside of the useFetch function. Finally this function will return an object with each of those states to then be accessed where the useFetch hook is called. Our useFetch hook will also accept one parameter, the URL, to allow for more reusability with the potential to make fetch requests to different endpoints.

Full Code for Approach #4

const useFetch = (url) => {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    // create async function b/c cannot use asyc in useEffect arg cb
    const fetchData = async () => {
      //   with async/await use the try catch block syntax for handling
      try {
        // using await to make async code look sync and shorten
        const res = await axios.get(url);
        setData(res.data);
      } catch (err) {
        console.error(`Error: ${err}`);
        // setting the error state
        setError(err);
      } finally {
        setLoading(false);
      }
    };

    fetchData();
  }, []);

  return {
    data,
    loading,
    error,
  };
};

Finally, we import this new custom hook into the components where it will be used and then call it as we would any other React hook. As you can see this greatly helps with code readability and shortening our component.

One final note with this approach is that there are also external libraries that you can install rather than creating your own custom hook. One popular library is react-fetch-hook with a very similar functionality to the hook we just built.

Approach #5 - React Query Library

One of the most modern and robust approaches for data fetching in React is using the React Query library. It has many features in addition to just simple data fetching but for this example we will learn just how to simply fetch data from the same example external API. (If you are interested in learning more check it out here)

After installing and importing, React Query provides many custom hooks that can be reused across our components in a very concise way. In this example, we import QueryClient and QueryClientProvider from react-query and then wrap our application with the provider and pass the queryClient instance as the client property to the wrapper. This enables us to use the library across our app.

To make this simple GET request we import and use the useQuery hook. Unlike the previous example with our custom hook, we pass in two parameters. The first required parameter is the queryKey that is used as a key for reference for this specific query. The second required parameter is the queryFn that is the function that the query will use to request data. Rather than just passing in a simple URL like our previous custom hook example we will use this query function and then use the Fetch API and promise method syntax to make the initial fetch. (This hook has many other optional parameters.)

Full Code for Approach #5

const { isLoading, error, data } = useQuery("dogData", () => fetch(URL).then((res) => res.json()));

From here, React Query will do all of the additional work behind the scenes and in this example we can destructure isLoading, error, and data from this hook call to be used in our application although there are many other values we are able to access as well.

The power and advantages of using React Query are evident in examples that are larger than our current Dog Image API example. A few additional features to mention include: caching, updating ‘out of date’ data in the background, and other performance related benefits.

Approach #6 - Redux Toolkit’s RTK Query

The final approach of this article is data fetching with Redux Toolkit’s RTK Query. It is very common for apps to be using Redux for state management. If your company or your current side project is currently using Redux, a good option is to use RTK Query for data fetching as it provides similar simplicity and benefits as React Query does.

To start using RTK Query wherever you are storing your Redux code, create a rtkQueryService.js file that will be the setup for data fetching. After creating you then add the service to your Redux store and assuming you are already using Redux you will already have a <Provider> component with the store that is wrapped around your application.

From here, it is very similar to using the custom hook and React Query approach where you import and then use the query hook and destructure data, error, and isLoading to then be able to use in your component.

Full Code for Approach #6

 const { data, error, isLoading } = useGetDogQuery();

As you can see there is a lot of setup for Redux so this might not be the best approach for our use case but RTK Query can be valuable if you are already using Redux within your React app and want a simple and modern approach for data fetching that also provides benefits like caching.

Some Final Thoughts

Props to you if you got to this point! The goal of this article was to introduce some different approaches of data fetching for those learning React. This serves as a centralized place to compare with the same use case to better understand. It was not my goal to make statements on the ‘best’ approach or dive into granular detail.

Additionally, there are other current approaches to data fetching not mentioned here and I am sure others will come about as the React ecosystem evolves. That said, I believe this article provides a strong foundation for understanding this space. I hope you found this useful!

(As this was my first post on dev.to I am curious to hear your feedback in the comments! What is your preferred way to fetch data in your React apps?)

charlie-carr.com