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.
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.
After recording, explore the replay to identify the areas that have changed in the pull request.
- For UI changes, use the Viewer
- For code changes, use Search
- For API changes, use the Network Monitor
- To validate changes, use Print Statements
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.
Upload in progress...
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.
Every replay has a shareable URL that can be added directly to the pull request in the description or as a comment.
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 (opens in a new tab) so every PR is well-documented for quick review.
Check out Replay’s open source
/devtools repository (opens in a new tab) to see how the team uses replays to document pull requests.