26. A (Pretty Deep Dive) Introduction to Next.js

This section of the course introduces building a new React project with a focus on creating a fullstack application using NextJS, a React framework. The project allows users to view and share meals within a foodies community. Unlike previous lessons, this project combines both front-end and backend elements. You’ll learn about NextJS, its benefits, and how to set up routes, pages, and work with React components within this framework. The section will cover data fetching and sending, styling, working with images, and page metadata, enhancing your React skills to create fullstack applications.

The content explains how to set up a new Next.js project, highlighting the differences from standard React projects. It suggests using the command npx create-next-app to create a project with Next.js pre-installed and outlines the initial setup process, including optional configurations like TypeScript, ESLint, and Tailwind CSS. The instructor opts out of using TypeScript and Tailwind to simplify the course content. After the project is created, they replace some default files with customized ones and provide a starting snapshot for learners to use, either through local files or CodeSandbox. Finally, they guide users on running the project using npm run dev to start the development server, noting that CodeSandbox automates this process.

The text explains the role of the app folder in a modern NextJS project, particularly focusing on the Page.js file within it. The Page.js file is important because it designates a React component as a page in NextJS, and it functions as a server component. This means the component is executed on the server, not the client side, which is a unique feature of NextJS compared to traditional React. Logs from the component are visible in the server terminal, not the browser console, demonstrating its server-side execution. The server component’s JSX code is then sent to the client’s browser to be rendered as HTML, making it visible on the screen.

The document explains how to add a new page to a Next.js website using server components. In Next.js, rather than using React Router, you create new pages by adding folders with a page.js file inside the app directory. For example, to create a page accessible at localhost:3000/about, you would create an about folder in the app directory and include a page.js file within it. This file should export a function returning the JSX content that will be rendered on the page. The folder structure is crucial because Next.js uses it to define routes. Once set up, visiting the /about route will display the content specified in the about page’s component.

The provided text explains how to enhance navigation between pages in a NextJS application without losing the single-page application (SPA) benefits. Initially, a traditional anchor element is used to link to a new page, causing a full page reload and breaking the SPA model by downloading a new page from the backend. To maintain the SPA experience, the text suggests using the Link component from next/link, which allows navigation without fully reloading the page. This component ensures that while the content is pre-rendered on the server, it updates on the client side with JavaScript, providing a seamless, interactive user experience.

The provided content explains the structure and purpose of layout and page JS files in a Next.js project. The page JS file defines the content of a specific page, while the layout JS file acts as a shell or wrapper for one or more pages. A root layout JS file is necessary at the top of the app folder, and additional nested layout files can be added for specific sections like an "about" folder. The layout file exports a React component that uses the children prop to render page content between HTML and body tags, setting up the basic HTML skeleton. The head element, typically used for metadata like titles, is not included directly in layout files because Next.js allows metadata to be set via a special reserved variable called "metadata." This way, the metadata applies to all pages covered by the layout. The children prop represents the content of the currently active page, illustrating how layout and page JS files work together, with layout providing the structure and page offering the content.

The provided text explains the setup and organization of a NextJS project, focusing on file structure and component management. It highlights the use of a globals.css file for global styles across all pages by importing it in layout.js, and mentions the special icon.png file for setting a favicon without explicit configuration in layout.js. The text describes creating routes through folders and reserved filenames like page.js and layout.js, and discusses adding regular React components that aren’t automatically treated as pages. It suggests organizing components in a components folder, either inside or outside the app directory, and emphasizes the importance of page.js for routing. Additionally, it mentions using an @ symbol in import paths for convenience, as configured in a jsconfig file, to simplify imports by referencing the root project folder. The text recommends consulting the official NextJS documentation for structuring projects and concludes with a preference for keeping components outside the app folder for a cleaner routing-focused structure.

In NextJS, certain filenames are reserved when used inside the app/ folder (or any subfolders). These reserved filenames include:

These filenames have specific purposes and are only treated specially within the app/ folder. For more details, refer to the official documentation.

