Accessing pathname in getServerSideProps

[javiercr]

Hello,

Our project has quite complex i18n requirements. In short, these are some of our requirements:

1. Domain based locales: example.es (locale = es), example.co.uk (locale = en).
   This is now covered by Next.js 10 i18n routing.
2. Translating non dynamic route segments: pages/search.js should be accessible on example.es/buscar (es) and example.co.uk/search (en).
   This is not directly covered by Next.js but it's possible using rewrites.
3. Translating routes with dynamic and non dynamic segments: example.es/productos/product-1 and example.co.uk/items/item-1.
4. Linking to correct domain + translated route should be transparent: we want <Link href=/search"> to produce example.es/buscar or example.co.uk/search according to the current locale.
   We've solved this by creating our own wrapper of the official component, which uses useRouter() hook.
5. Return a 404 (or 301) for routes that do not belong to the current locale: example.co.uk/buscar and example.es/search should either not work (404) or redirect (301) to the proper domain + route combination.

In order to achieve all of this we've created our own routing manifest, a json file that looks like this:

{
  "/search": {
    "page": "/search",
    "locales": {
      "es": "/buscar",
      "en": "/search"
    }
  },
  "/products/[slug]": {
    "page": "/products/:slug",
    "locales": {
      "es": "/productos/:slug",
      "en": "/items/:slug"
    }
  }
}

This file is read by next.config.js to produce the rewrites:

async rewrites() {
  const routes = require("./lib/routes.json");

  const rewrites = [];
  Object.entries(routes).forEach(function ([name, route]) {
    Object.entries(route["locales"]).forEach(function ([locale, url]) {
      rewrites.push({
        source: url,
        destination: route.page,
      });
    });
  });

  return rewrites;
}

The routing manifest is also used by our <Link> component to build routes for the current locale.

In order to achieve 5. (404 or 301 on invalid domain-route combinations), we're using getServerSideProps to try to validate the route. There we can access the context object which contains params, req, query, locale and resolvedUrl among other things. However it does not contain pathname, which we would need in order to find the relevant route in our routing manifest.

Interestingly, the context object for getInitialProps does contain pathname.

Is there any reason why getInitialProps has access to pathname as part of context but getServerSideProps doesn't? Would you guys accept a PR adding pathname to getServerSideProps?

Also any suggestion on how to cover the requirements exposed above with a different approach are more than welcome.

[Timer]

We don't expose pathname because you can directly parse this from req.url. It's just not a necessary API!

If resolvedUrl isn't sufficient, you'll have to rely on req.url (resolvedUrl is the replacement to pathname from getInitialProps).

[javiercr]

Here is a codesandbox showcasing what I was explaining:
https://codesandbox.io/s/nice-roentgen-q5d2x

There, navigate to items/product-1 (doing a server side render). Those are different values that the one I get for pathname (products/[slug]) by debugging Next.js code or using my own fork (that passes pathname down to getServerSideProps).

Here is the commit I'm using in my Next.js fork to add the pathname:
javiercr@d6de5bd

Let me know if there is anything else I can do to clarify. Thanks!

[Timer]

I'm not sure why you'd need pathname to return the name of the Next.js page? Your code is in that page—you know its name.

---

If this is what getInitialProps gives you:

pathname == "/products/[slug]"

Then it seems getInitialProps is broken and this is a separate bug that needs fixed. You shouldn't get the page name as-is without the product slug.

[javiercr]

Thank you for looking at this again.

I'm not sure why you'd need pathname to return the name of the Next.js page? Your code is in that page—you know its name.

I understand this may need a little bit more of background. What we're trying to achieve here is a workaround for the lack of support for translation route segments that are not dynamic (which was excluded from the I18n RFC.

To achieve this we're leveraging the rewrites feature, to have multiple (translated) routes pointing to the same page. But that's not enough, as we need to make sure that rewritten URLs only work in the language they're for (my point 5. in the original post here).

As I tried to explain in my original post, we're defining our routing manifest, that maps pathname with a URL for each locale:

{
  "/products/[slug]": {
    "page": "/products/:slug",
    "locales": {
      "es": "/productos/:slug",
      "en": "/items/:slug"
    }
  }
}

Then on the getServerSideProps for each page that has translated routes, we do something like this:

export const getServerSideProps: GetServerSideProps = async (context) => {
  if (!isValidRoute(context)) {
    context.res.statusCode = 404;
    context.res.end();
    return { props: { error: "Invalid URL" } };
  }

  // Pass data to the page via props
  return { props: {...context.params} };
};

The isValidRoute helper looks like this:

import { pathToRegexp } from "path-to-regexp";
import routes from "./routes.json";

export function isValidRoute(context: GetServerSidePropsContext) {
  const { pathname, req, locale } = context;

  // Remove query string from URL
  const cleanUrl = req.url.split("?")[0];

  // Create a regexp for the path, that may include named parameters (eg: /items/:slug)
  const regexp = pathToRegexp(routes[pathname]?.locales[locale]);

  // Test the path against the currentURL
  if (regexp.test(cleanUrl)) {
    return true;
  }

  return false;
}

(Note here the context includes the pathname, which is not included in the original Next.js implementation).

