Quick answer

PreBook ships as two separate Vue 3 apps - an admin dashboard and a customer-facing booking flow - each with its own Pinia store tree. I migrated all 21 stores to the Composition-API form, and moved API calls and data-shaping out of the stores into one shared model layer both apps import from. Stores now hold state; the model layer owns the HTTP contract.

TL;DR

Problem	Two independently-built Vue apps, each with its own Pinia stores, risked duplicating API-shaping logic and drifting onto inconsistent store patterns
What I did	Migrated all 21 stores (17 admin, 4 frontend) to Composition-API defineStore form, and routed data-shaping through a shared @model/@utils layer
Why it mattered	A backend response-shape change now gets fixed once in the model layer, not separately in every store that touched that data
Team	Solo, with guidance from Jafran Hasan
Part of	A Shared Component Architecture for a WordPress Booking Plugin series →

Two apps, one state-management problem

• Admin and frontend are two separate Vue apps, each with its own Vite config and its own bundle
• No published package between them - they share source through identical path aliases (@components, @model, @utils, ...)
• That's efficient to ship, but risky for state: two independent store trees mean the same data - an appointment, a staff member - could get fetched and shaped differently in each app
• A backend change would then need two separate fixes, with no guarantee they stayed consistent

Migrating every store to the Composition API

• The stores started in Pinia's Options form - defineStore('name', { state, actions, getters }) - split into separate objects by category
• I moved every store in both apps to the Composition form instead: defineStore('name', () => { ... return {...} }), where state, computed values, and methods sit together in one function body
• Both apps' stores (17 admin, 4 frontend) were converted the same day
• Why it's better: in the Options form, a fetch method and the ref it populates end up in different parts of the file. The Composition form keeps related state and behavior next to each other - closer to how <script setup> components already read elsewhere in the codebase

Keeping stores thin with a shared model layer

• The bigger change wasn't the syntax migration - it was what the stores stopped doing afterward
• Most stores in both apps now import from @model instead of making API calls themselves: a ref for the list, a computed for reading it, and methods that call into a model class instead of an endpoint directly
• One BaseModel class defines get, all, create, update, delete, and bulk operations once. Each resource model just sets a route - Appointment and Staff are under 25 lines each, since the CRUD behavior is inherited
• Why it matters with two apps: without BaseModel, a backend shape change would need fixing in both admin's and frontend's stores separately, with no guarantee they stayed consistent. Routed through one model class, the fix happens once and both apps pick it up on their next build

FAQ

Why migrate to Composition API stores instead of leaving the working Options API stores alone? The Options form was working but getting harder to read as stores grew - a fetch method and the ref it populated lived in different parts of the file. Better to pay that cost once, early, than let it widen. Why route data through a shared model layer instead of letting each store call the API directly? Because there are two apps. Logic written inside one store only protects that store - the other app would need the same fix made separately. Centralizing in BaseModel means one fix, both apps inherit it. Why a BaseModel class instead of shared composable functions? Resources mostly differ by route and label - Appointment and Staff need identical CRUD shapes, just different endpoints. A base class with subclasses setting a route expresses that directly. Why migrate both apps' stores on the same day instead of one at a time? So the two store trees reached the new pattern together, instead of reasoning about two different store shapes while writing features that touched both.

Part of the A Shared Component Architecture for a WordPress Booking Plugin series →