The text provides a detailed explanation of setting up dynamic routes in a NextJS application, particularly for a blog with multiple posts. It describes the process of creating a scalable and maintainable routing structure, emphasizing the use of dynamic routes to handle multiple posts without manually creating a new folder for each post. This is achieved using a special syntax in NextJS, where square brackets are used to create a placeholder (e.g., [slug]) for dynamic segments in the URL. This allows the same page component to render different content based on the URL path segment values. The text also explains how NextJS automatically passes a params prop containing these dynamic segment values, which can be used to fetch specific content like blog posts from a database. The explanation hints at further capabilities of NextJS, such as custom error handling and data fetching, which will be explored in a future project focused on a Meals app.

The text describes a new project, a foodies app, which is set up in both local and CodeSandbox versions. The project has been simplified by removing previously created pages and includes a new assets folder with necessary images. Updates have been made to styles, and the layout and page JavaScript files. Notably, the layout JavaScript file now includes an SVG graphic for aesthetic purposes, to be displayed behind the website’s header. This project is prepared and ready for further work.

The content provides a detailed explanation of how layouts function in NextJS, particularly focusing on creating and utilizing a root layout and nested layouts. The author intends to enhance a webpage by adding a proper header, navigation, and logo using the layout.js file. In NextJS, layouts serve as wrappers around pages and can be nested for more specialized layouts. The root layout remains active across all pages, while nested layouts apply only to specific subsets, like meals-related pages in this example. The explanation includes using React components and the children prop to manage content within layouts. Although a nested layout was demonstrated, it was deemed unnecessary for the current task, so the focus shifted to updating the root layout to include a universal header for navigation.

The text describes the process of creating a new header component in a Next.js project. The author explains the steps for adding a "MainHeader" component to manage a shared header across all pages. This involves creating a separate file named main-header.js and exporting a React component called MainHeader. The component includes a clickable logo, using Next.js’s Link component, and a navigation menu with links to different pages. The author emphasizes the flexibility in organizing component files and chooses to keep them outside the app folder for clarity. They also mention importing images in Next.js projects, highlighting the need to access the src property. Finally, the component is integrated into the root layout, and although the header is functional, it requires styling to improve its appearance.

The provided text explains various methods for styling NextJS projects, focusing on CSS options. Initially, it discusses using global CSS files, which apply styles across all pages when imported into the root layout.js file. Another popular option is Tailwind CSS, a utility-first CSS framework that allows styling through small utility classes; however, it’s not used in this project to keep the focus on NextJS and React. Instead, CSS modules are chosen, offering a way to scope styles to specific components by using files ending in .module.css. These modules prevent styles from affecting other components, even with similar class names. The process involves importing these CSS module files into component files and using the imported object to access and apply the styles. The text concludes by demonstrating how this method results in a well-styled header, logo, and navigation links in the project.

The content discusses optimizing image handling in a NextJS project by using the built-in NextJS image component instead of the default HTML image element. The NextJS image component provides several benefits, such as lazy loading, responsive image setup, automatic size detection, and serving images in optimal formats like WebP for different browsers. It simplifies image management without additional configuration. The component also allows customization, such as prioritizing image loading to prevent content shift during page load. The text encourages exploring further options and configurations for advanced use cases, like loading images from third-party sources.

The text describes the process of refactoring a web application’s header background into a separate component for better organization and practice. The steps include creating a new JavaScript file (main-header-background.js) for the component, extracting the relevant HTML and CSS into separate module files, and adjusting the CSS to work with modules. The component is then integrated back into the application within main-header.js instead of layout.js, and all related files are organized into a main-header subfolder within the components directory. Path updates are also made to ensure the application functions as expected. This organization improves code maintainability and clarity.

