frontend-ui-engineering

Use native interactive elements like <button> instead of <div onClick>, since they are focusable by default. If a custom element is unavoidable, add role="button", tabIndex={0}, and handle Enter and Space key events. Always test by tabbing through the page.

Choose the simplest option that fits: useState for local UI state, lifted state for 2-3 siblings, Context for read-heavy values like theme or auth, URL search params for shareable filters, React Query or SWR for server data, and Zustand or Redux for complex app-wide state.

Use the project's actual color palette instead of purple gradients, apply consistent border-radius and spacing from the design system, write realistic content instead of lorem ipsum, and build purpose-driven layouts rather than uniform stock card grids.

Test at 320px, 768px, 1024px, and 1440px. Design mobile-first, then expand layouts at larger breakpoints, for example moving from a single-column grid on mobile to two or three columns on larger screens.

Skeleton loaders preserve the page layout during loading, reducing layout shift and setting content expectations. Mark them with aria-busy="true" and an aria-label so screen reader users know content is loading.

Split components that exceed roughly 200 lines, handle multiple responsibilities, or require prop drilling deeper than three levels. Separate data-fetching container components from presentational components to keep each focused on one job.