[Feedback] App Directory in Next.js 13 #41745

Please have a look at https://beta.nextjs.org/docs/app-directory-roadmap. One of the items is Improved Mutations. You can expect more guidance on how to handle forms and mutations soon!

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

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 it intentional that if the current segment is already in view, this still scrolls to the top of it? It means if I do some state mutation (click a toggle and update some backend state) and then call router.refresh() it's scrolling to the top of the segment which means the element you were just interacting with disappears from view.

Is there a way to not scroll on refresh?

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.

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

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).

you can have any file name on the side and just simply export it from page.tsx

Just adding to the sentiment that having multiple page.tsx files open in your editor can become unclear to which files they actually are. Right now I added the path in the tabs in VSCode to make a bit easier. And I also found my self using page.js as a mere export for my actual page component, which also feels a bit clunky indeed.

+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.

@sebmarkbage GTM adding tracking scripts and overlay widget html is a pattern that works just fine with __next div. At least, for me, not having issues with advertisers is much more important than hydrating <html> is cool. Not really expecting a positive outcome, but insofar as this is a place for [Feedback]: this is basically a deal killer for me. Thanks for the replies 👍

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

For those of you who haven't seen this yet, here's the note about them not being supported yet:

While API Routes still work, they currently have to remain inside of the pages/ directory.

https://beta.nextjs.org/docs/app-directory-roadmap#caveats

if /app is about the app, probably they should be moved from /pages/api to /api directly.

/app
/api

I think they want to move towards colocation (the correct choice), which means I hope they deprecate /pages/api in the future, and /api seems like it'd just fracture the API.

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 am still confused why a console.log("test") in a component labeled as 'use client' would produce "test" in both the browser console as well as the node terminal.

This was always the case for SSR, up until "React Server Components" which nextJS 13 is based on.

https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html

I'm setting up the app directory but I have no clue how to wrap it inside the provider. I tried to use "use client" but nothing changed.
I have shared my issue here: #42134

I see lots of confusion as to when the client components actually execute a render pass, as opposed to fully become interactive or render their async data (through the use hook).

From the model I understand, if I am a bot which runs no JS, and make a request for your page, I want to see the entire first server frame and includes "Server Components" + "use client" components, is that correct? That's what's happening and it makes sense, but I am seeing material and discussions where people want to directly access the DOM/Window just because we are in a "use client" component.

@icyJoseph As to my experience and understanding that is correct. "Client Components" is a misleading term since they render on both client and server. Better name would have been "Universal Components".

Universal Components makes sense to me

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! 🙏

Not sure if it helps, but with Next 13 and App directory you have to have a SSR server. You can't export the SPA as static files that you can serve in a CDN or something.
It's on the roadmap, see: https://beta.nextjs.org/docs/app-directory-roadmap

I tried your snippet and it works for me. Could you make a small reproduction for me to check out? 🙏

Hi,
did you already have a look into: https://beta.nextjs.org/docs/data-fetching/caching#per-request-caching

The cache function memorizes the result of a certain function called with the same arguments and deduplicates it. This might provide a solution to what you are looking for. I think that there is no need for a tag parameter as considering function identity and arguments for memorization should do that job already.

Best regards,
Michael

Hello Michael,
While reading the documentation I believe I must have missed the part about the cache function. This solves what I need to do exactly, thank you very much for reiterating it for me.

I have a lib function that looks like this now:

import { cache } from "react";
import axios from "axios";
export const getConfig = cache(async () => {
   ...
   var blabla = await axios.get(...)
   ...
});

But I have to have await getConfig() both in app/some/page.tsx AND in app/some/head.tsx.
So ultimately, it becomes only 1 external axios.get(...) for both things but the reality is that it's a lot more than just await getConfig(). I.e. there's more lines, there's some auth stuff, there's some post-processing etc.

I would prefer if I could do it just once and pass it down.

I was also looking for a solution to pass data from Layout components to Head and Page components:

• [Feedback] App Directory in Next.js 13 #41745 (reply in thread)
• Implement a way to get data on Head and Page from a single database query #44639 (comment)

Haven't seen a way to do this yet, but that would enable interesting patterns if it were possible.

Noted the same issue!

In a nutshell I'm trying to figure out a pattern where using 5 of the same, or different Server Components where each of those components are trying to fetch same data (with same params) to not hit database 5 times.
So instead of fetching data in page layout once and passing them as props I see that new Nextjs 13 appdir docs suggest using fetch() api which should achieve automatic dedupe.

Maybe you're looking for the cache() API, mentioned by the Next.js team at the links below:

• Implement a way to get data on Head and Page from a single database query #44639 (comment)
• [Feedback] App Directory in Next.js 13 #41745 (reply in thread)

Tnx @karlhorky . I somehow missed the part that cache() has been patched into fetch(). It might even make more sense to do it like this and move all the logic to some "service/repository/db access" functions that will get the data and not implement /api part at all. I will give it a go.

Yeah you need to add the following to your next.config.js

experimental: {
    appDir: true,
    serverComponentsExternalPackages: ['vscode-oniguruma', 'shiki'],
  },

@leerob would it be possible to add vscode-oniguruma and shiki to the default serverComponnetsExternalPackages?