Forem: Graeme George

Next Stop, Nuxt: A React Engineer’s Journey into Vue

Graeme George — Thu, 28 Aug 2025 17:17:04 +0000

Welcome to a personal journey as I move from years of React and Next.js into the world of Vue 3 and Nuxt. It’s not meant to be a polished “final guide,” but rather a living, evolving document — part learning journal, part reference, and part cheat-sheet.

The focus is on mapping familiar React and Next.js patterns to their Vue and Nuxt counterparts, with plenty of code snippets and “mini-labs” along the way.

The tone here is intentionally hands-on and pragmatic. It’s written for experienced engineers who don’t need the basics explained, but want a direct path to becoming productive in Vue while still acknowledging that this is a journey, and the document will grow and change as we learn more.

If you're a seasoned Vue engineer, please do feel free to leave a comment and tell me where I'm going wrong or share some great tips for others to consider and discuss. ✨

How to Use This Document

👀 Jump in wherever you like. Each section compares a React/Next.js pattern to its Vue/Nuxt equivalent. If you already know slots, skip ahead to provide/inject or routing.
🧪 Treat the code-labs as exercises. They’re short, focused challenges designed to reinforce the concept. Copy, paste, break things, and make them your own.
🤷🏻 Don’t expect it to be finished. This is a living document. I’ll update, refine, and expand as I encounter new patterns and idioms in Vue/Nuxt.
🧑🏻‍🎓 Use it as a bridge. The goal is not to re-learn frontend from scratch, but to lean on your React knowledge while translating concepts into Vue’s mental model.
🐿️ Stay curious. When in doubt, follow the links to the official React, Vue, and Nuxt docs — this doc is a companion, not a replacement.

👷🏻 Setup (fast)

Scaffold Vue: Vite + SFC + TS ready.

npm create vue@latest

Scaffold Nuxt: → pnpm i && pnpm dev

npx nuxi@latest init my-app

Data: useAsyncData, useFetch, pages/ routing

🧠 Mental model (reframe)

Reactivity is granular:
derive with computed, side-effects with watch/watchEffect / (API).
SFCs with <script setup> are idiomatic; macros provide TS-friendly DX:
<script setup>, SFC spec.
Slots are Vue's "children" (scoped slot props):
Slots / 3.x unification.
Context → provide/inject (typed with InjectionKey):
Provide/Inject, API + InjectionKey<T>.
Portals/Keep state:
<Teleport>, <KeepAlive>.
Component v-model (two-way):
v-model & defineModel (3.4), Announcing 3.4.
Suspense exists but is experimental; in SSR prefer Nuxt's data composables:
<Suspense>, Nuxt data fetching.

Pattern translations + mini code-labs

Each section: React → Vue (+ Nuxt twist). Do the steps; verify visually.

1) Children/compound components → Slots & named slots

React

<Card>
  <Card.Header />
  <Card.Body />
  <Card.Footer />
</Card>

Vue (SFC)

<!-- components/Card.vue -->
<template>
  <div class="card">
    <header><slot name="header" /></header>
    <section><slot /></section>
    <footer><slot name="footer" /></footer>
  </div>
</template>

<!-- usage -->
<Card>
  <template #header>Title</template>
  Content
  <template #footer>Actions</template>
</Card>

Code-lab

Build Card.vue with named slots.
Add slot props: pass sectionId from parent -> #default="{ sectionId }".
Stretch: create <Card.Header/> etc. as wrappers that render named slots.

Refs: Slots

🤔 But wait!

I'm not sure about this pattern. React reads much closer to native html markup <Card.Header />, while it clearly belongs to the parent <Card /> it remains it's own unit of functionality.

What if we went further to wrap the inner template components in named slots like <Card.Header /> etc so it can read in the same way in Vue. Maybe it wouldn't have any actual functional meaning but could replicate the great readability of React.

But hang on, we need to think less "react" and more "vue" paradigms. Perhaps this isn't highlighting a drawback of Vue but rather the limitations of React?

By writing code as <template #header> we semantically mark it not only a native template but also as a header slot, not just for a Card but anything! The code is therefore not only reusable but transferrable too 🤯

Does this mean we have more control and say over where we want to separate our concerns? Do we in fact get more semantic meaning this way...?

2) Context → provide/inject

React