The content describes the process of updating the main page content in a page.js file located in the root of the app folder. The aim is to replace existing content with a new layout that includes a page-specific header and main section. The header will contain a nested header introducing the page, a div for an image slideshow, and another div with two inner divs for a hero section and a call-to-action (CTA) section. The hero section will have an h1 title and a marketing paragraph, while the CTA section will contain links for users to join a community and explore meals. CSS modules are used for styling, and the file includes a page.module.css for this purpose. The main section will temporarily hold dummy text. The description also notes that a prepared page.js file is available for use, and the next step will be to work on the image slideshow.

The statement discusses the process of adding an image slideshow to a web project using React and Next.js. The plan is to create a new component for the slideshow to keep the main file lean. This component will be placed in a new subfolder within the components folder, specifically named image-slideshow.js, along with a CSS module file for styling.

The JavaScript file will use React’s useState and useEffect hooks to manage the slideshow’s state, changing the visible image every five seconds using setInterval. The images are imported from an assets folder and displayed using Next.js’s image component.

However, while attempting to integrate this component into the main page, an error occurs. The error indicates a conflict between client and server components in Next.js because the slideshow component requires useState (a client-side feature) but is being used within a server component context. This highlights the need to mark components correctly in Next.js to handle client-side functionality.

The text explains the distinction between Server and Client components in NextJS, a full-stack framework built on React. Unlike standard React applications that run purely on the client side, NextJS utilizes Server components that are rendered on the server before being sent to the client. This approach can enhance performance and improve search engine optimization by delivering complete HTML content to web crawlers. However, Client components, necessary for features like state management and event handling, are also supported in NextJS. They must be explicitly defined using the use client directive, enabling client-side features such as hooks and event handlers. Understanding these component types is crucial for effectively leveraging NextJS’s capabilities.

The provided text details the process of updating a community page and improving navigation functionality within a project using NextJS. First, the community page is populated with dummy content by replacing existing files with attached page.js and page.module.css files. A community component is used to display placeholder text and images. The main focus of the project will be on meal-related logic, which will be addressed later.

The navigation header is improved by highlighting the active page link. This is achieved by adding a CSS class conditionally based on the current path. The usePathname hook from NextJS is used to determine the active path. A new NavLink component is created to handle the active link logic, ensuring only necessary parts are rendered as client components. This keeps the majority of the components as server components, maintaining server-side rendering advantages. CSS classes are adjusted and imported to style the links properly. By segmenting client-side rendering to specific components, the project maintains optimal performance while enhancing navigation user experience.

The content outlines a development plan for a Meals page in a web application. Initially, the team has worked on the starting and community pages, as well as the header. The focus is now on the Meals page, which will eventually allow users to share meals. The task involves setting up the page structure with a header and main section, and importing necessary styles from a CSS module. The header includes a title, a paragraph, and a link to a share page for users to contribute recipes.

A new component, MealsGrid, is introduced to display meal items in a grid format. This component will map through meal data, outputting each meal as a list item with a unique key (meal.id). Styles for this component are managed via a CSS module. Another component, MealItem, is created to display details of each meal, including dynamic links to meal detail pages and images. The images, stored in a database, will use the Next.js Image component with a fill prop to handle dynamic dimensions since their sizes are unknown at build time.

The MealsGrid component is integrated into the Meals page, though initially, it displays no meals due to the absence of a data source. Future steps will involve populating this component with actual meal data.

The process described involves setting up a local SQLite database to store meal data for a meals grid component in a development environment. Here’s a summary:

The next step involves figuring out how to load meals from this database onto the meals page.

The content discusses data loading in a Next.js application, highlighting its server-side capabilities. Unlike vanilla React, Next.js combines backend and frontend, allowing direct database access without useEffect or fetch requests. The example involves setting up a database connection using the better SQLite3 package and creating a function to fetch data from a database. The explanation includes converting functions to async for handling promises and simulating delays, which is beneficial for managing loading states. It also covers passing data to components without useEffect. A minor styling error is noted, and the document concludes with an overview of how data and images are fetched and displayed in the application.

