Dayvi Schuster's blog
NEXT.JS is Evolving

NEXT.JS is Evolving

Here are my favorite new features, I've left the best for last.

Dayvi Schuster's photo
Dayvi Schuster
·

5 min read

TurboPack

So nextConf just happened and they announced a couple of super cool things like TurboPack, a next.js bundler that promises to be a lot faster than vite and insanely faster than webpack. How much faster you may wonder, well according to their announcement it promises to be 10x faster than vite, and 700x faster than webpack.

How much that will actually matter in the real world, I can't say. But it's definitely a step in the right direction and should help you keep those build minutes down on your favorite cloud provider.

OG Image Generation

Then there's OG Image generation, which is a super cool feature that I'm already using on my blog. Basically it let's you define a new API route that will act as an image generator. You provide the contents of the image via HTML and CSS and when you call the API route, it returns the image for you. Here's how it works: 

// pages/api/og-image.ts
import { ImageResponse } from "@vercel/og";
import { NextRequest } from "next/server";

export const config = {
  runtime: "experimental-edge",
};
export default function ImageGenerator(req: NextRequest) {
  const { searchParams } = new URL(req.url);
  const text = searchParams.get("text")
  return (
    <div
      style={{
        width: 1200,
        height: 630,
        backgroundColor: "white",
        display: "flex",
        justifyContent: "center",
        alignItems: "center",
      }}
    >
      <h1>{text}</h1>
    </div>
  );
}

Now every time you call the API route, it will return an image with the text you provided in the query parameters.

File System Routing Extended

Next.js had a file system router from it's very inception, but now that router is getting a huge update. Every directory can have an index.tsx or index.jsx well that's about to change with next13. They're opting for a more directory based approach with their routing. Basically all your routing will now live in an app directory and you define your routes in there by creating a subdirectory for each route. Furthermore you can template out your route with the following files:

  • page.tsx - the base component that you wish to display on that route e.g app/home/page.tsx may contain the home page component
  • layout.tsx - provides a shared layout for your route and all of it's subroutes
  • loading.tsx - will be rendered while the page is loading
  • error.tsx - will be rendered if an error occurs while loading the page

I'm not too sure how I feel about this, as I find that file system routing can quickly grow into a bit of a mess that may be hard to navigate. But luckily you can still use the old file system routing if you wish to do so and adopt the new one procedurally. Which is also a concern if I'm honest since we all know there's plenty of teams out there that will due to time pressure or other unforseen circumstances just get to migrate half of their app to the new file system routing. Which will force them to maintain two different routing systems in the same app. So if you're reading this and getting ready to port everything to the new file system routing, please make sure to schedule enough time for it to fully finish it. Save yourself the headache.

BUT I've saved the coolest feature by far for last

Data Fetching

Now this is the one feature I and many other developers are really excited about, what it means is that you can now simply add async to your component and it will automatically be treated as a react server side component. Meaning that it will be rendered on the server and streamed to the client. This is a huge step forward for next.js and will make it a lot easier to build apps that are fast and performant. Not to mention it will reduce the need for external third party libraries to do this for us such as React Query. How it works is:

// pages/index.tsx

export default async function Home() {
  const data = await fetch("https://api.example.com", {
    next: {
      revalidate: 60, // when to revalidate cache in secods
    }
  });
  return (
    <div>
      <pre>
        {JSON.stringify(data, null, 2)}
      </pre>
    </div>
  );
}

And there you have it a fully server side rendered component that will be cached for 60 seconds. Without the use of any third party libraries or the useEffect hook. This is a huge step forward for Next and I'm really excited to see what the future holds for it and how it will be used in the real world.

Important Note As of right now 27.Oct.2022 you can not use one server side component inside of another without vscode throwing a type error at you. Since a server side component is basically a promise and a promise is not a valid JSX or TSX element.

Conclusion

Next.js is evolving and I'm really excited to see what the future holds for it. I'm really looking forward to the next release and I'm sure it will be a lot of fun to work with. I'm also really excited to see how the community will use these new features and what kind of new libraries will be built around them.

Thank you

Hey just wanted to take a minute to say thanks for reading my article, if you liked it feel free to follow me on twitter or my personal blog over at dayvster.com

Hope to see you there!

webdevNext.jsReactTypeScriptJavaScript