Telerik blogs
ReactT2 Dark_1200x303

Let's explore the new features that shipped with Next.js 9.4, including fast refresh, integrated web vitals reporting, new environment variables support and more.

Next.js

Next.js is well known as the React framework for static pages, progressive web apps, mobile web apps, SEO-friendly pages and, most especially, server-side rendering. It facilitates static exporting with just a line of command and ships with a CSS-in-JS library styled JSX. It also includes features such as code-splitting, universal rendering and hot reloading.

Let’s take a detailed look at some of the most noteworthy new features that shipped with the latest version of the framework: Next.js 9.4 — things like fast refresh, incremental static regeneration, new environment variables support, improvements in built-in fetch support, web vitals reporting and improvements in log output.

Fast Refresh

Fresh off the grill, the new version of Next.js has fast refresh enabled by default for all projects. This gives us a new hot reloading experience with instant feedback on edits that you make to your React components.

Even though hot reloading as a concept is not entirely new, before now, due to the fragility of enabling hot reloading by default in their projects, Next.js actually used to implement a coarse form of hot reloading that would always reset state of your app. The problem with the coarse form was resilience to runtime errors and compilation errors. Even if you made a typographical error while editing a CSS stylesheet for instance, your app reloaded and state would reset. This was not as efficient.

Using React Refresh, the fast refresh in Next.js integrates into React to handle predictable updates to your React component tree. This ensures that Next.js only updates code inside the file you edit and only re-renders that component without losing the component state. This includes CSS rules (whether inline, CSS-in-JS or SASS), HTML and effects.

Integrated Web Vitals Reporting

Recently Google introduced this Core Web Vitals browser extension, which is basically a car mechanic shop for your web app (if your app was a car). It shows you quality ways to ensure that you deliver a great user experience on the web, and it perfectly integrates with Lighthouse. Metrics like loading time, interactivity and stability of your app are monitored like this:

Core web vitals: largest contentful paint, first input delay, and cumulative layout shift are shown, each with a range of good, needs improvement, or poor

As Next.js is known for fast performing web applications, taking advantage of these new web vital tools to ensure you know the health status of your Next apps, the team decided to introduce in collaboration with Google a new method. It is called reportWebVitals and it is exported in your components from pages/_app.js:

    // Will be called once for every metric that has to be reported.
    export function reportWebVitals(metric) {
      // These metrics can be sent to any analytics service
      console.log(metric)
    }
    function MyApp({ Component, pageProps }) {
      return <Component {...pageProps} />
    }
    export default MyApp

If you would like to use this method together with your analytics service of choice, kindly read about sending results to analytics here in the docs, and if you want to know more about the core web vitals, refer to the homepage here.

New Environment Variables Support

Through user and customer feedback, the Next.js team found that some companies who use Next had trouble knowing exactly when an environment variable is inlined into a browser bundle and when it is just available in the Node environment. Due to this, the Next team is announcing that they’ll ship this new version of Next with two fully backward-compatible features that will help solve this problem.

The first feature is that you can now prefix the environment variable with NEXT_PUBLIC_ to expose it to the browser. When it is used, it will be inlined into the browser JavaScript bundle. This means you do not have to add a next.config.js and the env key to expose variables.

    // pages/index.js
    // The environment variable will be exposed to the browser
    console.log('My Application Version', process.env.NEXT_PUBLIC_VERSION)
    export default function HomePage() {
      return <h1>Hello World</h1>
    }

Secondly, Next.js now supports the .env loading by default, so that you can easily define dev and production environment variables. If you want to know more about the environment loading, read the docs here.

Essentially with these new improvements, using environment variables will become easier and way clearer than it was. This is because environment variables will only be available in the Node.js environment by default, and the variables prefixed with NEXT_PUBLIC_ will be exposed to the browser.

Improved Built-in Fetch Support

So in the 9.1 version of Next.js, polyfilling of the fetch API in the browser was announced, and now in this newest version, 9.4, it has been extended to the Node environment. This means that you do not have to use any type of server-side polyfill to fetch, like node-fetch — Next.js will now automatically provide fetch() in all environments.

A good example is when using getStaticProps, which gets executed using Next.js at build time:

    export async function getStaticProps() {
      // fetch no longer needs to be imported from isomorphic-unfetch
      const res = await fetch('https://.../posts')
      const posts = await res.json()
      return {
        props: {
          posts
        }
      }
    }
    function Blog({ posts }) {
      // Render posts...
    }
    export default Blog

Absolute Imports and Aliases

Depending on the directories, if your project is large, there is a chance that some of your import statements will suffer from the dots and backslashes dilemma:

    import Button from '../../../../components/button'

In cases like this, you can use absolute imports instead of using relative imports. So if the components directory is in the root folder, importing the button may just take this line:

    import Button from 'components/button'

With the new Next.js version, it gets even easier to do absolute imports for both JavaScript and TypeScript projects — just add the baseUrl configuration to the JavaScript project’s [jsconfig.json](https://code.visualstudio.com/docs/languages/jsconfig#_jsconfig-options) file or to the tsconfig.json file for TypeScript projects.

    // jsconfig.json or tsconfig.json
    {
      "compilerOptions": {
        "baseUrl": "."
      }
    }

This allows absolute imports from the root folder — it integrates well with Visual Studio Code and other editors that support code navigation. If you have already modified your webpack module alias config to have absolute imports, it would be removed as you upgrade.

Additionally, you can use the path option, as Next.js also supports its use to create custom module aliases. A good example is the code block below to use @/design-systeminstead of components/design-system:

    // tsconfig.json or jsconfig.json
    {
      "compilerOptions": {
        "baseUrl": ".",
        "paths": {
          "@/design-system/*": ["components/design-system/*"]
        }
      }
    }

The aliases can be used like this:

    // Imports 'components/design-system/button'
    import Button from '@/design-system/button'

Remember that if you use the paths option, you must specify baseUrl first. To learn more about paths, you can take a look at the TypeScript docs.

Configurable SASS Support

Built-in SASS support actually shipped in the last version Next, 9.3, and during that period the team at Next got user feedback that some users would like to configure the SASS compiler to modify things like the includePaths. In this new version of Next.js, it is now possible to do this by using the sassOptions key in next.config.js:

    const path = require('path')
    module.exports = {
      sassOptions: {
        includePaths: [path.join(__dirname, 'styles')]
      }
    }

Improved Log Output

The Next.js CLI has also been redesigned with this new version. It is now more consistent and outputs less duplicate data like the deployment link, waiting on dev server to start and other things that are usually repeated. The spacing of the texts are now also consistent, so there is no more jumping from one line to another.

Conclusion

The Next community has been showing growing use over time, as evidenced by its over 1,000 contributors, 48,000+ GitHub stars, vast number of example directories. These numbers are increasing month to month, speaking to growing ability of this community, and the Next.js team is fully committed to improving the developer experience and optimizing the Next product.


5E9A474B-EBDB-439E-8A4A-3B041B0BEDA6
About the Author

Nwose Lotanna Victor

Nwose Lotanna Victor is a web technology enthusiast who documents his learning process with technical articles and tutorials. He is a freelance frontend web developer based in Lagos, Nigeria. Passionate about inclusion, community-building and movies in Africa, he enjoys learning new things and traveling.

Related Posts

Comments

Comments are disabled in preview mode.