Add get-pathname function#59909
Conversation
alexdln
requested review from
feedthejim,
huozhi,
ijjk,
shuding,
timneutkens,
wyattjoh and
ztanner
as code owners
|
Allow CI Workflow Run
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer |
1 similar comment
|
Allow CI Workflow Run
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer |
|
Allow CI Workflow Run
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer |
|
Thank you so much for this @vordgi! We desperately need this in our project as the old workarounds no longer work. |
|
Thanks @vordgi for the initiative for this server feature |
|
Thanks for the work @vordgi! I was surprised to learn this was non existent in NextJS. |
|
Great work, this is unblocking all i18n apps using app router. |
|
@ijjk @timneutkens can we please merge this ASAP? This fixes one of the most critical issues people have with Nextjs, and people are resorting to forking #43704 |
|
For everyone who came to this PR not from discussions - there is no need to fork next.js, I made a package with this function (and a couple of others) and you can use it to check the getter - https://github.com/vordgi/next-impl-getters P.S. Next.js team, I think for v14.2, it’s probably time to make server getters! UPD: The new package update includes server contexts |
|
wen merge |
|
One more attempt to solve problem - getPageContext PR#65897 |
|
I hope the rootParams will also cover the cases mentioned in this PR Thank you all for your participation and attention to PR ❤️ |
Where can I get more info about the
|
|
@MurzNN As far as I know, this hasn't been particularly described yet, but in linked release it was removed as experimental and became stable Probably the best place to learn more and track progress is this issue - amannn/next-intl#663 (comment) And probably amannn's socials |
9 participants
Since this PR is not being merged, I'll leave a recommendation to use @nimpl/getters at the top here.
Adding a feature
What?
Ability to obtain the path in server components
Why?
I understand the concept of RSC - to build server-side and reuse, but restricting the retrieval of data about the current page internally seems excessive to me. Currently, we have to pass props with paths or keys and params through multiple levels of nesting.
For example, these are server-side translations (which require a lang param), pre-assembled card blocks with slight variations in several cards depending on the page, and different banners for individual pages.
Now people use headers, stores and other crutches to solve this - #50405, #43704, stack overflow 1, stack overflow 2
Also, my examples can be solved through a client-side component that returns one of the two passed server components or translations, but we don’t wanna pass all variations to the client. It can be done dynamically, but these data are needed on the page immediately for maximum SEO.
In the result, we are not creating an identical component because we pass unique data through props.
At the same time, I am not very fond of the idea of extending the hook - on the server, it will not be a hook, these are specifically getters. Moreover, a client-side hook can be synchronous, while a server-side getter for the same task can be asynchronous.
How?
I added a new function called
getPathnameto thenext/navigationmodule.The logic of the getter replicates the logic of preparing the path in the context of the
usePathnamehook. I also added an error for server-side getters, stating that they cannot be used on the client.Fixes #50405, #43704 (in the part about the pathname)