🚀 Feature Request

When this feature gets implemented:
Playwright would provide a generic callback mock that can be passed into components which then later can be asserted using appropriate assertions from expect

Example

Status Quo:
From the docs

// from the
test('event should work', async ({ mount }) => {
  let clicked = false;

  const component = await mount(
    <Button title="Submit" onClick={() => { clicked = true }}></Button>
  );

  await component.click();

  expect(clicked).toBeTruthy();
});

What it could look like after implementation:

test('event should work', async ({ mount }) => {
  const mock = fn() // fn is provided by playwright

  const component = await mount(
    <Button title="Submit" onClick={mock}></Button>
  );

  await component.click();

  await expect(mock).toHaveBeenCalledTimes(1);
});

Other assertions could be:
.toHaveBeenCalled
.toHaveBeenCalledWith

Motivation

The primary motivation is ease of use.
Testing single components also involves how they react to user interaction, and how they would pass information to their parents.
As in the example docs example firing a callback when a component is clicked.

Since stuff like this is common to test i would see it beneficial to have a common way to do it.

When a user implements these themself mistakes can happen leading to flaky tests.
Taking the docs example as a reference, since the assertion is not wrapped into expect.poll the test might be flaky because as far as i know the React event is not guaranteed fired before the assertion.
A native feature could lower the risk of this happen.

I think having these assertions would make migrating from other component test frameworks a lot easier since a lot of frameworks offer these kinds of assertions and having a native alternative could lower the entry barrier to migrate.

Overall i think it would greatly improve usability and improve ease of use writing component tests with playwright-ct.

If this feature would get approved i would also like looking into implementing it.
If that's ok.

It is likely to grow our expect API surface twice or so. If you can use third party mocking library (sinon?), that would work. Otherwise we would need to consider a better interop with jest.fn or to repeat it in our api, which is suboptimal.