Able to fetch data through axios

[hkhattabii]

The Issue

When I test nextjs api, the body that I send is always undefined if I don't Stringify at test level and parse at api level.
It's working, but when I don't make test, the JSON.parse() stay there and I also have to check wether the request body is stringified or not.

From the test I have to stringify my body, otherwise it is undefined on the api

I want to send the request through a client such as postman or web browser I am getting this exception becuase it tries to parse a plain object instead of string.

If I want to use both at test level and client level I have to check if I can parse or not the body

The solution

Access to "axios" parameter in the test callback to send body as plain object and avoid to stringify data

[Xunnamius]

@hkhattabii Hmm, do you have a MRE or open-source repo where I can see some code demonstrating the issue? The request body your client code receives can be manipulated with responsePatcher, but I'm not very clear on what problem you're trying to solve or how Axios factors in

[galmatn]

I believe that the issue is pretty well explained. I end up here finding a solution for the same. I don't understand how the "responsePatcher" could solve this problem if the problem is in the request itself.

@hkhattabii (and I) we are trying to post a body without the necessity of stringifying it (Since it is the only way to post data using fetch).
The problem with this approach is that you need to include a mandatory JSON.parse in your code which in fact, is not needed at all for your application.

[Xunnamius]

I'm interested in helping you two figure this out, but your issue is not well-explained enough.

NTARH uses node-fetch as its fetch function, not Axios or Got or the infinity other fetch libraries each with their own idiosyncrasies and feature sets that likely differ from node-fetch. AFAIK, node-fetch does not support passing a non-buffer object as body. Here's an excerpt of the node-fetch documentation on how to send a POST request with JSON data:

import fetch from 'node-fetch';

const body = {a: 1};

const response = await fetch('https://httpbin.org/post', {
	method: 'post',
	body: JSON.stringify(body),
	headers: {'Content-Type': 'application/json'}
});
const data = await response.json();

console.log(data);

Achieving that, NTARH doesn't do anything special or fancy with your request body upon receiving it. Once you call fetch and the request and response objects are created by the HTTP server, the patcher functions are called, query string parsing happens, and the request and response (along with your handler) are passed directly to Next.js's apiResolve function (see these source lines). That's it.

responsePatcher can change the response object that is fed into apiResolve, hence "patching" the response object before Next.js receives it and data is returned to your client. If your goal is to change how the NextApiResponse/ServerResponse object deals with your JSON data, that would be the place to do it.

If you're needing to call JSON.parse in your Next.js handler or on the HTTP response returned from Next.js's apiResolve function, perhaps because you're not passing the correct content-type header, that's not something NTARH can help you with.

Further, adding an "axios" parameter to achieve (I'm still not exactly sure how Axios factors into this or what the goal is here... do you want to change Next.js's apiResolve function?) specifically for Axios means, to be fair, I'd also have to add a Got parameter, an unfetch parameter, a WHATWG-fetch parameter, a superagent parameter, a needle parameter, a request-lib parameter, a httpsnippet parameter, a requestify parameter, a simple-get parameter, and other parameters for every fetch library in existence, no? This project is already tracking unstable Next.js internals, I'd rather not make things even more difficult.

But perhaps I'm thinking about your issue the wrong way. So, in the interest of understanding your issue, can either of you provide a simple minimal reproducible example (MRE) demonstrating the behavior you're experiencing? I'd love to play with some code.

I'll go first. Here's me using NTARH in one of my recent projects running without incident in production.

A unit test using NTARH to post some json data:

/* file: test/endpoint.test.ts */

describe('/ [POST]', () => {
    it('accepts a new meme schema; returns a meme', async () => {
      expect.hasAssertions();

      await testApiHandler({
        handler: api.memes,
        test: async ({ fetch }) => {
          await expect(
            fetch({
              method: 'POST',
              headers: { KEY, 'content-type': 'application/json' },
              body: JSON.stringify({})
            }).then(async (r) => [r.status, await r.json()])
          ).resolves.toStrictEqual([
            200,
            expect.objectContaining({ meme: expect.anything() })
          ]);
        }
      });
    });

And the corresponding Next.js API handler that handles the request and sends a response:

/* file: src/pages/api/memes.ts */

export default async function (req: NextApiRequest, res: NextApiResponse) {
  await wrapHandler( // <== this handles stuff like ensuring some endpoint versions are disabled
    async ({ req, res }) => {
      const key = req.headers.key?.toString() || '';

      // ...

      if (req.method == 'GET') {
        // ...
      } // * POST
      else
        sendHttpOk(res, { meme: await createMeme({ creatorKey: key, data: req.body }) });
    },
    { req, res, methods: ['GET', 'POST'], apiVersion: 1 }
  );
}

Where createMeme is defined as:

export async function createMeme({
  creatorKey,
  data
}: {
  creatorKey: string;
  data: Partial<NewMeme>;
}): Promise<PublicMeme> {
  // Does stuff with the JSON data contained in `data`
  // Note that we NEVER HAD TO CALL JSON.PARSE at any point
}

In fact, I grepped for "JSON.parse" across the project's entire codebase, including the integration tests (that also use NTARH), and found only two unrelated results.

And here's me using postman to test out the above API, again without incident and again without using JSON.parse anywhere:

So, it works at the test level and the client level without any of the issues you describe, which is why I'll need a little more to go on 🙂