ReactJS

What's New in Next.js

Published Nov 25, 2020

Updated Feb 14, 2023

4 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

What's new in Next.js

On October 27th 2020, the first ever Next.js Conf streamed to an audience of more than 34K.

Let's go over the most important highlights!

Next.js v10

The new version of Vercel's framework was released, boasting exciting new features that directly affect website performance and Web Vitals Metrics, allowing developers to have a better impact in search results.

So what are these features?

New `Image` Component

One of the core metrics of the Web Vitals is the Largest Contentful Paint (LCP), and it directly affects user experience as a web application loads.

Often, images are not properly optimized to have different behaviour based on the visitor device. For example, you may be downloading a 1000x1000 pixels image and only rendering a 200x200 pixels image on mobile devices.

Luckily, this new version introduces a new Image component that acts as a drop-in replacement for the HTML <img> element, with the advantage that comes with built-in optimization for different devices. Under the hood, images rendered with the new Image compoonent will be lazy-loaded, and will only render when they are within the viewport.

Migration

Integrating the new Image component is as easy as replacing all img elements with the new component:

Before

<img alt="Company Logo" src="/images/logo.jpg" width="200" height="125" />

After

import Image from 'next/image'

<Image alt="Company Logo" src="/images/logo.jpg" width="200" height="125" />

One important thing to note is that the width and height props are required. Although one may think it will affect responsive layouts, this is not the case, because the image will be automatically made responsive based on the aspect ratio from the provided dimensions.

Internationalization

After 2 months of gathering feedback from the community, in an RFC, the ability to add i18n to a Next.js application is now built into the framework. Before this release, it was only possible through a custom server, which is not encouraged anymore by the Vercel team.

Instead, you can now easily configure a Next.js application to have i18n capabilities by just adding some extra parameters to the configuration file:

next.config.js

module.exports = {
  i18n: {
    locales: ['en','es'],
    defaultLocale: 'en',
  },
}

The routing can happen at two different levels; subpath routing (adds the locale as an URL path, i.e. https://miwebsite.com/es/about) and domain routing (reads the locale from an absolute URL, i.e https://mywebsite.es).

To enable domain routing, the configuration file will need to be slightly different:

next.config.js

module.exports = {
  i18n: {
    locales: ['en', 'es'],
    domains: [
      {
        domain: 'mywebsite.com',
        defaultLocale: 'en',
      },
      {
        domain: 'mywebsite.es',
        defaultLocale: 'es',
      },
    ]
  },
}

This new version also has automatic language detection on the / route by checking the Accept-Language header, which will be matched against the provided configuration.

Improved `Link` component

Trying to create a link to a dynamic route by using a combination of the href and as props was somewhat confusing before. However, now the next/link component only needs the href prop.

Before:

<Link href="/blog/[slug]" as="/blog/hello-world" />

After:

<Link href="/blog/hello-world" />

This is not a breaking change so you can still continue using both props. However, now it is more developer-friendly.

Blocking fallback for `getStaticPaths`

What makes Next.js stands over other frameworks is the ability to incrementally generate static pages. This means, if you are building an e-commerce platform with lots of products, you won't need to statically generate all pages at build time. Instead, you can opt in to incrementally generate the pages in getStaticPaths.

Starting in Next.js 9.3, you could opt-in to this by adding a fallback property in getStaticPaths. At build time, a static fallback page was generated so the first time a user visited a given URL, it would be served, and once the data was fetched, a new page would be served, and pushed to the CDN for subsequent loads.

However, now we have the ability to avoid showing a fallback page at all and instead blocking the render until the data has been fetched by just adding fallback: 'blocking' to the returned object from getStaticPaths.

Before:

export async function getStaticPaths() {
  return {
    fallback: true,
  }
}

After:

export async function getStaticPaths() {
  return {
    fallback: 'blocking',
  }
}

`notFound` support for `getStaticProps` and `getServerSideProps`

The getStaticProps and getServerSideProps methods implemented a new boolean property: notFound. By adding it, your users will be redirected to your 404 page.

export async function getStaticProps () {
  return {
    notFound: true,
  }
}

redirect support for getStaticProps and getServerSideProps

A redirect property was also added to both methods. Allowing you to redirect to either an internal or an external page, with the ability to also mark the redirect as permanent.

export async function getStaticProps() {
  return {
    redirect: {
      destination: '/new-page',
      permanent: true,
    },
  }
}

Vercel's Next.js Analytics

Although this is not related only with the framework, Vercel released Next.js Analytics, a new feature of the platform that collects analytics from real users by measuring Core Web Vitals and generating reports.

Next.js Commerce

If you are planning to spin up an e-commerce functionality on top of Next.js, you can just clone an all-in-one starter kit that includes all of the previously mentioned new features.

Moving forward

We are planning to release a series of Next.js articles in the upcoming weeks, including in-depth guides on how to create a Next.js application using all of the new features, including best practices and tips from the community. Stay tuned!

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Kevin Wolf
@kevinwolfdev @kevinwolfdev

Communication Between Client Components in Next.js

Communication Between Client Components in Next.js In recent years, Next.js has become one of the most popular React frameworks for building server-rendered applications. With the introduction of the App Router in Next.js 13, the framework has taken a major leap forward by embracing a new approach to building web applications: the concept of server components and client components. This separation of concerns allows developers to strategically decide which parts of their application should be rendered on the server and which are then hydrated in the browser for interactivity. The Challenge: Communicating Between Client Components While server components offer numerous benefits, they also introduce a new challenge: how can client components within different boundaries communicate with each other? For instance, let's consider a scenario where you have a button (a client component) and a separate client component that displays the number of times the button has been clicked. In a regular React application, this would typically be accomplished by lifting the state to a common ancestor component, allowing the button to update the state, which is then passed down to the counter display component. However, the traditional approach may not be as straightforward in a Next.js application that heavily relies on server components, with client components scattered across the page. This blog post will explore three ways to facilitate communication between client components in Next.js, depending on where you want to store the state. Lifting State to a Common Client Component One approach to communicating between client components is to lift the state to a common client component. This could be a React context provider, a state management system like Zustand, or any other solution that allows you to share state across components. The key aspect is that this wrapper component should be higher up in the tree (perhaps even in the layout) and accept server components as children. Next.js allows you to interleave client and server components as much as you want, as long as server components are passed to client components as props or as component children. Here's how this approach might look in practice. First of all, we'd create a wrapper client component that holds the state: ` This wrapper component can be included in the layout: ` Any server components can be rendered within the layout, potentially nesting them several levels deep. Finally, we'd create two client components, one for the button and one for the counter display: ` ` The entire client and server component tree is rendered on the server, and the client components are then hydrated in the browser and initialized. From then on, the communication between the client components works just like in any regular React application. Check out the page using this pattern in the embedded Stackblitz window below: Using Query Params for State Management Another approach is to use query params instead of a wrapper client component and store the state in the URL. In this scenario, you have two client components: the button and the counter display. The counter value (the state) is stored in a query param, such as counterValue. The client components can read the current counter value using the useSearchParams hook. Once read, the useRouter hook can update the query param, effectively updating the counter value. However, there's one gotcha to this approach. If a route is statically rendered, calling useSearchParams will cause the client component tree up to the closest Suspense boundary to be client-side rendered. Next.js recommends wrapping the client component that uses useSearchParams in a boundary. Here's an example of how this approach might look. The button reads the current counter value and updates it on click by using the router's replace function: ` The counter display component is relatively simple, only reading the counter value: ` And here is the page that is a server component, hosting both of the above client components: ` Feel free to check out the above page in the embedded Stackblitz below: Storing State on the Server The third approach is to store the state on the server. In this case, the counter display component accepts the counter value as a prop, where the counter value is passed by a parent server component that reads the counter value from the database. The button component, when clicked, calls a server action that updates the counter value and calls revalidatePath() so that the counter value is refreshed, and consequently, the counter display component is re-rendered. It's worth noting that in this approach, unless you need some interactivity in the counter display component, it doesn't need to be a client component – it can be purely server-rendered. However, if both components need to be client components, here's an example of how this approach might look. First, we'll implement a server action that updates the counter value. We won't get into the mechanics of updating it, which in a real app would require a call to the database or an external API - so we're only commenting that part. After that, we revalidate the path so that the Next.js caches are purged, and the counter value is retrieved again in server components that read it. ` The button is a simple client component that calls the above server action when clicked. ` The counter display component reads the counter value from the parent: ` While the parent is a server component that reads the counter value from the database or an external API. ` This pattern can be seen in the embedded Stackblitz below: Conclusion Next.js is a powerful framework that offers various choices for implementing communication patterns between client components. Whether you lift state to a common client component, use query params for state management, or store the state on the server, Next.js provides all the tools you need to add a communication path between two separate client component boundaries. We hope this blog post has been useful in demonstrating how to facilitate communication between client components in Next.js. Check out other Next.js blog posts we've written for more insights and best practices. You can also view the entire codebase for the above snippets on StackBlitz....

Jun 21, 2024

5 mins

NextJSReact

Tim Neutkens, Co-Author of Next.js on the State of Next

Watch this episode! Tim Neutkens, Co-author and Tech Lead for Next.js, discusses how open source maintainers are simplifying the web, and covers the challenges faced with the current Next.js setup. Tim talks about TurboPack, a solution that optimizes bundling, improves parallelism, caching, and module graph calculations. He also talks about TurboAC, which focuses on addressing performance and compatibility issues, providing seamless transitions for Next.js users. Tim highlights the importance of efficient bundling processes to avoid excessive recompilation and discusses the updates in Next.js versions to enhance caching, rendering behavior, and client-side caching. Tim also discusses some exciting upcoming features in Next.js 15. Tim Neutkens' Socials - Twitter: @timneutkens - GitHub: timneutkens - Bluesky: timneutkens.bsky.social - Website: https://timn.tech/ Links - Vercel on Twitter, LinkedIn, Facebook, Instagram, YouTube, GitHub and Vercel's website - Next.js on Twitter, GitHub, LinkedIn, YouTube, Instagram, Facebook, official Next.js website - Turbopack on Twitter, GitHub, YouTube, LinkedIn, Instagram, Official Turbopack Docs - Webpack on GitHub, Twitter, YouTube, and Official Webpack Website Show Notes - [00:00:02] Podcast episode featuring Tim Neutkens discussing Next.js and the upcoming release of TurboPack. - [00:04:27] JavaScript bundlers evolving to handle growth. - [00:07:58] TurboPack solves Webpack limitations efficiently. - [00:12:12] Bundler compatibility for optimal app performance. - [00:16:50] Client components separated in webpack instance. Turbo pack for better parallelism and stability. Industry moving towards server-side. Feed and rollup still relevant. Collaboration between tools for future. - [00:20:57] Replacing part with roll down, similar to Webpack. Overlapping ecosystem with Avonetic Conference. Limits with unbundling and loading on demand. Cycle of building frameworks and hitting limits. History of using Webpack for client-side code. Two compiler architecture for server and client. Coordination between server and client with Webpack. - [00:25:38] Server action imports, turbo pack improves performance. - [00:30:04] Next.js is popular for websites. - [00:34:18] Chipotle using Next in Vercel, exciting improvements. - [00:38:51] Next.js 15 release candidate with changes. This episode is sponsored by Wix Studio....

Aug 7, 2024

2 mins

VercelNextJS

Supercharging Next.js Development with Tailwind CSS

Supercharging Next.js Development with Tailwind CSS When creating a new Next.js project (and in general, any React.js application), choosing a styling solution can be a time-consuming part of the process. While there are plenty of approaches to styling a React.js application, in this case, we are going to use TailwindCSS. Unlike CSS-in-JS solutions that only provide the styling system or component libraries that give you opinionated component styles, TailwindCSS provides you with a set of unopinionated utility CSS classes that your components can leverage to build your User Interface, with the chance of extending them via configuration files. Scaffolding our application > Note: We will use yarn across this guide, but feel free to use npm if that is your personal choice. Let's create a new Next.js application. While there is an official create-next-app CLI tool, we will manually scaffold our project to avoid removing unnecessary files created by it. Create a new directory and cd into it. ` Initialize an empty package.json ` Install required dependencies ` Create a homepage in pages/index.js By default, the Next.js filesystem router will pick all pages created in the pages directory and make them available as routes. pages/index.js ` Add dev, build and start scripts to our package.json package.json ` Now, let's run yarn dev to start your development server and navigate to http://localhost:3000 to preview your unstyled Home page. Configuring TailwindCSS We have a basic web application now, but its lack of styling, colors, and a nice font makes it look boring and lifeless. Install TailwindCSS as a devDependency ` Generate a TailwindCSS config file Run yarn tailwindcss init to create a tailwind.config.js file if you want to later customize the default configuration or add more plugins. Additionally, if you are using the TailwindCSS VSCode Extension, you will get intellisense completions for your class names. Create a Global Stylesheet In order to import TailwindCSS utility classes, we need to create a stylesheet in styles/main.css, where we will use the @tailwind directive to import all the required classes and set up some global styles. ` Import the Global Stylesheet To add a Global Stylesheet, we need to create a custom App and import it there. pages/_app.js ` Configure PostCSS If you run yarn dev and navigate to http://localhost:3000, you will see an unstyled page like the following: This is happening because Next.js doesn't know (_yet!_) what to do with the @tailwind and @apply directives. For that, we will leverage Next.js's built-in PostCSS support to parse our CSS file. Create a postcss.config.js file in your project root with the following code: postcss.config.js ` Now, let's restart our development server to see it working: Adding More Styles Now that our TailwindCSS config is working and PostCSS is compiling, we can start consuming those rules in our app routes. Let's edit our Home Page to make it look better. pages/index.js ` It should look like this: Optimizing Build Result Our Next.js project is successfuly set up to use TailwindCSS 🎉. However, we can still run some optimizations to make it work with all browsers and reduce final CSS file size. Polyfill modern CSS Most modern webapps use modern CSS features that old browsers does not support, and manually covering all cases can be frustrating, time-consuming and pointless since we have tools like PostCSS Preset Env that can automate the process. Install postcss-preset-env ` Add postcss-preset-env as a plugin to postcss.config.js postcss.config.js ` Refer to the postcss-preset-env documentation for more details on how it works and what it solves. Purge unused utility classes If we run the yarn build command, we will notice some warnings from the PostCSS step: ` This is happening because the final build is including all of the TailwindCSS utility classes, which will create a *huge* StyleSheet and we don't want to slow down the page load for our users. Luckily, TailwindCSS config has an option to control the file size that we can leverage by configuring the purge property of our tailwind.config.js file. tailwind.config.js ` By using that configuration, PostCSS will analyze the code within components and pages directories, extract class names and match them with our generated TailwindCSS utility classes. This means the final CSS file will only have the neccessary classes to work and no dead code ✨. Moving forward We have concluded our mini guide on how to Supercharge your Next.js Development with TailwindCSS. Pretty easy, right? I personally think the folks at Vercel have been really working hard to make integrations like this as seamless as possible. If you want to keep digging into the available utility classes, how to customize your configuration, add more variants or even create your own plugins, refer to the TailwindCSS documentation. Also, if you just want a sneak peak on what you can do with TailwindCSS without creating a new project, go to the Tailwind Play tool where you will be able to try it in your browser. If you want a finished code sample, refer to this GitHub repository....

Oct 21, 2020

5 mins

ReactNextJSTailwind CSS

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

Understanding the Difference Between :focus and :focus-visible in CSS I have learned my fair share about the importance of keyboard accessibility, so I know that visual indication of the focused element is very important. But the well-known :focus pseudo-class is not always the best fit for this job. That's where :focus-visible comes in. Let's look at the differences between these two pseudo-classes and explore the best practices for using them effectively. What is the :focus Pseudo-Class? The :focus pseudo-class is a CSS selector that applies styles to any element that receives focus, regardless of how that focus was triggered. This includes focus events from keyboard navigation, mouse clicks, and touch interactions. Example Usage of :focus ` In this example, the button will display a blue outline whenever it is focused, whether the user clicks on it with a mouse, taps it on a touchscreen, or navigates to it using the keyboard. What is the :focus-visible Pseudo-Class? The :focus-visible pseudo-class is more specialized. It only applies styles to an element when the browser determines that the focus should be visible. This typically occurs when the user navigates via the keyboard or assistive technologies rather than through mouse or touch input. Example Usage of :focus-visible ` Here, the button will only show a blue outline when focused through keyboard navigation or another input method that usually requires visible focus indicators. Key Differences Between :focus and :focus-visible :focus - Behavior: Applies to any element that receives focus, regardless of the input method. - Use Cases: Ensures that all interactions with the element are visually indicated, whether by mouse, keyboard, or touch. :focus-visible - Behavior: Applies styles only when the focus should be visible, such as using a keyboard or assistive technology. - Use Cases: Ideal for scenarios where you want to provide focus indicators only to keyboard and assistive technology users while avoiding unnecessary outlines for mouse and touch users, typically required by design. Accessibility Implications :focus - Pros: - Guarantees that all users can see when an element is focused, which is critical for accessibility. - Cons: - Can lead to a suboptimal experience for mouse users, as focus styles may appear unnecessarily during mouse interactions. :focus-visible - Pros: - Enhances user experience by showing focus indicators only when necessary, thus keeping the interface clean for mouse and touch users. - Tailors the experience for keyboard and assistive technology users, providing them with clear visual cues. - Cons: - Additional considerations may be required to ensure that focus indicators are not accidentally omitted, especially in older browsers that do not support :focus-visible. - There may be cases where you want to show focus indicators for all users, regardless of input method. Best Practices for Using :focus and :focus-visible To achieve the best accessibility and user experience, combining both :focus and :focus-visible in your CSS is often a good idea. Combining :focus and :focus-visible ` Here is a Stackblitz example of what such styling could look like for you to try out and play with. Additional Tips - Test with Keyboard and Assistive Technology: Ensure that your web application is navigable using a keyboard (Tab, Shift + Tab, etc.) and that focus indicators are visible for those who rely on them. It's never a bad idea to include accessibility testing in your e2e testing suite. - Provide Clear Focus Indicators: Make sure that focus indicators are prominent and easy to see. A subtle or hard-to-spot focus indicator can severely impact accessibility for users who rely on keyboard navigation. Conclusion The :focus-visible pseudo-class offers a more refined way to manage focus indicators, improving accessibility and user experience, particularly for keyboard and assistive technology users. By understanding the differences between :focus and :focus-visible, and applying best practices in your CSS, you can create more accessible and user-friendly web applications. Remember, accessibility should never be an afterthought. By thoughtfully applying focus styles, you ensure that all users, regardless of how they interact with your site, can easily navigate and interact....

Nov 8, 2024

3 mins

AccessibilityCSSPlaywright

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

What's New in Next.js

What's new in Next.js

Next.js v10

New `Image` Component

Migration

Internationalization

Improved `Link` component

Blocking fallback for `getStaticPaths`

`notFound` support for `getStaticProps` and `getServerSideProps`

Vercel's Next.js Analytics

Next.js Commerce

Moving forward

Kevin Wolf

You might also like

Communication Between Client Components in Next.js

Tim Neutkens, Co-Author of Next.js on the State of Next

Supercharging Next.js Development with Tailwind CSS

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

Let's innovate together!

You might also like

Communication Between Client Components in Next.js

Tim Neutkens, Co-Author of Next.js on the State of Next

Supercharging Next.js Development with Tailwind CSS

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

What's new in Next.js

Next.js v10

New Image Component

Migration

Internationalization

Improved Link component

Blocking fallback for getStaticPaths

notFound support for getStaticProps and getServerSideProps

Vercel's Next.js Analytics

Next.js Commerce

Moving forward

Kevin Wolf

Communication Between Client Components in Next.js

Tim Neutkens, Co-Author of Next.js on the State of Next

Supercharging Next.js Development with Tailwind CSS

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

Let's innovate together!

Communication Between Client Components in Next.js

Tim Neutkens, Co-Author of Next.js on the State of Next

Supercharging Next.js Development with Tailwind CSS

Understanding the Difference Between `:focus` and `:focus-visible` in CSS

New `Image` Component

Improved `Link` component

Blocking fallback for `getStaticPaths`

`notFound` support for `getStaticProps` and `getServerSideProps`