frontend-ui-engineering

Frontend UI Engineering

Production-quality UI is accessible, follows the project's actual design system, and handles every state (loading, empty, error) — not just the happy path. Examples below use Vue 3 Composition API syntax; the underlying component-architecture and accessibility principles apply to any framework.

When to use

Building new UI components or pages, modifying existing user-facing interfaces, implementing responsive layouts, adding interactivity, or fixing visual/UX issues.

Component architecture

Colocate everything related to one component:

components/TaskList/
  TaskList.vue
  TaskList.spec.ts
  useTaskList.ts     # composable, if state logic is non-trivial
  types.ts

Composition over configuration. A component that accepts children/slots adapts to unforeseen content; a component with a growing prop surface for every variant becomes unmaintainable:

<!-- Good: composable -->
<Card>
  <CardHeader><CardTitle>Tasks</CardTitle></CardHeader>
  <CardBody><TaskList :tasks="tasks" /></CardBody>
</Card>

<!-- Avoid: over-configured -->
<Card
  title="Tasks"
  header-variant="large"
  body-padding="md"
  :content="tasksContent"
/>

Keep components single-purpose:

<script setup lang="ts">
defineProps<{ task: Task }>();
const emit = defineEmits<{ toggle: [id: string]; delete: [id: string] }>();
</script>

<template>
  <li class="flex items-center gap-3 p-3">
    <input type="checkbox" :checked="task.done" @change="emit('toggle', task.id)" />
    <span :class="task.done ? 'line-through text-muted' : ''">{{ task.title }}</span>
    <button aria-label="Delete task" @click="emit('delete', task.id)"><TrashIcon /></button>
  </li>
</template>

Separate data fetching from presentation — a container component owns loading/error/empty branching; the presentation component only renders data it's already been handed. This keeps the presentation half trivially testable and reusable in a different data-fetching context (e.g. Storybook, a different route).