Looking forward to this! Ideally, we could define mutations on the server and we can import them just like that on the client side and it works with typing and everything. Maybe something like https://github.com/Janpot/next-rpc would be awesome.

I think the ideal here would really be to have mutations and manually-triggered revalidations fundamentally use form POST/GET (as appropriate), so that you can have a page that works fine even with JS disabled. This would mean adding some handling around, e.g. form values being limited to strings, but I don't think that's really a hard blocker on anything. The need to route everything through client-side JS handling is IMO the biggest weakness with Next pre-13.x, and it would seem like a huge missed opportunity to me to not correct that with all the other emphasis on server-side handling.

@timneutkens I guess we are all excited to learn how the improved mutations and forms handle guidance will look (any teasers? ;)) I found using the RPC approach here quite promising. Both Server Components and Client Components using RPC have the same coding style when server-side functions can be just used directly inside React components. Let me share a quick example and a post to articulate the idea. Curious what you all think

Mutations are the biggest question left unanswered by the new app directory for me. For an app, as opposed to a what some would call a "standard website", mutating data is as important, if not more so, than fetching it. The temporary workaround in the documentation feels sketchy. Moreover, the "beta" status is causing major API libraries (such as TRPC and Apollo GraphQL) to not attempt definitive implementations for fear of breaking changes. I don't mean to sound demanding, but I strongly believe that implementing mutations in an effective manner should be a top priority.

I agree, literally bumped into needing do handle form data submissions, saw that mutations is still WIP. Very ampt for that to be sorted.

This might help explain the rendering equivalents a bit: https://beta.nextjs.org/docs/rendering/fundamentals

Right now on-demand revalidation already works, if the page uses static rendering which is the case when you don't have a bailout on the page like calling cookies, headers, or a fetch with cache: 'no-store' you can on-demand revalidate that page.

In the future this will be expanded to be more granular than per-page deciding static rendering or dynamic rendering.

I don't understand.
"cookies, headers, or a fetch with cache: 'no-store'" ==> this is work like getServerSideProps, alway call api and rerender from server, right?
I want page ISR, page render on build, and revalidate in background, for example i set it to 24h: next: { revalidate: 60 * 60 * 24 }, but suddenly i need to update new information, so how do i, for nextjs version 12 i use res.revalidate, so what something similar to res.revalidate in nextjs version 13, or is there another way to do the same function?

I've also used a bit of Route Segment Config Options. It lets you configure behavior in layouts or pages by exporting the variables settings to your needs.

Is there a way to see what's causing a page to server render as opposed to static render? I've tried using export const dynamic = 'force-static' and not even that gets next build to show a circle icon (static) next to the outputted routes. Maybe the icons are bugged, because it does say "Generating static pages (4/4)" and so far, that is about the number of pages I have.

I had the same problem when I used React Three Fiber.

I use Canvas for the parent layout, and I add CSS "displays: contents" too. I got the error "Error: R3F: Link is not part of the THREE namespace! Did you forget to extend? See: https://docs.pmnd.rs/react-three-fiber/api/objects#using-3rd-party-objects-declaratively"

I don't understand why we had "Link" in here. Is it because of the nested layout or not

It seems undesirable for the framework to generate div tags at will. The reason is that you can't know the side effects unless you search.

I didn't have a good solution because I didn't have enough knowledge. I'm sorry to point it out. 😢

Have anybody found a way to manually prevent scroll when using router? Having exactly same issue with toggling checkboxes as mentioned above.
To use display: contents workaround globally seems too much, because having scroll normally is good. But it seems to be impossible to localize it for specific page only.

Hi everyone, you'll be pleased to hear the app directory no longer adds additional <div>'s in the latest canary (13.0.7-canary.2). The scroll/focus management behavior is preserved.

I just love its awesome.

Opened a PR here: #41894 Thanks!

