So NextJS is essentially opinionated React…plus? Okay, I’m listening.

I’m running through a great Frontend Masters class to learn the basics of the latest version of NextJS (that’d be 13, with the introduction of the new app directory and removal of the pages directory).

It’s been awesome (Scott Moss is not only a great instructor but is a really smart dude in general - check out his LinkedIn someime), but some of the latest changes in the 13+ version of NextJS have made even the latest class already be a touch out of date (example: the head file discussed in the class no longer exists in 13.3 in favor of a metadata. Sidenote, these words only sort of having meaning to me).

Stuff I’ve learned about NextJS so far⌗

File-based routing⌗

All your routes in Next are separated and set up via files and directories - no massive route file to be found here. In fact, the whole structure of Next is entirely based on directories. I don’t love that the root page file of each directory is named page (this seems like it could get kind of annoying to track tabs in your IDE), but it’s still incredibly slick and easy to understand from a routing perspective.

This site has a main index-type root for the homepage (app), and then 3 sub-routes: blog, about, and contact:

- /app
  - /blog
    - page.js
  - /about
    - page.js
  - /contact
    - page.js
  - page.js

Components are, by default, rendered on the server⌗

This was a bit of a mind-blowing moment for me - you can actually run server code in your React components because by default your components are completely rendered on the server, not the client. This is as opposed to vanilla React, which is of course completely rendered on the client, and different from SSR in that it streams the data as it resolves to the rendered HTML versus serializing all the data at once and sending it to the client with the HTMl to hydrate it (SSR is not a pattern I’m super familiar with, but this vaguely makes sense to me).

What a twist gif

Server Component data fetching is DOPE⌗

Dude, doing data fetching in a server component is awesome - not only does it have a bunch of general advantages like bette API security (you don’t need an API), and direct access to the DB(!) but you can also asynchronously render your component based on data availability! Tired of setting up a useEffect hook and checking your data availability in your JSX? Now you don’t have to!

const getData = async () => {
    return await fetch()
}

export default async function MyPage() {
    const data = async getData()

    return (
        <div>This won't get rendered until the data is available!!</div>
    )
}

Async components? Whaaaaat.

API data fetching for Client Components is cool, too!⌗

You’ll likely eventually hit a point where you need an API. Just like with your page routes, you use directory structure to structure out your API routes as well.

One Major Downside?⌗

Which is not to say that everything about NextJS 13 is perfect.

Because of the new breakdown between client and server components, there appear to be zero component libraries available and ready to work with this…paradigm? <buzzword> In a lot of cases a wrapper with use client at the top (this denotes a client component) will get you to where you need to be, but that certainly lacks finesse - you may not want that component to be a client component.

Having to craft my own components will obviously slow things down, but that’s the price you pay for brand new technology.

Anyway⌗

Regardless, this seems pretty great. I’m digging the simple routing both for pages and API, the idea of async components to aid in data loading…I’ll just have to spend some time either buildling my own components or massaging somebody else’s! More to come, I’m sure.

Learning NextJS