Skip to content
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

Asserting request payload (waitForRequest) in v2 documentation #113

Open
karlosos opened this issue Apr 12, 2024 · 4 comments
Open

Asserting request payload (waitForRequest) in v2 documentation #113

karlosos opened this issue Apr 12, 2024 · 4 comments

Comments

@karlosos
Copy link

After upgrading to v2, the code copied from the documentation is not functioning properly.

function waitForRequest(method: string, url: string) {
  let requestId = ''

  return new Promise<MockedRequest>((resolve, reject) => {
    server.events.on('request:start', (req) => {
      const matchesMethod = req.method.toLowerCase() === method.toLowerCase()
      const matchesUrl = matchRequestUrl(req.url, url).matches

      if (matchesMethod && matchesUrl) {
        requestId = req.id
      }
    })

    server.events.on('request:match', (req) => {
      if (req.id === requestId) {
        resolve(req)
      }
    })

    server.events.on('request:unhandled', (req) => {
      if (req.id === requestId) {
        reject(
          new Error(`The ${req.method} ${req.url.href} request was unhandled.`),
        )
      }
    })
  })
}

Is it still possible to retrieve a request reference and write request assertions (i.e., determine if the correct request payload was sent) in v2? I am unable to find this information in the new documentation.

@karlosos karlosos changed the title Asserting request payload (waitForRequest) in v2 Asserting request payload (waitForRequest) in v2 documentation Apr 12, 2024
@karlosos
Copy link
Author

karlosos commented Apr 12, 2024

I found the solution here: https://github.com/zextras/carbonio-shell-ui/blob/devel/src/mocks/server.ts

import { LifeCycleEventsMap, matchRequestUrl } from 'msw';
import { setupServer } from 'msw/node';

import handlers from './handlers';

const server = setupServer(...handlers);
export default server;

export function waitForRequest(method: string, url: string): Promise<Request> {
	let requestId = '';

	return new Promise((resolve, reject) => {
		server.events.on('request:start', (info) => {
			const matchesMethod = info.request.method.toLowerCase() === method.toLowerCase();
			const { matches: matchesUrl } = matchRequestUrl(new URL(info.request.url), url);

			if (matchesMethod && matchesUrl) {
				requestId = info.requestId;
			}
		});

		server.events.on('request:match', (info) => {
			if (info.requestId === requestId) {
				resolve(info.request);
			}
		});

		server.events.on('request:unhandled', (info) => {
			if (info.requestId === requestId) {
				reject(new Error(`The ${info.request.method} ${info.request.url} request was unhandled.`));
			}
		});
	});
}

UPDATE: it seems that is not working the same as the implementation from v1. For a while, I'll stay on v1, as this function is really necessary for my workflow.

@kettanaito
Copy link
Member

Hi!
You are looking at v1 docs. The v2 docs for the life-cycle events are here: https://mswjs.io/docs/api/life-cycle-events/

@karlosos
Copy link
Author

You are looking at v1 docs. The v2 docs for the life-cycle events are here: mswjs.io/docs/api/life-cycle-events

I noticed that the section "Asserting requests payload" is present in the v1 documentation but has been removed from the v2 documentation.

This removal was likely intentional, as it's recommended to avoid request assertions. However, I've heavily utilized the waitForRequest function in my codebase.

The solution I proposed for porting waitForRequest to v2, outlined in this comment, isn't functioning correctly.

@kettanaito
Copy link
Member

This removal was likely intentional, as it's recommended to avoid request assertions.

While we still discourage request assertions, I think the removal of that example was accidental. It took a lot of time to (re)write the docs for v2 so some things got lost along the way.

I think we should re-add the example. I propose to add it to the Exceptions section of the "Avoid request assertions" best practice. Does that make sense to you?

it seems that is not working the same as the implementation from v1.

Can you please share more details about what exactly is not working?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants