Documenting Pull Requests

Using Replay to document changes with pull requests makes it easier to review and accepts PRs faster. Record the updated application flow and use comments to highlight changed to the UI, application behavior, and even lines of code and network requests.

Record

Start by recording the area(s) of your application impacted by the pull request. Depending on the scope of your PR, this may involve capturing a single component render or a more complex user flow.
👉
Replay captures all code execution happening in the browser, not just the UI. This makes it a powerful tool for understanding changes that don’t just happen on the screen.
Check out the Recording a Replay guide for details.

Inspect

After recording, explore the replay to identify the areas that have changed in the pull request.
  • For UI changes, use the Viewer

Comment

Comments in Replay are linked to a point in time and one of the following:
Use comments to identify visual changes in the UI, diffs in lines of code, network requests and response bodies, or to add context for decision-making on why a change was made.
The pull request reviewer can click on any comment and be taken directly to the referenced point in time and UI location, line of code, or network request. No need to write file names or reproduction steps.

Share

Every replay has a shareable URL that can be added directly to the pull request in the description or as a comment.
Image without caption
We recommend setting up a team to easily manage access to replays so anyone reviewing your PR will already have access.
💡
As a best practice, require a replay as part of your pull request template so every PR is well-documented for quick review.

Examples

Check out Replay’s open source /devtools repository to see how the team uses replays to document pull requests.