The content discusses how to improve user experience when loading pages in a web application using NextJS. Initially, when accessing a meals page, there’s a noticeable delay due to a forced two-second wait implemented in the data fetching function. However, NextJS caches pages, so revisiting them is faster. To enhance the experience during the initial load, a loading indicator can be added. This is achieved by creating a loading.js file, which displays a message (e.g., "Fetching meals…​") while data is being loaded. This provides immediate feedback to users, indicating that their navigation request is processing, thus improving the overall user experience. Basic styling for this indicator is handled with a loading.module.css file.

The text discusses improving the user experience on a NextJS meals page by handling loading states more effectively. Initially, the loading text occupies the entire screen, which is not ideal since the header can be displayed immediately without waiting for data. The proposed solution involves using React’s Suspense component to manage loading states. By moving data fetching to a separate component and wrapping it with Suspense, it allows displaying fallback content while data loads. This approach avoids using the loading.js file that applies to all nested layouts, enabling more granular control. The text also explains how this method partially renders the page, loading visible content first and streaming in data as it becomes available, enhancing the user experience.

The content explains how to handle errors in a Next.js application using an error.js file. The error.js file is a special component that can be added to the app folder to manage potential errors in pages and components, such as data loading failures. It can be placed at different levels of the application to catch errors either globally or within specific parts of the app. The error component must be a client component and can access props that provide details about the error, though sensitive information is hidden for security. The explanation includes a practical example of simulating an error by throwing one in a meals.js file and then handling it with a custom error page, which can be further customized. After demonstrating error handling, the simulated error is commented out to restore normal functionality.

The provided content discusses handling invalid URLs in an application. When a user enters a URL that is not supported, a default 404 error page appears. The text explains how to customize this page by adding a not-found.js file in the app folder. This file can be placed at the root level to handle all not-found errors globally or nested for more specific error handling. The example demonstrates exporting a NotFound function that returns HTML with a custom message using a CSS class defined in globals.css. This change allows for a tailored "Not Found" page for invalid URLs. The content then transitions to the next task of enabling browsing of meal details within the application.

The content describes the process of setting up a Meal Details page in a Next.js application. It involves working within a meals folder, specifically the mealSlug dynamic segment, to create a page.js file responsible for displaying meal details. The page structure includes a header and a main section, styled using a page.module.css file.

Key tasks include:

The approach ensures a secure and efficiently loaded Meal Details page, fetching and displaying data dynamically from a database.

The text discusses improving user experience when a requested meal does not exist in a web application. Instead of displaying a generic error page, the author suggests checking if the meal is undefined and then displaying a more user-friendly "not found" page. This can be achieved by using the notFound function from NextJS’s next/navigation module, which displays the nearest not-found page or error page. The author recommends creating a meal-specific not-found message to inform users that the requested meal or page data could not be found, providing a clearer and more helpful response.

The statement discusses the process of enhancing a meal management application by adding functionality to allow users to add their own meals. The focus is on a specific file, page.js, located in the meals folder, which is responsible for displaying the relevant page. A pre-prepared version of this file is provided, which includes a header, a form with various input fields, and an image picker for uploading images. Although the form is not yet functional for submissions, a CSS file for styling is also provided. The next steps involve working on the image picker and eventually enabling form submission functionality.

The provided content outlines the process of creating an Image Picker component in a React application. The component is built to allow users to attach and upload images via a form. It involves creating a separate component file image-picker.js and a CSS module for styling. The Image Picker component includes a label and a file input element, which accepts only image files (image/png or image/jpeg). The component hides the default file input and uses a custom button to trigger the file selection, utilizing React’s useRef hook to handle button clicks and input interactions. The component is marked with the use client directive to enable client-side interactions, such as clicking events. Finally, the goal is to enhance the component by adding a feature to preview the selected image.

The content describes the process of creating an image picker component in React that updates the UI to display a preview of the selected image. It involves handling the image selection event, using a state hook to manage the selected image, and converting the image file into a data URL using the FileReader class. This enables the image to be displayed as a preview. The implementation checks if a file is selected, reads it as a data URL, and updates the state to show the preview using the Next.js Image component. The component is designed to handle a single image selection and provides feedback if no image is selected. Once set up, the functionality allows users to pick an image and see an immediate preview before form submission.

