TypeError: Failed to parse URL from /api/images

[tqmvt]

Link to the code that reproduces this issue

https://stackblitz.com/edit/stackblitz-starters-qyc8rc?file=README.md

To Reproduce

1. Add nextjs api in app router
2. call the api in client component using fetch('/api/hello')
3. Got error ( It works fine on localhost but when building, it throws error )

Current vs. Expected behavior

Current:
Throws error: TypeError: Failed to parse URL from /api/images

Expected:
Should build successfully

Provide environment information

Next: 14.2.3

Config:

/** @type {import('next').NextConfig} */
const nextConfig = {
  eslint: {
    dirs: ['src'],
  },

  reactStrictMode: true,
  swcMinify: true,

  // Uncoment to add domain whitelist
  // images: {
  //   domains: [
  //     'res.cloudinary.com',
  //   ],
  // },

  webpack(config) {
    // Grab the existing rule that handles SVG imports
    const fileLoaderRule = config.module.rules.find((rule) =>
      rule.test?.test?.('.svg')
    );

    config.module.rules.push(
      // Reapply the existing rule, but only for svg imports ending in ?url
      {
        ...fileLoaderRule,
        test: /\.svg$/i,
        resourceQuery: /url/, // *.svg?url
      },
      // Convert all other *.svg imports to React components
      {
        test: /\.svg$/i,
        issuer: { not: /\.(css|scss|sass)$/ },
        resourceQuery: { not: /url/ }, // exclude if *.svg?url
        loader: '@svgr/webpack',
        options: {
          dimensions: false,
          titleProp: true,
        },
      }
    );

    // Modify the file loader rule to ignore *.svg, since we have it handled now.
    fileLoaderRule.exclude = /\.svg$/i;

    return config;
  },
};

module.exports = nextConfig;

### Which area(s) are affected? (Select all that apply)

Not sure, create-next-app, Developer Experience

### Which stage(s) are affected? (Select all that apply)

next build (local), Vercel (Deployed)

### Additional context

_No response_

[icyJoseph]

Hi,

fetch in non-browser environments, necessarily requires an absolute URL to work.

You are setting yourself up for errors and problems, read more here: https://nextjs-faq.com/fetch-api-in-rsc

[tqmvt]

Hi,

fetch in non-browser environments, necessarily requires an absolute URL to work.

You are setting yourself up for errors and problems, read more here: https://nextjs-faq.com/fetch-api-in-rsc

So what will be the soluton?
I am calling the api on the client component. It's fine on the localhost. But in build, it throws error. I even use absolute url but the problem is:

• It fails on vercel build without absolute url
• Without build, how can I have the absolute url?

[icyJoseph]

Isn't there like a HydrationBoundary component in that package?

• https://tanstack.com/query/latest/docs/framework/react/guides/advanced-ssr#streaming-with-server-components

Get the data you need, directly from source, and pass it to the hydration boundary as shown, then consume it with the hooks the package provides.

I think you are fundamentally misunderstanding something here. As you point out, in the vanilla case, there cannot be anyone handling the api request during build time, because the server is being built at that time as well.

Locally, the fetch cache is tricking you, because it stores the development time result. Try removing .next and rebuilding locally, it'll fail too.

What's more, within a server side context, how can fetch know, relative to what to make the request. In the browser it can make some assumptions about the baseURL, from some document properties, but on the server, at the end of the day, it is just a Node.js script running.

Alternatively, you could disable the query on SSR? but that's like, not good... it has been some months since I used that package too, so I am a bit rusty, but reading the docs, it does sound like they accommodate this use case very well

[tqmvt]

Isn't there like a HydrationBoundary component in that package?

• https://tanstack.com/query/latest/docs/framework/react/guides/advanced-ssr#streaming-with-server-components

Get the data you need, directly from source, and pass it to the hydration boundary as shown, then consume it with the hooks the package provides.

I think you are fundamentally misunderstanding something here. As you point out, in the vanilla case, there cannot be anyone handling the api request during build time, because the server is being built at that time as well.

Locally, the fetch cache is tricking you, because it stores the development time result. Try removing .next and rebuilding locally, it'll fail too.

What's more, within a server side context, how can fetch know, relative to what to make the request. In the browser it can make some assumptions about the baseURL, from some document properties, but on the server, at the end of the day, it is just a Node.js script running.

