Strict Smart/Dumb Components

The claim under test

Almost every Vue codebase of consequence is laid out like this, and almost every team that owns one will tell you they separate smart components from dumb ones. The directory names say so.

src/
├── components/     114 .vue files    ← "presentational"
│   ├── area/
│   ├── charts/
│   └── layout/
├── views/           14 .vue files    ← "containers", one per route
├── composables/     71 .ts files
└── stores/          Pinia

One regular expression settles it. Counting .vue files that mention storeToRefs or a use*Store factory: 50.9% of the files in components/ reach into a Pinia store, against 50.0% of the files in views/. Not a smaller number. The same number.

That is the sharpest possible result, because it is not a near miss. If the two layers touch global state at identical rates, the directory boundary carries literally zero information about what is inside a file. "We follow smart/dumb components" described the dir tree, not the code.

The original pattern, and its author's retraction

The canonical statement is Dan Abramov's 2015 article. It is worth reading his definition precisely, because most repetitions of it are vaguer than the original and drop the clause that actually matters.

Four years later Abramov added a note to the top of that same article. It is not a footnote or a clarification; it is a retraction of the structural advice, and any honest treatment of this pattern has to lead with it.

patterns.dev reaches the same conclusion from the other direction, listing the replacement rather than the regret:

Read the retraction carefully and you will notice it retires exactly one half of the article. The half it retires is the mechanical one.

The rule, stated so it can be tested

Discard "smart" and "dumb": they are adjectives, and adjectives cannot fail a build. What remains is three mechanical properties of a source file. A component either has them or it does not, and a script can tell you which.

• Imports nothing from stores/, and nothing from pinia. No useXStore(), no storeToRefs, at any depth of its import graph.
• Imports no transport. No axios, no fetch wrapper, no base URL, no knowledge that a network exists.
• Receives every piece of data through defineProps, typed, with no fallback path to get it another way.
• Communicates upward only through defineEmits. It reports what happened; it does not decide what follows.
• Owns local UI state only: open/closed, hovered, the draft text in an input. That is not application state and it never was.

Two of these are underwritten by the framework rather than by taste. Vue's props are, in the documentation's words, "a one-way-down binding between the child property and the parent one: when the parent property updates, it will flow down to the child, but not the other way around", and Vue warns in the console when a child tries to write back. The upward channel is deliberately narrow: defineEmits carries a name and a payload, not a reference to anything the parent owns.

The composable leak

This is the part almost every article on the subject omits, and it is the part that decides whether your separation is real. Vue's own guide defines a composable as "a function that leverages Vue's Composition API to encapsulate and reuse stateful logic", and says nothing about which stateful logic, because it cannot. A composable is an ordinary module. It may import a store. Pinia is explicit that a store is instantiated when called "within a component <script setup> (or within setup() like all composables)", which is precisely what makes the hop invisible: the call site looks identical either way.

So a component whose import list contains not one reference to stores/ can still be fully coupled to global state. Every measurement that greps components for use*Store reports it as clean. Every reviewer scanning the imports approves it.

The trade-off is worth naming rather than glossing. You can make useAreaFilters pure by having it take the refs it needs as arguments and import nothing, and then it is safe to call from anywhere, including a leaf. The price is that every call site must thread those refs through, which is real friction and the reason teams stop doing it. The alternative kept here is cheaper and equally enforceable: let the composable own the store, and constrain who may call it.

What this looked like in production

Run the same thing on your own repository before you argue about it. Four commands give you the headline; the last two give you the number that actually matters.

# Every .vue file under components/ that reaches a Pinia store DIRECTLY.
rg -l --glob '*.vue' 'storeToRefs|use[A-Za-z]*Store' src/components | wc -l
rg --files --glob '*.vue' src/components | wc -l          # the denominator

# The same measurement on the layer that is ALLOWED to know about stores.
# If the two percentages match, the directory split is decorative.
rg -l --glob '*.vue' 'storeToRefs|use[A-Za-z]*Store' src/views | wc -l
rg --files --glob '*.vue' src/views | wc -l

# --- the indirect path, which almost nobody measures ----------------------

# 1. Which composables are themselves store-aware?
rg -l 'storeToRefs|use[A-Za-z]*Store' src/composables \
  | xargs -n1 basename | sed 's/\.[jt]s$//' | sort -u > tainted.txt

# 2. Which components import one of those? rg -f reads one pattern per line.
rg -l --glob '*.vue' -f tainted.txt src/components | wc -l

Doing it properly

Three files. The first is the leak as it is normally written. Note that only some of it is visible. Lines marked in red are what a reviewer catches; the pair marked in indigo is the coupling that survives review untouched, because the import that carries it names a composable, not a store.

<!-- Filed under components/, therefore presentational. Allegedly. -->
<script setup lang="ts">
import { computed } from 'vue'
import { storeToRefs } from 'pinia'
import { useAreaStore } from '@/stores/area'
import { useAreaFilters } from '@/composables/useAreaFilters'

const props = defineProps<{ areaId: string }>()

// Leak 1, direct: the card now knows a global store exists, which one it
// is, and how its state is shaped. Three facts of coupling in two lines.
const store = useAreaStore()
const { areas, savingId } = storeToRefs(store)

// Leak 2, indirect: the one that survives review. useAreaFilters imports
// the very same store. Nothing on line 17 says so; the import list is clean.
const { isVisible } = useAreaFilters()

const area = computed(() => areas.value.find(a => a.id === props.areaId))

function rename(name: string) {
  // Leak 3: a leaf writing to global state. The parent cannot intercept it,
  // cannot roll it back, and cannot render this component without Pinia.
  store.rename(props.areaId, name)
}
</script>

<template>
  <article v-if="area && isVisible(area)" class="card">
    <h3>{{ area.name }}</h3>
    <button :disabled="savingId === area.id" @click="rename('Renamed')">Rename</button>
  </article>
</template>

<!-- Presentational: nothing from stores/, nothing from api/, no composable. -->
<script setup lang="ts">
import { computed } from 'vue'
import type { AreaSummary } from '@/types/area'

// The props type is this component's entire contract with the outside world.
// Change it and every call site fails to compile, which is the whole point.
const props = withDefaults(defineProps<{
  area: AreaSummary
  saving?: boolean
}>(), { saving: false })

const emit = defineEmits<{
  (e: 'rename', payload: { id: string; name: string }): void
  (e: 'select', id: string): void
}>()

// Local state is allowed: this is UI state, not application state.
const label = computed(() => (props.saving ? 'Saving…' : 'Rename'))
</script>

<template>
  <article class="card" @click="emit('select', area.id)">
    <h3>{{ area.name }}</h3>
    <button :disabled="saving" @click.stop="emit('rename', { id: area.id, name: 'Renamed' })">
      {{ label }}
    </button>
  </article>
</template>

<!-- Route-level container: the only layer permitted to import a store. -->
<script setup lang="ts">
import { onMounted } from 'vue'
import { storeToRefs } from 'pinia'
import { useRouter } from 'vue-router'
import { useAreaStore } from '@/stores/area'
import { useAreaFilters } from '@/composables/stateful/useAreaFilters'
import AreaCard from '@/components/area/AreaCard.vue'

const router = useRouter()

// storeToRefs lives here and only here: state keeps its reactivity through
// destructuring, while actions come off the store directly, because Pinia binds them.
const store = useAreaStore()
const { savingId } = storeToRefs(store)
const { rename, load } = store

// A store-aware composable is legitimate at this level because it sits inside
// the boundary. Importing it from components/ is what the lint rule forbids.
const { visibleAreas } = useAreaFilters()

onMounted(load)

function onRename(payload: { id: string; name: string }) {
  rename(payload.id, payload.name)
}

function onSelect(id: string) {
  router.push({ name: 'area', params: { id } })
}
</script>

<template>
  <section class="board">
    <AreaCard
      v-for="area in visibleAreas"
      :key="area.id"
      :area="area"
      :saving="savingId === area.id"
      @rename="onRename"
      @select="onSelect"
    />
  </section>