The content discusses implementing form submissions in a full-stack application using Next.js. Instead of traditional methods in React, where data is manually collected and sent to a backend on form submission, Next.js offers a more efficient approach using Server Actions. This involves creating a function within the component holding the form and using the 'use server' directive to ensure the function executes on the server. This Server Action is set as the form’s action prop, enabling automatic handling of the form submission on the server side. The form data, including input fields like title, summary, and image, is collected using the formData object. The document also explains how to extract and potentially store this data, although the storage implementation is not detailed. The process allows for seamless form handling without reloading the page, as evidenced by logging the data to the console on the server side.

The text explains how to properly implement server actions in a web application, specifically when using components that interact with server-side logic. It points out that server actions cannot be included directly in client components due to technical restrictions in build processes like that of NextJS. Instead, server actions should be stored in separate files marked with a "Use Server" directive at the top. This way, server-side functions are kept separate from client-side components, helping prevent security issues and build errors. The server actions can then be imported into client components as needed, allowing for a clean separation of client and server logic. The explanation concludes by emphasizing the importance of storing data properly, such as saving meal information to a database and images to a file system, instead of merely logging them.

The content describes a process for adding a new function to a JavaScript file, meals.js, which handles storing meal data. This involves creating a saveMeal function that takes a meal object as input. The function includes several steps:

The content describes a process for handling image uploads in a web application. Instead of storing images directly in a database, which is inefficient for performance, the images are stored in a public folder on the file system. The steps involve extracting the file extension, generating a unique filename, and using Node.js’s file system API to write the image to the designated folder. The image path is then stored in the database rather than the image itself. The content also outlines how to prepare and execute SQL statements securely to prevent SQL injection attacks. Once the image is uploaded and data is stored, the application redirects the user to a different page to enhance user experience. The process ensures efficient storage and retrieval of images while maintaining database integrity.

The content describes a process of enhancing the user experience in a web application by providing immediate feedback during form submission. The solution involves using a React hook, useFormStatus, which provides the status of a form submission. The challenge is to avoid turning the entire page into a client component while still updating the button text to indicate that a request is being processed. The solution is to create a new component, MealsFormSubmit, which uses the useFormStatus hook to conditionally update the button text to "Submitting" and disable it during the submission process. This component is then used to replace the existing button in the form. As a result, users receive real-time feedback while their data is being submitted, improving the overall experience.

The text discusses the importance of validating user input for form submissions both on the client and server sides. While client-side validation can prevent empty form submissions using HTML attributes, it can be bypassed by users who manipulate the page through developer tools. Therefore, server-side validation is crucial to ensure data integrity. The process involves checking if fields are populated and valid, such as ensuring text fields aren’t empty after trimming whitespace and verifying that an email contains an "@" symbol. Additionally, it involves checking file uploads for validity. If any input is invalid, an error is thrown, though this approach isn’t ideal as it discards user input, suggesting a better method would be to display error messages on the same page to improve user experience.

The text explains how to handle validation errors in a more elegant way using Server Actions and the useFormState hook in React. Instead of redirecting or throwing errors, you can return serializable response objects from Server Actions, which can be accessed in your components. The useFormState hook, which is similar to React’s useState, helps manage the state of a form that uses Server Actions. It requires two arguments: the Server Action to be triggered (e.g., shareMeal) and the initial state of the component. This hook returns an array with two elements: the current state and a form action. The form action must be set as the value for the form’s action prop, allowing useFormState to manage the component’s state based on Server Action responses. The text also highlights the need to adjust the shape of the Server Action to accept two parameters and to ensure that useFormState is executed in a client component by using use client. This setup enables you to display error messages on the form based on the response returned by the Server Action.