const Theme = createContext<'light'|'dark'>('light')
<Theme.Provider value="dark"><App/></Theme.Provider>

Vue

// App.vue
<script setup lang="ts">
import { provide } from 'vue'
const ThemeKey = Symbol() as InjectionKey<'light'|'dark'>
provide(ThemeKey, 'dark')
</script>

// Leaf.vue
<script setup lang="ts">
import { inject } from 'vue'
const theme = inject(ThemeKey, 'light')
</script>

Code-lab

Provide a reactive ref('light') and a toggle function.
Inject in deep child and verify updates.
TS: use InjectionKey<T> for type-safe provide/inject.

Refs: Provide/Inject, API w/ InjectionKey

3) Hooks → Composables

React

function useMouse(){ /* setState/effect */ }

Vue

// composables/useMouse.ts
import { ref, onMounted, onUnmounted } from 'vue'
export function useMouse(){
  const x = ref(0), y = ref(0)
  const move = (e: MouseEvent)=>{ x.value=e.pageX; y.value=e.pageY }
  onMounted(()=> window.addEventListener('mousemove', move))
  onUnmounted(()=> window.removeEventListener('mousemove', move))
  return { x, y }
}

Code-lab

Create composables/useMouse.ts and display { x }/{ y } in a component.
Stretch: add throttling (requestAnimationFrame) and SSR-guard window access.

Refs: Community: VueUse

4) `useMemo` / `useCallback` → computed

React

const total = useMemo(()=> items.reduce(...), [items])

Vue

import { computed } from 'vue'
const total = computed(()=> items.value.reduce(...))

Code-lab

Convert a derived selector to computed.
Add a heavy calc; confirm it recomputes only when deps change (log).

Refs: Computed

5) `useEffect` side-effects → onMounted / watch / watchEffect

React

useEffect(()=>{ const id=setInterval(tick,1000); return ()=>clearInterval(id) }, [])

Vue

import { onMounted, onBeforeUnmount } from 'vue'
onMounted(()=>{ const id=setInterval(tick,1000); onBeforeUnmount(()=>clearInterval(id)) })

Code-lab

Replace a useEffect data sync with watch(source, cb).
Use watchEffect for auto-tracked dependencies; compare to computed.

Refs: Watchers, Reactivity API

6) Controlled inputs → `v-model` / `defineModel`

React

<input value={name} onChange={e=>setName(e.target.value)} />

Vue

<input v-model="name" />

Child two-way (3.4)

<!-- Child.vue -->
<script setup lang="ts">
const model = defineModel<string>()
</script>
<template><input v-model="model" /></template>

Code-lab

Build a reusable <TextField v-model="name" /> with validation.
Add multiple models: defineModel('start'), defineModel('end').
Try .trim/.number modifiers.

Refs: Component v-model + defineModel, Vue 3.4

7) Portals → Teleport

React

return createPortal(<Modal/>, document.body)

Vue

<Teleport to="body">
  <Modal />
</Teleport>

Code-lab

Render a modal/tooltip via <Teleport to=\"#modals\"/> (dedicated node).
SSR note: verify target exists client-side.

Refs: <Teleport>

8) Error boundaries → `onErrorCaptured` / Nuxt error pages

React: componentDidCatch/error boundaries.

Vue:

import { onErrorCaptured } from 'vue'
onErrorCaptured((err, instance, info)=>{ /* log */ return false })

Nuxt

Global: Error handling, error.vue page.

Code-lab

Throw in a child; handle with onErrorCaptured and display fallback UI.
Nuxt: create error.vue and simulate an API failure.

Refs: Vue error handling API, Nuxt errors

9) Suspense & async UI

React: Suspense/RSC orchestrate async and streaming.
Vue: <Suspense> experimental; prefer Nuxt data APIs for SSR.

Nuxt data

<script setup lang="ts">
const { data, pending, error } = await useAsyncData('posts', () => $fetch('/api/posts'))
</script>
<template>
  <PostList v-if="data" :items="data" />
  <Skeleton v-else-if="pending" />
  <ErrorBox v-else :error="error" />
</template>

Code-lab

Implement the above; confirm no double fetch on hydrate.
Compare useFetch vs useAsyncData for GET/POST. (Docs: Data fetching)

10) Routing (React Router/Next) → Vue Router/Nuxt

Vue Router: nested routes, guards, programmatic nav. Docs: Guide, Guards, Composition API

Vue Router example

// router.ts
import { createRouter, createWebHistory } from 'vue-router'
export const router = createRouter({
  history: createWebHistory(),
  routes: [
    { path: '/', component: () => import('./pages/Home.vue') },
    { path: '/admin', component: () => import('./pages/Admin.vue'), meta:{auth:true} }
  ]
})

// main.ts
import { createApp } from 'vue'
import App from './App.vue'
createApp(App).use(router).mount('#app')

Guard

router.beforeEach((to, _from, next)=>{
  if (to.meta.auth && !isAuthed()) return next('/login')
  next()
})

Nuxt

File-based routes via pages/ (docs)
Access router/route via useRouter / useRoute

Code-lab

Port an authenticated section with a global guard.
Nuxt: create pages/admin.vue; add navigation middleware; test redirects.

Cheat Sheet

React → Vue Cheat-Sheet

React / Next.js	Vue 3 / Nuxt 3
Children / compound components	Slots & named slots
Context (createContext / useContext)	provide / inject
Hooks (`useX` functions)	Composables (`useX`)
useMemo / useCallback / useCallback	computed
useEffect	onMounted / onUnmounted, watch / watchEffect
Controlled inputs	v-model / defineModel (3.4+)
Portals (createPortal)	Teleport
Error Boundaries	onErrorCaptured, Nuxt error handling
Suspense & React Server Components	<Suspense> (experimental), Nuxt useAsyncData/useFetch
Next.js App Router	Nuxt pages/ routing, server/api (Nitro)

Bonus: ecosystem mappings

State: Redux/Zustand → Pinia (docs, Vuex note).
Transitions: <Transition> / <TransitionGroup> built-in.
Preserve component state: <KeepAlive> (docs).
Client-only/islands: Nuxt <ClientOnly> + <NuxtIsland>.

Vue-native best practices (for React folks)

Prefer <script setup> + macros (defineProps/Emits/Model, withDefaults) for clean TS.
Use computed for derivations, watch/watchEffect for side-effects.
Don't destructure props/reactive objects unless via toRefs/toRef (keep reactivity).
Reach for composables for shared logic; study patterns in VueUse.
Be SSR-aware (no direct window/document on server); if needed, gate with process.client in Nuxt.
For modals/menus, prefer Teleport to dedicated container elements.
Performance: start with defaults-fine-grained tracking does heavy lifting. Only micro-opt once measured.

Primary docs: Computed, Watchers, <script setup>, Provide/Inject, Teleport

Nuxt for Next engineers (quick map)

