Extract Pinia Stores from Bloated Vue Components
If your Vue components are full of repetitive ref() declarations and inline fetch() calls, ask Claude to extract them into a proper Pinia store — it handles the refactor and updates the component in one go.
"This Vue component has 80+ lines of data fetching and local state.
Extract everything into a Pinia store:
- Move all refs and reactive state to the store's state()
- Convert fetch logic into store actions with loading/error states
- Add a $reset() action for testing
- Update the component to use storeToRefs() for reactivity
- Write Vitest tests that use createPinia() and mock the API calls"
Claude generates a typed store and rewrites the component to stay lean — it should only call store actions and render:
// store/useUsersStore.ts
export const useUsersStore = defineStore('users', () => {
const users = ref<User[]>([])
const loading = ref(false)
const error = ref<string | null>(null)
async function fetchUsers() { /* ... */ }
function $reset() { users.value = []; error.value = null }
return { users, loading, error, fetchUsers, $reset }
})
It also handles the subtle bits: resetting state between route navigations, preventing duplicate concurrent fetches with a guard, and setting up a storeToRefs() pattern so reactivity doesn't silently break when you destructure.
Fat components are a maintenance problem — Pinia stores keep your data layer testable and your templates readable.
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.