How I review complex front-end pull requests

When I review a complex front-end pull request, I try to resist starting with taste. Naming, formatting, and small refactors matter, but they are rarely the first risk. The first risk is whether the behavior is actually understandable.

I start by tracing the route or feature boundary. What state enters the page? Who owns it? What happens when data is empty, stale, loading, forbidden, partially available, or failed? If those questions require archaeology, the code is asking too much from the next person.

Then I look for ownership leaks. Parents passing implementation switches into children. Components holding unrelated state because it was convenient. Services that know product decisions they should not know. Templates that hide business rules in conditions nobody will remember to update.

I also look at the user's path, not just the code path. Can the user recover? Can they tell whether an action worked? Are disabled states explained? Does the UI preserve context after an update? These questions catch more real regressions than a purely structural review.

Good review comments should raise the level of the codebase, not prove the reviewer is clever. I try to write comments that describe the risk: this duplicates the source of truth, this makes the child depend on parent knowledge, this misses the retry state, this can drift from the design system.

The best PRs make review boring in the right way. The behavior is named, the states are visible, the components have obvious jobs, and the tradeoffs are called out before someone has to ask.

That is the culture I want around front-end work: direct about risk, respectful of delivery pressure, and unwilling to let unclear UI contracts become tomorrow's maintenance bill.