App directory support with servercomponents

[joellp]

Hello! I'm trying to get next-drupal working with the new app directory of Next.js. This does work for client components, but I cannot get it working for ServerComponents.

import { drupal } from "lib/drupal"
import { NodeArticle } from "components/node--article"
import { DrupalNode } from 'next-drupal';

const Article = async () => {
  // This requires "use client"
  const drupalContent = await drupal.getResource<DrupalNode>('node--article', 'bb601c1a-6e1f-4e09-9b42-ef07136963f4')
 
  return (
    drupalContent ? <NodeArticle node={drupalContent} />: <h1>Hi</h1>
  );  
}

export default Article;

When fetching resources a call to createContext is made, which requires me to use a client component. Is there a way to use this in Server Components?

[shadcn]

Not yet. But I'm actively looking into it. I'll post an update soon.

[MokDevelopment]

I think the app folder is not really usable yet. Not even ReactQuery seems to be usable … nor there is a best practice for language support. Somehow have the feeling the nextJs community tries to ignore the feature as long as pos ;)

[marcinmaruszewski]

It looks like this piece of code is using the next/router https://github.com/chapter-three/next-drupal/blob/main/packages/next-drupal/src/use-menu.tsx#L2. As far as I know NextJS this component is trying to get the current locale.

I did some investigation and the error occurs at the moment when some of the next-drupal methods are used. And it's because the use-menu.tsx is always included - https://github.com/chapter-three/next-drupal/blob/main/packages/next-drupal/src/index.ts#L11 included. This is how the webpack works.

The next/router is by use-menu.tsx in order to guess the current language context as part of NextJS i18n support.

When I started searching the web for some examples of i18n with NextJS 13 and the app directory I found this article - https://dev.to/ajones_codes/the-ultimate-guide-to-internationalization-i18n-in-nextjs-13-ed0. TLDR with the new app directory you have to handle i18n yourself in the middleware. This means that this repository should drop next/router and try to use the middleware to adapt to the new approach. But AFAIK that would be a Breaking Change.

There is also a second way. I have studied https://next-drupal.org/docs/fetching-resources and I see that i18n support is provided by the developer using the options.locale and options.defaultLocale parameters. IMHO we could remove support by reverting this commit 9463bd1. But I don't know what was the point of including this change. And it would also be another Breaking Change.

I hope that Chapter Three will take a closer look at this in the near future.

[JohnAlbin]

Next.js 13.4 was just released and the app directory router is no longer "beta"; it is a stable API. See the blog announcement here: https://nextjs.org/blog/next-13-4

My current project requires server-side rendering using Next.js' generateStaticParams and next-drupal can't be imported into a file that uses that Next.js function.

[amarincolas]

Any update on this matter @shadcn?

[trickreich]

@shadcn have you started with a prototype already and/or could we help with implementing this?

[taskrider2022]

@shadcn I am also very interested in this feature. Is there any info about it?

[sinyayadynya]

More and more people seems to be interested... @shadcn Maybe just to have an idea about any expected timeline for the next next-drupal update would be helpful.

[robdecker]

Adding app directory support (and all the implications that go along with it) is on our roadmap, but we don't have an eta yet.

@trickreich We are open to contributions if anyone is so inclined.

[MathiasGmeiner]

A while back, @shadcn mentioned in the #nextjs Drupal-Slack channel that the work has already started. @robdecker, could you share that progress as a starting point for those who are willing to participate? Thanks for your work so far!

[shrop]

Curious on a status update for this issue. Vercel is recommending App Router for some of our use cases.

[JohnAlbin]

@marcinmaruszewski’s comment above is exactly the issue.

It looks like this piece of code is using the next/router

it's because the use-menu.tsx' is always included

Yep. use-menu.tsx is using a client-side-only piece of Next.js' APIs.

There's nothing wrong with the code per se. The issue is that all of next-drupal is bundled into a single JavaScript module so you always import that client-only code even if you don't want to use it.

The quick fix here is to either change how microbundle bundles or to not bundle at all and just compile the multiple, existing TypeScript modules into multiple JS modules.

This fix is related to #528 [edit: nah. that issue can be done later.]

I'm working on a PR for this. And hoping to get it done before/during Drupalcon Lille.

[JohnAlbin]

I experimented with switching from microbundle to just using tsc to build the JavaScript. While that does work, it means that all the files in src become entry points.

For example:

import { DrupalClient } from 'next-drupal/client';
// ick.
import { useMenu } from 'next-drupal/use-menu';
import { getMenu } from 'next-drupal/get-menu';

And, frankly, none of those files names were meant to be entry points into the package, so I don't think this swap to tsc works.

Looking more closely at microbundle, I see it has the ability to specify multiple entry points, so I'm experimenting with that now. I hope to have an experimental PR out later today to celebrate the first day of Drupalcon Lille.

The fix for being App Router-compatible, will be to use the new entry points instead of the main entry point.

Current import code (that will continue to work in any 1.x release):

// Throws error in Server Components since it also imports useMenu().
import { DrupalClient } from 'next-drupal';

New import code:

// Can be used on Server or Client components.
import { DrupalClient } from 'next-drupal/client';

// Can only be used in Client components.
import { useMenu } from 'next-drupal/navigation';

Does anyone have any comments/concerns with this path? For example, do we need to add App Router support to codebases using next-drupal 1.0’s get[DrupalThing] functions? Hmm…

[Danishkhurshid]

@JohnAlbin I'm eager to find out your results with micro bundling. i have gone down the same path but ran into issues while microbundling with multiple entry points.

I'm also curious about whether it's possible and advisable to make 'next-drupal' the default entry point for exports that can be used in both client and server components.

So rather than doing this:

// Can be used on Server or Client components.
import { DrupalClient } from 'next-drupal/client  // the client export sounds like it can only be used in client components. 

you could simply use this in components that are compatible with both client and server:

import { DrupalClient } from 'next-drupal'

And this with components that can only be used client side.
import { useMenu } from 'next-drupal/client';