The content discusses a problem encountered when transitioning a Next.js application from development to production. During development, everything works fine using a development server, but issues arise in production due to Next.js’s aggressive caching and pre-rendering strategies. When the application is built for production using npm run build, Next.js pre-generates pages that can be pre-rendered, such as non-dynamic pages. This results in faster initial load times, as the pages are cached and instantly available to users. However, the downside is that dynamic content, like newly added meals in this application, does not get re-fetched or updated in real-time, leading to missing data. The caching mechanism prevents the re-execution of code that fetches dynamic data, which causes discrepancies between the development and production environments. This behavior is problematic as it doesn’t reflect real-time changes in the data presented to users.

To address the issue of NextJS caching too aggressively, you can use the built-in function revalidatePath. This function allows NextJS to clear and revalidate the cache associated with specific route paths whenever data changes, such as when a new meal is added. By default, only the specified path is revalidated, but if you have nested paths relying on the same data, you need to revalidate those separately or set the second argument to layout to revalidate the entire layout, including nested pages. Revalidating means NextJS discards the old cache for those pages, ensuring updated data is reflected. For instance, revalidating /meals after adding a meal ensures the meals page reflects the new data. Running npm run build and npm start again will rebuild and cache the pages, but the cache will be correctly revalidated upon adding new data. This process ensures that dynamic content updates correctly without over-caching issues.

The content explains an issue with missing images when running a NextJS production server. The images were stored in a public folder, which is accessible during development but ignored in production because the server uses a .next folder instead. This means images added after deployment won’t be recognized. The recommended solution, as per NextJS documentation, is to use external file storage services like AWS S3 for files generated at runtime. However, implementing AWS S3 is considered beyond the course’s scope, but additional resources are provided for those interested in learning how to use it for storing and serving user-generated images.

The content discusses finalizing an application by fixing a styling error in the CSS, which had already been corrected in previous attachments. The main focus then shifts to adding metadata to web pages using NextJS. It explains how metadata constants are used in the root layout.js file to provide search engine and social media visibility. The metadata fields, such as title and description, can be set globally in the layout or specifically for individual pages, with precedence given to page-specific metadata. The text also touches on the challenge of adding metadata to dynamic pages, where static metadata does not suffice.

The text describes how to add metadata to dynamic pages in Next.js by using an async function called generateMetadata, rather than exporting a constant or variable. This function is executed by Next.js if no other metadata is found, and it receives the same data as the page component, including params. This allows for generating metadata based on dynamic data, such as a meal’s title and summary. However, if an invalid slug is entered, an error occurs because metadata generation fails when attempting to access properties on an undefined meal. To handle this, an if-check should be added to call a notFound function if the meal is not defined, ensuring the not-found page is displayed instead of an error.

This section provided an in-depth exploration of NextJS, focusing on the App Router and how to set up routes using the file system with special file names like page.js and layout.js. It covered handling errors with error.js and not-found.js, and managing loading states with the loading JS file. The section emphasized the use of suspense for more granular control and configuring dynamic routes for unknown path segments, such as pages for individual meals. It explained that all pages export standard React components, which are special server components rendered on the server in NextJS. The concept of client components was introduced, highlighting the use of the use client directive for client-side functionality. The section discussed Server components and Server Actions for fetching data directly in components, and how to use these with form elements via the action prop and hooks like useFormState and useFormStatus for UI updates. It also covered NextJS’s aggressive caching and the importance of using revalidatePath to ensure data accuracy. The need to test apps in production mode was emphasized due to potential differences from development mode. Finally, metadata management for pages was discussed, providing a solid foundation to use NextJS with its App Router in future projects.

The content discusses the two routing approaches available in NextJS for building full-stack web applications with React: the App Router and the Pages Router. The App Router is the modern and recommended approach, while the Pages Router is the older, more stable method that was previously the only option. Despite the App Router being the future, the Pages Router is still relevant, especially for older projects. The NextJS documentation allows users to switch between these two versions to learn about both methods. The content advises learning about the Pages Router for its stability and relevance to existing projects, and it provides lectures on this approach for those interested.