Request: capture timings too

[scottrippey]

Hi, I would like to suggest a feature, can this library capture the timings too?

The onRender callback contains a number of interesting metrics; mainly phase, baseDuration, and actualDuration. It would be great if this profiler wrapper could capture these values. Here's an example of what I would like:

const ExampleComponent = () => <div />;
const TestComponent = withProfiler(ExampleComponent);

it("should capture all renders", () => {
  const { rerender } = render(<TestComponent />);
  rerender(<TestComponent />);

  // `renders` is an array of the captured "phase" parameter
  expect(TestComponent.profiler.renders).toMatchInlineSnapshot(`
    Array [
      "mount",
      "update",
    ]
  `);

  // `timings` is an array of ALL the parameters: 
  console.log(TestComponent.profiler.timings);
  // Logs:
  // Array [
  //   {
  //     phase: "mount",
  //     actualDuration: 2.112893512389,
  //     baseDuration: 2.91723497584,
  //     startTime: 1147.7671834767779,
  //     commitTime: 1157.7768147817643,
  //   },
  //   { phase: "update", ... }
  // ]

  TestComponent.profiler.clear();
});

I have 2 use-cases:

1. Better assertions. In the example above, I'm not limited to just using .toHaveCommittedTimes(#). By exposing the number of renders via Wrapper.profiler.renders, I'm able to make any assertions I want, including snapshots or range testing.

2. Quick access to rendering times. The Wrapper.profiler.timings array would contain the detailed timings for each render. I don't intend to use these values to make assertions (because this kind of perf testing is too unstable), but I do think it could be useful for logging the timings for testing purposes. It would be great to know whether mount or update is taking the most time, and it would be a nice developer tool for attempting to improve performance.

What do you think? (Fwiw, I've got a forked copy that has these implemented, if you'd like to see it)

[bvaughn]

Truthfully, I had forgotten this package existed. Haven't used it in years.

If you'd like, I'd be happy to give you write access to the repo and publish access to NPM (though I'll need you to share your NPM username) and you can publish this yourself rather than in your fork?

[scottrippey]

Ha ha, been there, forgotten about plenty of my stuff :) I'd be happy to be a collaborator.
This package is still useful, because there really isn't much else in this "performance testing" space.
And I'd rather spend my time making improvements to this, rather than working on a fork that dilutes the domain. NPM username is scott-rippey

[bvaughn]

@scottrippey Awesome! I've added you to both GitHub and NPM projects. :)