How to view UI changes before & after a pull request?

I've heard this called "snapshot testing"

I've used Chromatic before and really enjoyed it: https://www.chromatic.com/features/test

Jest also offers the core functionality if you want to roll your own tests: https://jestjs.io/docs/snapshot-testing

I upload a before and after picture or a video to the ticket, and then link it in the PR description, so design or product can comment before developers.

I think you're asking about automating the screenshot comparison, and there are some answers about that already. I wanted to chime in with a complementary comment.

We recently started using Vercel to host our front-end application, and out-of-the box, it automatically deploys every branch to it's own "Preview" environment. This has been game changing for me, inverting my review workflow. Before I look at the code, I typically test out the UX changes live.

There is also a service which can be integrated into your pipeline: https://diffy.website. You can take screenshot from your production or stage environment and compare them with your feature/PR builds.

A different tack: are you getting the frontend PRs because they want you to review UI changes?

As a backend developer there's a certain "thoroughness" you have drilled into you about making sure backend PRs are "rock solid" and everything is well reviewed (because sometimes PR is the only place you catch things that would cost considerable problems in Production). That's a great mindset to have! It's not necessarily a mindset you need to bring to frontend PR reviews.

For UI changes, those often get plenty of "review" in User Acceptance Testing. We want to think that UAT is a deep process that tests every aspect of the app, and sometimes we build complex QA scripts for UAT testers, but in most cases in my experience the things that UAT are most reliable for are primarily fairly shallow, and UI/visual bugs are the number one thing UAT tests find quickly and reliably. (You don't feel a lot of UAT pressure on the backend which is why sometimes you feel a need to get backend PRs as solid and comprehensive as possible. The opposite happens in frontend work: the PRs can be a bit "sloppier" because UAT often is a strong "canary" for bugs/mistakes/glitches/tweaks.)

As often a full stack developer my experience is that backend and frontend focused PRs have very different needs in the PR process. If there's a strong place to apply that "backend mindset" to frontend PRs it is in a lot of the same things that likely make you a good backend programmer: frontend JS has all the same memory and performance management tasks of any other garbage collected language you work with. For instance: are your frontend engineers considering the O-complexity of their algorithms and their memory storage? That may even be the reason they want someone more "backend minded" reviewing "frontend PRs". They may be too busy worrying about the UI/visual changes of their tasks and don't have as much bandwidth or need to pay as much attention to how the code is working at a performance level and that sort of "cross-pollination" between mindsets in PR benefits the project (users experience those performance/memory issues pretty directly, but it can be hard to focus in planning UI/frontend tasks).

Cypress can take screenshots too, maybe you can use the screenshot function and store the artifact in your CI job. This way you can include a before / after screenshot of your change in the PR

My org requires screenshots and/or gifs in the PR. Tooling is great, but not everything needs automation all the time when a little bit of manual work needs to be done anyway.