Alternatively, you could disable the query on SSR? but that's like, not good... it has been some months since I used that package too, so I am a bit rusty, but reading the docs, it does sound like they accommodate this use case very well

Yeah, as I posted the example above: #66330 (comment) , it shows error on both environment. You can check the code that I shared on stackblitz

What I want to know is the solution for this problem. Is this issue related to react query? Thanks

[icyJoseph]

Isn't there like a HydrationBoundary component in that package?

• https://tanstack.com/query/latest/docs/framework/react/guides/advanced-ssr#streaming-with-server-components

Get the data you need, directly from source, and pass it to the hydration boundary as shown, then consume it with the hooks the package provides.

I think you are fundamentally misunderstanding something here. As you point out, in the vanilla case, there cannot be anyone handling the api request during build time, because the server is being built at that time as well.

Locally, the fetch cache is tricking you, because it stores the development time result. Try removing .next and rebuilding locally, it'll fail too.

What's more, within a server side context, how can fetch know, relative to what to make the request. In the browser it can make some assumptions about the baseURL, from some document properties, but on the server, at the end of the day, it is just a Node.js script running.

Alternatively, you could disable the query on SSR? but that's like, not good... it has been some months since I used that package too, so I am a bit rusty, but reading the docs, it does sound like they accommodate this use case very well

Yeah, as I posted the example above: #66330 (comment) , it shows error on both environment. You can check the code that I shared on stackblitz

What I want to know is the solution for this problem. Is this issue related to react query? Thanks

The solution is on the docs for that package

[tqmvt]

Isn't there like a HydrationBoundary component in that package?

• https://tanstack.com/query/latest/docs/framework/react/guides/advanced-ssr#streaming-with-server-components

Get the data you need, directly from source, and pass it to the hydration boundary as shown, then consume it with the hooks the package provides.
I think you are fundamentally misunderstanding something here. As you point out, in the vanilla case, there cannot be anyone handling the api request during build time, because the server is being built at that time as well.
Locally, the fetch cache is tricking you, because it stores the development time result. Try removing .next and rebuilding locally, it'll fail too.
What's more, within a server side context, how can fetch know, relative to what to make the request. In the browser it can make some assumptions about the baseURL, from some document properties, but on the server, at the end of the day, it is just a Node.js script running.
Alternatively, you could disable the query on SSR? but that's like, not good... it has been some months since I used that package too, so I am a bit rusty, but reading the docs, it does sound like they accommodate this use case very well

Yeah, as I posted the example above: #66330 (comment) , it shows error on both environment. You can check the code that I shared on stackblitz
What I want to know is the solution for this problem. Is this issue related to react query? Thanks

The solution is on the docs for that package

Sounds good.
What is the solution if we don't use react-query and just fetch data in useEffect or anywhere in client side?

[icyJoseph]

Isn't there like a HydrationBoundary component in that package?

• https://tanstack.com/query/latest/docs/framework/react/guides/advanced-ssr#streaming-with-server-components

Get the data you need, directly from source, and pass it to the hydration boundary as shown, then consume it with the hooks the package provides.
I think you are fundamentally misunderstanding something here. As you point out, in the vanilla case, there cannot be anyone handling the api request during build time, because the server is being built at that time as well.
Locally, the fetch cache is tricking you, because it stores the development time result. Try removing .next and rebuilding locally, it'll fail too.
What's more, within a server side context, how can fetch know, relative to what to make the request. In the browser it can make some assumptions about the baseURL, from some document properties, but on the server, at the end of the day, it is just a Node.js script running.
Alternatively, you could disable the query on SSR? but that's like, not good... it has been some months since I used that package too, so I am a bit rusty, but reading the docs, it does sound like they accommodate this use case very well

Yeah, as I posted the example above: #66330 (comment) , it shows error on both environment. You can check the code that I shared on stackblitz
What I want to know is the solution for this problem. Is this issue related to react query? Thanks

The solution is on the docs for that package

Sounds good.
What is the solution if we don't use react-query and just fetch data in useEffect or anywhere in client side?

Then this won't be a problem. The callback of useEffect is not run during SSR, only on the client.

[leerob]

Closing this as guidance has been provided above to use the absolute URL versus the relative URL when making a fetch from client components.

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.