I hope this explains better why we need that pathname. There may be better workarounds to achieve this, and I understand there may be official support for translating non dynamic route segments in the future, but in the meantime if we want to get rid of our existing express custom server and be able to move our production env from GCP to Vercel.

Thank you!

[andresgutgon]

Hi @javiercr maybe has in rewrite keys can serve in your case:

https://nextjs.org/docs/api-reference/next.config.js/rewrites#header-cookie-and-query-matching

[tihonko999]

Hi, @Timer !

If resolvedUrl isn't sufficient, you'll have to rely on req.url

How to deal with client transitions?
I have a rewrite in next.config.js:

{source: "/articles", destination: "/news" }

If i navigate to http://localhost:3000/articles at first time, i see that req.url is '/articles'
But in client transition req.url is '/_next/data/development/news.json'
How can i get the real path during client transition?

[Pustinyak]

I haven't found a way to get the real pathname. If the url is "/en/something" then both resolvedUrl and req.url point to "/something". Exposing the real pathname will help a lot when it comes to custom logic based on the new i18n routing.

[apalumbo]

@EmilTruthful check your i18n configuration in nextJs , the path you are receiving is because nextJs is handling the locale detection and routing for you. If so you will also receive the current locale in the context, so you can easily recompose the information

[Pustinyak]

Hi @apalumbo, thanks for the reply. You can read my solution to the problem here - #19077

[shivamdhammi]

has anybody able to find solution to this problem ?

[krisu-pl]

We have a similar problem. When using rewrites.js then resolvedUrl contains incorrect URL based on the file structure where it's redirected, instead of actual browser URL. And we can't use req.url neither, because it's /_next/data/development/....json with client routing. Is there any solution to this?

[lucaslaricchia]

Maybe i'm missing the point here, but this may work?

getServersideProps({ params, req, resolvedUrl}) {
const domain = req.headers.host;
const pathName = 'https://' + domain + resolvedUrl;
}

[mk0y]

What if you're working on localhost and it's http not https?

[alex-statsig]

For extra context here, another compelling use case of pathname is for logging. We have a wrapper around all of our getServersideProps which does some common logic including logging the route / some performance numbers. Currently we have to manually pass in a unique name for each route. Instead, we could have something like "/blogs/[blog_id]/" (we don't want "/blogs/a" and "/blogs/b" to be separated, as they are the same route with different params). This works great in our getInitialProps / clientside logging, but for some reason isn't exposed here

[danielbeardsley]

We'd also make use of this. It's effectively the name of the controller and is useful for logging / stats tracking. For now we're just hard-coding a human name for each page.

[RinatRezyapov]

In my getServerSideProps I'm deciding whether a user have the right to access a page and having a reliable source of information without doing additional parsing would be great. Next.js has pathname on client side, why wouldn't it have pathname on server side?

req.url in my case not even close resembles a pathname.
My use case is:

const allowedRoutes = {
 "/dashboard/[envId]": ["owner", "member"]
}
ctx.resolvedUrl = "/dashboard/123"
allowedRoutes[ctx.resolvedUrl].includes(role)
"/dashboard/123" != "/dashboard/[envId]"

Right now I'm doing something like that:

let url = ctx.resolvedUrl.split('?')?.[0];
const queries = Object.entries(ctx.query);
url = queries.reduce((acc, [key, val]) => acc.replace(val, `[${key}]`), url)

Which is meh...

[srigi]

I wrote a small snippet with help of .reduce() to convert ctx.resovedUrl to page-route:

export const getServerSideProps: GetServerSideProps = async (ctx) => {
  let resolvedUrl = ctx.resolvedUrl;

  // if we have params in URL
  if (ctx.params != null) {
    // cut params values from resolvedUrl
    resolvedUrl = Object.keys(ctx.params).reduce<string>((memo, param) => {
      const value = ctx.params![param];
      if (typeof value === 'string') {
        const paramPositionInResolvedUrl = memo.indexOf(value);

        return `${memo.substring(0, paramPositionInResolvedUrl)}[${param}]`;
      }

      return memo;
    }, ctx.resolvedUrl);
  }

  const resourceUrl = new URL(`${process.env.WEBSITE_URL}${resolvedUrl}`);
  console.log(resourceUrl.pathname)

  return { props: {} };
}

If I have a request like /user/df60bd34-6251-43ea-a8a4-e8fd43a89f0a?some=query hitting my src/pages/user/[id], it will correctly log into console /user/[id]

[PeterPimentel]

I am using the approach suggested by @srigi , I just did a quick update to use replace instead of substring in case of the params don't came in the exactly orders as the url.

Ex:

getResolverUrl('/user/5/post/12', { postId:'12', userId: '5' })

const getResolverUrl = (url: string, params?: Record<string, string>): string => {
    let resolvedUrl = url;
    if (params && params !== null) {
        resolvedUrl = Object.keys(params).reduce((memo, param) => {
            const value = params[param];
            if (typeof value === 'string') {
                return memo.replace(value, `[${param}]`);
            }

            return memo;
        }, url);
    }
  
    const resourceUrl = new URL(`${process.env.WEBSITE_URL}${resolvedUrl}`);

    return resourceUrl.pathname;
};