-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
App directory support with servercomponents #442
Comments
Not yet. But I'm actively looking into it. I'll post an update soon. |
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 ;) |
It looks like this piece of code is using the I did some investigation and the error occurs at the moment when some of the The When I started searching the web for some examples of 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 I hope that Chapter Three will take a closer look at this in the near future. |
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' |
Any update on this matter @shadcn? |
@shadcn have you started with a prototype already and/or could we help with implementing this? |
@shadcn I am also very interested in this feature. Is there any info about it? |
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. |
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. |
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! |
Curious on a status update for this issue. Vercel is recommending App Router for some of our use cases. |
@marcinmaruszewski’s comment above is exactly the issue.
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.
I'm working on a PR for this. And hoping to get it done before/during Drupalcon Lille. |
I experimented with switching from 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 Looking more closely at 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 |
@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:
you could simply use this in components that are compatible with both client and server:
And this with components that can only be used client side. |
Yeah, the "client" part of the path is mildly confusing. The "client" in
Yep, but that's a breaking change. The problem we also need to solve is that Next.js specifically designed the App Router to be compatible with the So there are two paths to fixing that:
I feel like option 1 is too disruptive a change. Option 2 may require a disruptive change later (when 2.0.0 comes out), but that will come with major refactoring where the change will feel like it's worth it.
Thanks for the tips! I'll read over that. |
New features should come as new minor version. It should come as fast as possible. |
So Also, I found this issue with
I think, yes. I've created a My draft PR includes these 6 new entry points: import * from "next-drupal"; // All the exports, same as 1.6.0 release.
import * from "next-drupal/client";
import * from "next-drupal/navigation"; // The only one that is not Server Component compatible.
import * form "next-drupal/preview";
import * from "next-drupal/query"; // Contains get[DrupalThing] functions.
import * form "next-drupal/translation";
import * from "next-drupal/utils"; |
Ok. An experimental build with the new entry points is now available on npmjs.com.
I'm going to start my own testing in a project, but it would be great if others try it out too. The more testing now the sooner we'll have a real release. Also, keep the comments about this solution coming. They are most welcome! |
We had some internal discussions and decided we need to map out the upgrade path properly before deciding on the actual solution. Right now, code using Next Drupal fall into 3 categories:
Everything is client-side code so a single entry point is fine. Configuring Since Next.js supports both App Router and So the next major version of Next Drupal will need to support all of these scenarios at the same time:
Scenario 5 means Scenarios 3 and 4 mean the entry points for all the other current functions and classes need to be available in an entry point that does NOT contain Client-Component-only code. In a previous comment I said:
Actually, I was wrong. All we really need to do move The other path to fixing this issue is what is in the experimental release above. No breaking change now. Anyone creating App Router pages must use one of the new entry points. Then when 2.x, we can remove whatever exports from the default entry that we want. Which means the upgrade would be very similar to just releasing 2.x now. Which… sounds like path 1 with more steps? I'll create a new experimental release later this week. |
@JohnAlbin Separating breaking changes related to the App and Pages directories into their dedicated entry points, aligned with NextJs naming conventions, is a better approach. This would ensure that the pages directory, which is not set to be deprecated, can still be supported effectively. Great work 🙌. |
Fixes #442 BREAKING CHANGE: The useMenu() client hook has moved out of the main entry point and into its own entry point. Any import or require of that function needs to be updated: Old usage: ```js import { useMenu } from "next-drupal" ``` New usage: ```js import { useMenu } from "next-drupal/navigation" ```
Fixes #442 BREAKING CHANGE: The useMenu() client hook has moved out of the main entry point and into its own entry point. Any import or require of that function needs to be updated: Old usage: ```js import { useMenu } from "next-drupal" ``` New usage: ```js import { useMenu } from "next-drupal/navigation" ```
Fixes #442 BREAKING CHANGE: The useMenu() client hook has moved out of the main entry point and into its own entry point. Any import or require of that function needs to be updated: Old usage: ```js import { useMenu } from "next-drupal" ``` New usage: ```js import { useMenu } from "next-drupal/navigation" ```
Fixes #442 BREAKING CHANGE: The useMenu() client hook has moved out of the main entry point and into its own entry point. Any import or require of that function needs to be updated: Old usage: ```js import { useMenu } from "next-drupal" ``` New usage: ```js import { useMenu } from "next-drupal/navigation" ```
Fixes #442 BREAKING CHANGE: The useMenu() client hook has moved out of the main entry point and into its own entry point. Any import or require of that function needs to be updated: Old usage: ```js import { useMenu } from "next-drupal" ``` New usage: ```js import { useMenu } from "next-drupal/navigation" ```
Fixes #442 BREAKING CHANGE: The useMenu() client hook has moved out of the main entry point and into its own entry point. Any import or require of that function needs to be updated: Old usage: ```js import { useMenu } from "next-drupal" ``` New usage: ```js import { useMenu } from "next-drupal/navigation" ```
Sorry for the delay in getting back to this issue; I've had some health issues (kidney stone). But I've made 2 new experimental releases that support the App Router with Next.js v14 (using 2 different bundlers). We're doing some internal testing and aren't sure which bundler we will go with, but you can test out the releases at #600 or #583 I'm working on upgrading the basic-starter to use the App Router now (to help with our testing). |
Fixes #442 BREAKING CHANGE: The useMenu() client hook has moved out of the main entry point and into its own entry point. Any import or require of that function needs to be updated: Old usage: ```js import { useMenu } from "next-drupal" ``` New usage: ```js import { useMenu } from "next-drupal/navigation" ```
Fixes #442 BREAKING CHANGE: The useMenu() client hook has moved out of the main entry point and into its own entry point. Any import or require of that function needs to be updated: Old usage: ```js import { useMenu } from "next-drupal" ``` New usage: ```js import { useMenu } from "next-drupal/navigation" ```
Fixes #442 BREAKING CHANGE: The useMenu() client hook has moved out of the main entry point and into its own entry point. Any import or require of that function needs to be updated: Old usage: ```js import { useMenu } from "next-drupal" ``` New usage: ```js import { useMenu } from "next-drupal/navigation" ```
Fixes #442 BREAKING CHANGE: The useMenu() client hook has moved out of the main entry point and into its own entry point. Any import or require of that function needs to be updated: Old usage: ```js import { useMenu } from "next-drupal" ``` New usage: ```js import { useMenu } from "next-drupal/navigation" ```
Fixes #442 BREAKING CHANGE: The useMenu() client hook has moved out of the main entry point and into its own entry point. Any import or require of that function needs to be updated: Old usage: ```js import { useMenu } from "next-drupal" ``` New usage: ```js import { useMenu } from "next-drupal/navigation" ```
We've decided to go with the |
@JohnAlbin Hope your health improves rapidly and thank you for the update. tsup is what I go for too 👍 preconstruct would also have been great choice. |
@JohnAlbin my best wishes for a speedy recovery too. I have just followed this discussion and now I have the overall issue much more clear, anyway I am still struggling to understand how to use internal APIs which expect the Added here some details: #601 (comment) |
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.
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?The text was updated successfully, but these errors were encountered: