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

[Feature]: Use the spec-compliant fetch in request #31518

Open
illright opened this issue Jul 2, 2024 · 2 comments
Open

[Feature]: Use the spec-compliant fetch in request #31518

illright opened this issue Jul 2, 2024 · 2 comments

Comments

@illright
Copy link
Contributor

illright commented Jul 2, 2024

🚀 Feature Request

In our application, we have a package that abstracts away API calls to the backend. It's a convenient way to setup up the test data. This package allows customizing the fetch function, and it expects a spec-compliant fetch implementation. However, the Playwright fetch differs quite a lot from the conventional fetch provided by browsers.

Currently, the differences are the following:

  • the first argument of Playwright's fetch is string | Request, and Request here is not the spec-compliant Request, but the Playwright-specific one. The first argument of browser fetch is string | Request | URL
  • the second argument differs in the headers field — the Playwright's fetch has no support for the Headers class and an array of entries
  • the return value, Promise<Response> is vastly different from spec-compliant response — a bunch of properties are methods, their types are not easily convertible between each other

All of the above makes writing a custom adapter complicated.

Example

This would allow me to create fixtures like the following:

export const test = base.extend({
  callApi: ({ request }, use) =>
    use(async (method, ...args) => {
      const originalFetch = Base.fetch;

      try {
        Base.fetch = request.fetch.bind(request);
        return await method(...args);
      } finally {
        Base.fetch = originalFetch;
      }
    }),
});

Motivation

It will make Playwright's APIs easier to learn because the knowledge will be transferable. It will also allow the freedom of integrating Playwright's request making functionality with anything that is fetch-compatible.

@mxschmitt
Copy link
Member

our application, we have a package that abstracts away API calls to the backend.

Would using Node.js fetch() work for you?

@illright
Copy link
Contributor Author

illright commented Jul 3, 2024

I don't think so, because I would like to reuse the auth cookies obtained by playwright when logging in. Basically, I would like to take actions as the current user

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

No branches or pull requests

2 participants