Data: useAsyncData / useFetch (SSR-first; payload de-dupes client refetch). Docs: useAsyncData, useFetch
Server routes: server/api/*.ts (Nitro).
Routing: pages/ filesystem; nested layouts & middleware.
Islands: <NuxtIsland>; client-only: <ClientOnly>
Errors: Error handling, error.vue

4-week self-study plan

W1: Rebuild a small React app in Vue SFCs; slots + composables + Pinia.
W2: Router 4 (guards, nested layouts); transitions; Teleport + accessibility.
W3: Migrate to Nuxt: file routing, data fetching, API routes, error pages.
W4: Production polish-payload caching, <KeepAlive>, perf checks, CI build.

Appendix: official docs index

Vue core: Computed · Watchers · <script setup> · SFC · Provide/Inject · Teleport · KeepAlive · Suspense (exp.)
Router: Guide · Guards · Composition API
Pinia: Docs
Nuxt: Data fetching · pages/ · Errors · ClientOnly · NuxtIsland

Rethinking Responsibility: Empowering Engineers

Graeme George — Thu, 28 Aug 2025 15:43:32 +0000

Talking about the responsibility of programmers is tricky. It’s easy to slip into judgment or create a defensive atmosphere. Yet when handled thoughtfully, it can unlock empowerment-not guilt. Here’s how.

The Challenges Engineers Face

Feeling judged too often
In blame-heavy environments, engineers hide mistakes and avoid innovation-because speaking up can feel risky. Blame culture dampens psychological safety and hampers creativity (study here).
Culture doesn’t reward performance
Productivity obsessed organisations (tickets closed, hours logged, features shipped) rarely acknowledge creativity, mentorship, or architectural thinking leaving engineers uninspired.
The freedom to hide
When recognition is scarce, disappearing into routine feels safer than standing out, especially for those cautious about judgment.
The 10/90 imbalance
A minority trying to carry the workload can lead to burnout and disengagement, leaving the majority untapped.

Reframing Responsibility

Responsibility isn't about fault, it's about ownership, growth, and contribution without fear.

Eradicate blame culture Replace "who failed?" with "what failed, and how can we fix it?" This reflects the idea of a Just Culture, a shift from finger-pointing to systemic learning.
Spot and cultivate strengths
People thrive when their unique skills are valued, not just measured by output.
Celebrate visibility, not heroics
Reward incremental collaboration, knowledge-sharing and mentoring, not just flashy releases.
Encourage creativity and safe risk-taking
When mistakes become learning opportunities, innovation emerges.

Building a Culture That Empowers

Shift from output to outcomes
Elegance and stability should be recognised as much as new features.
Reward curiosity
Allocate time for exploration, hack days, brown-bag sessions, so curiosity becomes part of the culture.
Promote psychological safety
Google's Project Aristotle found psychological safety to be the top predictor of team effectiveness. Teams where members feel safe admitting mistakes, asking questions, and offering ideas consistently outperform others (LeaderFactor summary, Psychsafety overview).
Offer autonomy and clarity

Autonomy boosts psychological safety which in turn improves performance and reflexivity (research here).
Recognise the unseen work

Celebrating documentation, mentorship, and small fixes is crucial for morale.

Leadership: Enablers, Not Judges

Managers and tech leads must recognise that responsibility lies in cultivating an environment where developers can take pride and ownership over their work.

Leaders must inspire and be a reminder as to why their work matters.
They should be visible in celebrating wins - not just failures. This prevents the all too common feeling that "they're there for your failures, never your successes."

Closing Reflection

Engineering culture is too often shaped by fear of judgment, irrelevance, or mistakes. But responsibility, when reframed, becomes empowering. It frees developers to take risks, grow, and collaborate. Leadership plays a vital role too-not by policing, but by enabling and celebrating.

This isn't the final word, it's a starting point. Let's experiment, wonder, and build environments where engineers feel safe to bring their pride and potential-and leaders shoulder responsibility for making that possible.

Composability in Component Architecture: Lessons from React, Radix UI, and Beyond

Graeme George — Thu, 28 Aug 2025 13:56:36 +0000

Component-driven development has matured dramatically in the last decade. As frameworks evolve, so too do the paradigms and principles that shape how we build UI systems. One concept that has stood the test of time—arguably even strengthened—is composability.

Radix UI for example, embodies this philosophy beautifully:

import { Accordion } from "radix-ui";

export default () => (
  <Accordion.Root>
    <Accordion.Item>
      <Accordion.Header>
        <Accordion.Trigger />
      </Accordion.Header>

      <Accordion.Content />
    </Accordion.Item>
  </Accordion.Root>
);

A common pattern I like to use are primitive parts to make up a card.

<Card>
  <CardHeader />
  <CardBody />
  <CardFooter />
</Card>

Rather than bloating a single <Card /> component with endless props (showHeader, footerVariant, isCompact), Radix opts for composability. Each subcomponent does one thing well, and you stitch them together to achieve flexibility.

This reflects principles drawn from functional programming and single responsibility, while also challenging outdated dogma like DRY (Don't Repeat Yourself).

Why "God Components" Fail

Many React developers fall into the trap of the "God Component":

Takes a huge object of props.
Bloated with if/else conditionals.
Hard to test, hard to extend, brittle to refactors.

Consider this anti-pattern:

<Card
  showHeader
  footerVariant="compact"
  theme="dark"
  showBorder={false}
  isLoading
>
  Content goes here
</Card>

This single component is burdened with far too much knowledge. Even worse, when props are passed as new object references ({}), React often sees them as “different” on each render, causing unnecessary re-renders. Objects-as-props are another subtle performance trap.

By contrast, composability avoids these pitfalls:

<Card>
  <CardHeader>Profile</CardHeader>
  <CardBody>Some content</CardBody>
  <CardFooter compact>Footer text</CardFooter>
</Card>

Each part is responsible for itself.
Props stay shallow and predictable.
Testing is trivial: test <CardHeader /> in isolation.

Composability Over DRY

"Don’t Repeat Yourself" (DRY) once dominated software engineering. In UI, however, repetition can be healthy. Consistency of patterns matters more than absolute deduplication.

For example, repeating the structure of composable layouts—like headers, bodies, and footers—creates familiarity. This makes it easier for other developers to navigate your codebase and for design systems to scale. Over-abstraction in the name of DRY often introduces more indirection and fragility than it removes.

Inspirations from Functional Programming

Composability mirrors functional programming’s ethos:

Small, pure functions → small, pure components.
Pipeline composition → JSX composition.
No side effects → predictable rendering.

This mindset makes components easy to test, reason about, and reuse. Just as FP warns against large impure functions, frontend engineers should resist "God Components."

Composability in VueJS

React isn’t the only framework where this philosophy thrives. Vue has long encouraged composability via slots and, more recently, the Composition API.

A Vue <Card> might look like:

<Card>
  <template #header>
    <CardHeader>Profile</CardHeader>
  </template>

  <CardBody>Some content</CardBody>

  <template #footer>
    <CardFooter compact>Footer text</CardFooter>
  </template>
</Card>

Key parallels:

Vue’s slots are React’s children.
Vue’s Composition API encourages extracting small, reusable logic units, just like React hooks.
Both frameworks are moving away from monolithic components toward patterns over props.

Lessons from React translate directly into Vue:

Avoid God Components.
Embrace composable slots/components.
Repetition of patterns is good—don’t fear repeating yourself.

Is Composability Still Relevant in React Server Components (RSC)?

With Next.js and RSC, some devs worry composability may be less relevant. After all, server components bring new paradigms: data fetching in the component, zero client-side JavaScript by default.

But composability remains core:

Server components benefit even more from composability: smaller components fetch their own data, keep concerns isolated.
Streaming UI aligns with composability: headers can load before footers, independent of one another.
Client components wrap naturally into the same patterns. A CardHeader can be a client component for interactivity, while CardBody stays a server component for static content.

In fact, the move to RSC makes "God Components" even riskier. Bloated components become harder to cache, harder to stream, and harder to split between client/server boundaries.

Closing Thoughts

Composability isn’t just a coding style—it’s a survival strategy for scalable UI systems. From React’s Radix UI to Vue’s slots, the philosophy of small, focused, repeatable patterns is stronger than ever.

God Components are brittle; composability is robust.
DRY is overrated; repetition of patterns fosters clarity.
Functional programming principles map perfectly onto modern component design.
Composability transcends libraries/frameworks: React/NextJS and Vue /Nuxt converge here.
Even in the age of React Server Components, composability is more critical, not less.

The takeaway: keep building small, composable, repeatable components. Your future self—and your teammates—will thank you.

Forem: Graeme George

Next Stop, Nuxt: A React Engineer’s Journey into Vue

How to Use This Document

👷🏻 Setup (fast)

🧠 Mental model (reframe)

Pattern translations + mini code-labs

1) Children/compound components → Slots & named slots

2) Context → provide/inject

3) Hooks → Composables

4) useMemo / useCallback → computed

5) useEffect side-effects → onMounted / watch / watchEffect

6) Controlled inputs → v-model / defineModel

7) Portals → Teleport

8) Error boundaries → onErrorCaptured / Nuxt error pages

9) Suspense & async UI

10) Routing (React Router/Next) → Vue Router/Nuxt

Cheat Sheet

React → Vue Cheat-Sheet

Bonus: ecosystem mappings

Vue-native best practices (for React folks)

Nuxt for Next engineers (quick map)

4-week self-study plan

Appendix: official docs index

Rethinking Responsibility: Empowering Engineers

The Challenges Engineers Face

Reframing Responsibility

Building a Culture That Empowers

Leadership: Enablers, Not Judges

Closing Reflection

Further Reading

Composability in Component Architecture: Lessons from React, Radix UI, and Beyond

Why "God Components" Fail

Composability Over DRY

Inspirations from Functional Programming

Composability in VueJS

Is Composability Still Relevant in React Server Components (RSC)?

Closing Thoughts

4) `useMemo` / `useCallback` → computed

5) `useEffect` side-effects → onMounted / watch / watchEffect

6) Controlled inputs → `v-model` / `defineModel`

8) Error boundaries → `onErrorCaptured` / Nuxt error pages