My front-end quality bar before a PR

Before I open a front-end PR, I want the boring things handled. Not because boring checks are glamorous, but because they are where most UI regressions hide.

The screen can look right in the happy path and still fail the product. Long text can break the layout. Keyboard focus can disappear. A loading state can shift the page. An error can erase user input. A mobile viewport can turn a tidy component into a puzzle.

My front-end quality bar is a way to catch those problems before review.

SurfaceDoes it look right?

Responsive layout, spacing, hierarchy, long content, visual states.

BehaviorDoes it act right?

Keyboard, focus, loading, error, empty, permission, recovery.

DiffDoes it belong?

Small scope, clear data flow, no unrelated refactor, no invented pattern.

Start with the smallest honest diff

The easiest PR to review is the one that changes only what it needs to change.

Before I open a PR, I check for accidental scope:

• Did I reformat unrelated files?
• Did I rename things because I prefer a different style?
• Did I add an abstraction before the duplication proved itself?
• Did I change shared behavior for one local screen?
• Did I include experimental code that is not used?

Small diffs are not just polite. They reduce risk. They make review more precise. They also make it easier to revert if the product decision changes.

Test with ugly content

Pretty mock data lies.

I like to test UI with:

• long customer names
• short and long button labels
• empty lists
• one item
• many items
• missing avatars
• 0 values
• large values
• translated-looking text
• dates with long month names
• dense status combinations

If a card only works with "Acme" and "$58k," it is not done. The product will eventually get a customer name that wraps, a translated label that doubles in length, or a value that needs more space.

The layout should bend without feeling broken.

Check the state set

Every UI change has states, even when the task did not mention them.

For a data surface, I want:

• loading
• ready
• empty
• filtered empty
• error
• partial data
• stale data if relevant

For an action, I want:

• default
• hover
• focus
• active
• pending
• success
• failure
• disabled or unavailable

Not every state needs a custom design. But every state needs an answer. If there is no answer, the browser will create one on the user's behalf.

Use the keyboard

I try to use the feature without the mouse before calling it done.

Can I tab to the control? Is focus visible? Does Enter submit the right thing? Does Escape close the modal? Does focus return to the trigger? Can I reach the error message? Does a menu trap me? Does a drawer preserve page scroll?

Keyboard checks are not a separate accessibility ritual. They reveal whether the interface is actually built as an interface.

Watch layout during loading

Loading states should preserve trust. A page that jumps while data loads feels fragile even when the data is correct.

I look for:

• stable card dimensions
• skeletons that match final shape
• buttons that do not resize when pending
• tables that keep columns predictable
• spinners that do not replace important context
• disabled actions that explain why

Sometimes a plain "Loading..." is fine. Sometimes a skeleton is better. The point is not the pattern. The point is that loading should not make the product feel like it is falling apart.

Keep errors local

Global error banners are easy to add and easy to overuse.

If one row action fails, show the failure near that row. If a field is invalid, show the message near the field. If a save fails, preserve the draft. If a list cannot load, show retry in the list area.

The user should not have to connect a generic error to the action they just took.

Inspect the responsive behavior

Responsive QA does not mean dragging the viewport until something looks bad. I use a few known sizes:

• narrow phone
• large phone
• tablet-ish width
• laptop
• wide desktop

At each size, I check whether the primary action is reachable, text still fits, sticky elements do not cover content, and the layout does not create accidental horizontal scroll.

The mobile check matters even for internal tools. People still open links on phones. Support people still check dashboards on the move. Founders still review staging links from messages.

Verify data flow

Before opening a PR, I want to understand where the data comes from and who owns it.

I check:

• Is the API shape stable?
• Are null values handled?
• Is sorting done in the right layer?
• Are dates timezone-safe enough for this use?
• Does optimistic UI have rollback?
• Does cached data need invalidation?

Front-end work is often where weak data assumptions become visible. It is better to catch them before review.

The PR note

I like PR notes that make review easier:

• what changed
• what states were checked
• what viewport or browser was used
• what is intentionally out of scope
• any known tradeoff

This does not need to be long. A good note prevents reviewers from guessing what kind of review the change needs.

My final pass

Before I push, I ask:

• Does the happy path work?
• Does the unhappy path preserve user work?
• Does long content fit?
• Does keyboard use work?
• Does loading preserve layout?
• Does mobile hold?
• Is the diff smaller than my first attempt?
• Did I leave unrelated cleanup out?

That is the bar. It is not fancy. It is the basic discipline that makes UI changes feel safe.

Good front-end work is often invisible. The page does not jump. The error helps. The button keeps its shape. The keyboard path works. The reviewer understands the diff. Those details are not extra polish. They are the product behaving with care.