</template>

The second tab is worth one more look. It imports vue and a type. That is the complete list. It can be mounted with a plain object and asserted against without a Pinia instance, without a router, and without a network stub. That testability is not a bonus, it is the same property as the decoupling, observed from a different angle.

Making it enforceable

A convention that lives in a style guide is a convention that will be 50.9% observed. The rule has to fail a build. ESLint's no-restricted-imports, "Disallow specified modules when loaded by import", expresses the whole boundary in one flat-config block, because the rule accepts gitignore-style path patterns and applies them per files glob.

// Flat config. This is what turns "we follow smart/dumb components" from a
// claim about the dir tree into a build failure.
import pluginVue from 'eslint-plugin-vue'

const NO_GLOBAL_STATE = {
  // Both spellings, deliberately. A team that bans only the '@/' alias gets
  // routed around by '../../stores/area' inside a week.
  group: ['pinia', '@/stores/*', '**/stores/*'],
  message: 'Global state is not available at this layer. The container owns the store; receive the value as a prop or an argument.'
}

const NO_TRANSPORT = {
  group: ['axios', 'ofetch', '@/api/*', '**/api/*', '**/services/http*'],
  message: 'No transport at this layer. Emit an event or return a value; the container performs the call.'
}

export default [
  ...pluginVue.configs['flat/recommended'],

  {
    // One rules object per glob. A second config object with the SAME `files`
    // would replace this rule rather than merge with it.
    files: ['src/components/**/*.vue'],
    rules: {
      'no-restricted-imports': ['error', {
        patterns: [
          NO_GLOBAL_STATE,
          NO_TRANSPORT,
          {
            // The composable leak, made syntactic. Store-aware composables live
            // in exactly one directory, and components may not reach into it.
            group: ['@/composables/stateful/*', '**/composables/stateful/*'],
            message: 'This composable owns global state. Call it from the container and pass the result down as props.'
          }
        ]
      }]
    }
  },

  {
    // Closes the loop. Without this, nothing stops a store import landing in the
    // unmarked composables directory, and then the rule above sees nothing at
    // all. Note the single '*': composables/stateful/ is deliberately excluded.
    files: ['src/composables/*.{ts,js}'],
    rules: {
      'no-restricted-imports': ['error', { patterns: [NO_GLOBAL_STATE, NO_TRANSPORT] }]
    }
  }
]

The two blocks are load-bearing together and neither works alone. The first stops a presentational component reaching a store, directly or through the quarantined directory. The second stops the quarantine from being trivially escaped by writing the store import into an ordinary composable instead. Miss the second and you have rebuilt the original hole with extra ceremony.

Lint catches shape. It cannot catch a component that receives a prop named store. The remaining checks belong in review, and they are short enough to actually get used:

• Does this component's import list contain anything other than vue, types, and other presentational components?
• For every composable it calls, open that composable. What does it import? This is the one step that is always skipped.
• Could this component be mounted in a test with a hand-written props object and no plugins?
• Does any prop carry a store, a store slice, or a function bound to a store, rather than plain data and callbacks?
• Does it decide what happens next, or does it report what happened and let the parent decide?
• Is the container at the right level, or is it a route by habit, four pass-through layers above the component that owns the subtree?

Canonical sources

• Dan Abramov: Presentational and Container Components · the original definition, with the author's 2019 retraction at the top. Read both.
• patterns.dev: Container/Presentational Pattern · states that in many cases the pattern can be replaced with Hooks, and lists what is lost.
• Vue 3: Composables · what a composable is, why each caller gets its own state, and the pointer to State Management for anything shared.
• Vue 3: Props · the one-way-down binding, and why a child may not write back.
• Vue 3: Component Events · defineEmits, including the type-only declaration syntax used above.
• Pinia: Core concepts · why a store cannot be destructured directly, what storeToRefs is for, and where a store may be instantiated.
• ESLint: no-restricted-imports · the patterns/group option, and the static-imports-only limitation.