Thanks @timneutkens ! So do you recommend keeping reactStrictMode enabled even with the useEffect running twice? Is that normal behavior w/ strict mode? (nvm, this is new in react 18 facebook/react#24502)

It's a dev only hint that maybe something is wrong. ;)

https://beta.reactjs.org/learn/you-might-not-need-an-effect

It's a dev only hint that maybe something is wrong. ;)

https://beta.reactjs.org/learn/you-might-not-need-an-effect

Yes, but it should only work when StrictMode is turned on. StrictMode docs here

Your feedback is welcome, but I would advise against using emoticons in these scenarios, as they can be misinterpreted.

Definitely running into the same issue here, and since Turbopack does not support SCSS at this time it's not a viable option if your modules aren't using plain ol' CSS

As of next@13.0.1 this is supposed to be fixed, do try: #42106

using version 13.1.0 this is not just working. I simply followed the installation steps from the guide, and no styles are loaded in client, exactly as @made-by-jonny exaplained

It does work with Turbopack, not sure what the implications are. I guess it's not using proper CSS modules, but it's def. applying some scoping mechanism, generating classnames such as description◽[project-with-next]/app/page.module.css

It has been fixed with the latest version of next.

martpie/next-transpile-modules#280

You no longer have to use next-transpile-modules, there's a built-in option: https://beta.nextjs.org/docs/api-reference/next.config.js#transpilepackages

Is this expected to work with CSS Modules (file.module.css) as well?

Yeah it should, are you seeing something else?

When using CSS Modules with transpilePackages I'm seeing similar errors as described in #41856 (comment).

+1 to customizing file names. page.tsx everywhere gets hardish to track with a small app w/only a couple pages (in the POC I did), can't imagine what a large project would be like. In my mind, it doesn't scale as is and some of the suggestions here are on the right track.

@AndrewOttavianoAbb It's never gonna' happen.

We still talking about this? I think I'm gonna have to abandon this thread because it's just become the same repetitive complaints that have been answered 1,000 times.

It was nice to have this while it lasted. I would appreciate it if Vercel centralized all this into a referable blog so these threads that contain all the information don't get ruined and buried by random comments. Might be good to lock this at this point.

Naming is nice and clear, intuitive and understandable. I see no reason to change it or make customisable. Customisation bring a chaos among projects. Nextjs is a framework, frameworks have a lot of fixed stuff to make your work more easier.

I actually don't like the lmao lets put everything that's not a route thing in the route things folder ...

everything in pages/* should be a browser router. in fact I go as far to say that there should only be "routing" paradigms in the the pages folder.

everything else should be imported from outside the pages folder 👍🏻

components/
  landing/
    HomPage/
      index.ts
      styles.css.ts
      HomePage.tsx
      HomePageContainer.tsx
      HomePage.stories.tsx
      HomePage.test.tsx
    LandingCard/
      index.ts
      styles.css.ts
      LandingCard.tsx
      LandingCardContainer.tsx
      LandingCard.test.tsx
      LandingCard.stories.tsx
    ...

  otherarea/
    ...etc

services/
  Auth/
    index.ts
    ...
  Theme/
    index.ts
    ...
  Cms/
    index.ts
    ...

config/
  index.ts

pages/
  index.tsx
  

That the nextjs team encourage putting everthing in the app directory feels like shortsighted thinking.

next dev

ready - started server on 0.0.0.0:3000, url: http://localhost:3000
warn - You have enabled experimental feature (appDir) in next.config.js.
info - Thank you for testing appDir please leave your feedback at https://nextjs.link/app-feedback
warn - Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use at your own risk.

event - compiled client and server successfully in 1472 ms (267 modules)
wait - compiling...
event - compiled client and server successfully in 514 ms (267 modules)
wait - compiling /page (client and server)...
event - compiled client and server successfully in 1174 ms (597 modules)

http://localhost:3000/ browser stuck at loading

I think I experienced the same with lastpass extension in my browser. It auto adds an element when you have an input. I just have a normal form with label and input in it. I don't have an issue when I turn off the extension.

I got a bug report for Emotion recently that showcased to me how a Remix app gets broken with somebody's web extension. The root cause behind this that I've diagnosed is the same thing that is being discussed here - rehydrating the whole <html/>.

I'm not exactly sure what the real extension was trying to do. I only got a minimal repro that had this in the extension:

document.documentElement.appendChild(document.createElement('foo'))

Perhaps the issue reporters could shed some more light on what they are trying to achieve there to get some advice here. cc @flappyBug @lucascurti

While I agree that a lot of things can break the reconciliation - a custom container used as root was always a good enough boundary that allowed 3rd party things to work most of the time.

I'm also a little bit confused when it comes to useServerInsertedHTML. Things inserted when rendering the shell~ are inserted into <head/> and I'm not sure what kind of rule makes this OK here since that's bypassing React. How those extra <head/> children are OK? 🤔 cc @huozhi

The original issue @Andarist mentioned is here. I got report that some browser extension breaks our site style, including Urban VPN Proxy. I reviewed the compiled extension code, and reproduced a minimal extension to make this happen. The key point is that the extension injects new DOM element into the document in a content script runs at document_start

Another fun fact is to break React 18's hydrateRoot, one additional DOM element is enough. But to break the legacy hydrate, the extension need to append at least 2 DOM elements (no matter what).

Just got another hydration warning related to this when investigating another reported issue:

Warning: Extra attributes from the server: data-new-gr-c-s-check-loaded,data-gr-ext-installed,data-loom-blur-type

This one doesn't blow the SSRed content as far as I can tell - but it's still super annoying. Both Loom and Grammarly are super popular extensions

@sebmarkbage @timneutkens Wondering if the official position on this has changed at all?

In think, it would be great to include a suffix like *.function.js or *.function.ts within the directory specifically for creating serverless functions.

API Routes are now supported in the app/ directory since version 13.2.0 🎉 They are called Route Handlers and the convention is route.ts:

• Announcement blog post: https://nextjs.org/blog/next-13-2#custom-route-handlers
• Docs: https://beta.nextjs.org/docs/routing/route-handlers

How to get body in POST and PUT handlers?

export async function POST(request: NextRequest) {
  const body = await request.json();

Check out some examples here:

• https://github.com/upleveled/next-js-example-winter-2023-vienna-austria/blob/main/app/api/animals/route.ts
• https://github.com/upleveled/next-js-example-winter-2023-vienna-austria/blob/main/app/api/animals/%5BanimalId%5D/route.ts

thank you @karlhorky

the first div should be replacing #__next I assume, but since there is no ID to target, it might inject multiple more?

the first div should be replacing #__next I assume, but since there is no ID to target, it might inject multiple more?

#41745 (reply in thread)

You can read the reply here: #41745 (reply in thread) goal is to remove it but we can't do that yet 👍

Quick update: the app directory no longer adds additional <div>'s in the latest canary (13.0.7-canary.2).

I'm running into the same problem, but the workaround @IhsenBouallegue suggested solved the issue for me.

Does that mean that with the app folder it will no longer be possible to do domain-level-localization

No, you get full flexibility for whichever approach you want to take by leveraging middleware.js. Middleware allows you to rewrite an incoming hostname to a different path which is how that config option in Next.js does it.

Could you elaborate on how to exactly include localized text context with that approach or direct me to a resource?

Cannot read property '' of undefined
    at resolveModuleReference

For anyone getting this error just for using client components: Updating to 13.0.2 worked for me.

I'm also not sure how we can handle i18n stuff without a lang segment in the url.

domain.com > en website
domain.com/de > de website
domain.com/fr > fr website

Is it my part to check if the locale matched with on of my sites and if not it's the root / default site?

Does that mean that with the app folder it will no longer be possible to do domain-level-localization

No, you get full flexibility for whichever approach you want to take by leveraging middleware.js. Middleware allows you to rewrite an incoming hostname to a different path which is how that config option in Next.js does it.

Could you elaborate on how to exactly include localized text context with that approach or direct me to a resource?

I have been unsuccessful in getting middleware to load in nextjs 13.0.5 with turbopack, I only found this: https://stackoverflow.com/questions/74614404/middleware-in-next-js13-with-turbopack ... does anyone have any tips?

i'm having this same issue while trying to deploy to vercel...

@mike14747 , as you described, is it possible to use useSession() and getServerSession() in app/dashboard/users

Yeah, you will be able to use useSession() in client components and getServerSession() in server components.

Example of client component usage (my Authbar component):

'use client';

import Link from 'next/link';
import { signOut, useSession } from 'next-auth/react';
import Button from '../components/Button';

import styles from '../../styles/Authbar.module.css';

export default function Authbar() {
    const { data: session, status } = useSession();
    const loading = status === 'loading';

    return (
        <section className={styles.authbarContainer}>
            {loading && <>Loading...</>}

            {!session && !loading &&
                <p>
                    <Link href="/login?callbackUrl=/">
                        Login
                    </Link>

                    <span>&nbsp;/&nbsp;</span>

                    <Link href={'/register'}>
                        Register
                    </Link>
                </p>
            }

            {session?.user &&
                <>
                    <span className={styles.username}>
                        <>User: </>
                        <Link href="/profile">
                            {session.user.name}
                        </Link>
                    </span>

                    <Button onClick={() => signOut({ callbackUrl: '/' })} size="small" variant="text">Logout</Button>
                </>
            }
        </section>
    );
}

I use next-auth I wrapped _app.tsx by <SessionProvider> How can I add it in layout.tsx ?

If I wrap up layout.tsx with SessionProvider, I can't create Server side components inside it.
All children components should be client side component. That isn't good for new Next.js app router feature.
As much as possible, we need to have server-side components for app performance.
Could we have better approach to get session and manage protected routes and private routes?

@devHybrid0306
your layouts should be server components as much as possible.
you can have middleware that creates the web session and makes it available on inbound request as a cookie.
then your page/layout can extract the session from the request cookies.
you can also have middleware guarding your pages
below you can see what I use in my app.
nextjs uses the primary middleware.ts file which creates a pipeline of supplementary middleware filters that i've defined.

// /middleware.ts
import { NextResponse, NextMiddleware } from 'next/server';
import { SessionFactory } from './app/middleware/session-factory.ts';
import { AuthPageGuard } from './app/middleware/auth-page-guard';
import { foldLeft } from './utils/function.utils';

const factories = [
  SessionFactory,
  AuthPageGuard,
];
const base: NextMiddleware = () => NextResponse.next();
export const middleware = foldLeft(
  (factory, accumulation) => factory(accumulation),
  base,
  factories
);

// /app/middleware/middleware-factory.ts
import { NextMiddleware } from 'next/server';
export type MiddlewareFactory = (middleware: NextMiddleware) => NextMiddleware;

// /app/middleware/session-factory.ts

import { NextMiddleware, NextResponse } from 'next/server';
import { v4 } from 'uuid';
import { expiration, SESSION_ID } from '../../utils/cookie.utils';
import { routes } from '../../utils/route.utils';
import { MiddlewareFactory } from './middleware-factory';

// creates session and adds session id to inbound request cookies if one doesn't already exist
// stores session id as cookie on response if it doesn't already exist
export const SessionFactory: MiddlewareFactory = (next: NextMiddleware) => {
  const middleware: NextMiddleware = async (request, event) => {
    const secure = request.nextUrl.protocol.startsWith('https');
    const path = request.nextUrl.pathname;
    const match = routes.pages.patterns.some(pattern => pattern.test(path));
    if (!match) {
      return next(request, event);
    }
    const cookie = request.cookies.get(SESSION_ID);
    const sessionId = cookie ? cookie.value : v4();
    if (!cookie) {
      request.cookies.set(SESSION_ID, sessionId);
    }
    const result = await next(request, event);
    if (!cookie && result instanceof NextResponse) {
      result.cookies.set({
        name: SESSION_ID,
        value: sessionId,
        expires: expiration('years', 1),
        secure,
      });
    }
    return result;
  };
  return middleware;
}

// /app/middleware/auth-guard.ts
import { NextMiddleware, NextResponse } from 'next/server';
import { routes } from '../../utils/route.utils';
import { MiddlewareFactory } from './middleware-factory';

/**
  * request to /login or /register which already has an access-token is redirected to home page
  */
export const AuthPageGuard: MiddlewareFactory = (next: NextMiddleware) => {
  const patterns = [
    routes.auth.register.pattern,
    routes.auth.login.pattern,
  ];
  const middleware: NextMiddleware = (request, event) => {
    const path = request.nextUrl.pathname;
    const match = patterns.some(pattern => pattern.test(path));
    if (match && request.cookies.has('access-token')) {
      const parts = path.split('/');
      const locale = parts[1];
      const base = process.env.NEXT_PUBLIC_APP_BASE_URL;
      const url = routes.home.url(locale);
      const location = `${base}${url}`;
      return NextResponse.redirect(location, 303);
    }
    return next(request, event);
  }
  return middleware;
}

// /utils/function.utils.ts
export function foldLeft<I, A>(folder: (item: I, accumulation: A) => A, accumulation: A, items: I[]): A {
  if (items.length === 0) {
    return accumulation;
  }
  const [item, ...rest] = items;
  return foldLeft(folder, folder(item, accumulation), rest);
}

When I enable Turbopack (next dev --tubro), styles from CSS Modules are applied correctly, however, the naming of classes is quite strange.

For me it only works on next dev without Turbopack. It doesn't work when using next build; next start either.

This should be fixed on the latest stable version, can you check that? Thanks!

Tracking this here: #42010, thanks for reporting!

Please head to vercel/turbo#2312 with this feedback. Attaching a minimal reproduction repository with your post would be tremendously helpful for the team working kn Turbopack! 🙏

This is odd. My post have all the <. input. .> fields removed.

If you have a GitHub repo I can take a look.

I don't. New to all this. I follow what you are telling me. I think I tried it but I'm not sure. Will know tomorrow when I log in and try it.

Take a look at this page: https://stackoverflow.com/questions/76130675/react-with-nextjs-and-search-bar/76132882#76132882

I've changed HEADER since this post but I believe search-results/page.js hasn't change. I even think search-text/page.js is pretty much the same but maybe without the PROPS. I was trying different combinations trying to get something to work.

I added SearchResults into SearchText and it just runs SearchResults fetching the API over and over and over. I have to remove SearchResults from SearchText to get it to stop. But then there's no results.

I can attach the code if someone would like to look at it.

Found the issue. It would appear you can't have ASYNC as part of the function if the parent is a Client Component.

export default async function SearchResults( {query} ) {

So, what's the work around for resolving this?