You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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
🚀 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-compliantfetch
implementation. However, the Playwrightfetch
differs quite a lot from the conventionalfetch
provided by browsers.Currently, the differences are the following:
string | Request
, andRequest
here is not the spec-compliant Request, but the Playwright-specific one. The first argument of browser fetch isstring | Request | URL
headers
field — the Playwright's fetch has no support for theHeaders
class and an array of entriesPromise<Response>
is vastly different from spec-compliant response — a bunch of properties are methods, their types are not easily convertible between each otherAll of the above makes writing a custom adapter complicated.
Example
This would allow me to create fixtures like the following:
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.The text was updated successfully, but these errors were encountered: