Front-End Structure

Enforce Vue 3 and Ionic three-layer architecture with data-only Pinia stores.

Updated May 13, 2025
One-click install
npx skills add https://github.com/GolferGeek/orchestrator-ai --skill front-end-structure
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: Front-End Structure
Source: https://github.com/GolferGeek/orchestrator-ai/tree/main/.claude/skills/front-end-structure-skill
Command: npx skills add https://github.com/GolferGeek/orchestrator-ai --skill front-end-structure

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill addresses the challenges of inconsistent front-end architecture, which can lead to unmaintainable code, reactivity issues, and complex state management in Vue 3 + Ionic applications.

Core Features & Use Cases

  • Three-Layer Architecture: Enforces a strict View, Service, and Store separation for clear responsibilities.
  • Data-Only Stores: Mandates Pinia stores to hold state exclusively, preventing business logic or API calls from polluting them.
  • Service-Driven API Calls: Ensures all API interactions are handled by services, using transport types for robust and type-safe requests.
  • Use Case: When developing a new dashboard feature, use this skill to ensure your Vue components, Pinia stores, and API services are structured correctly, maintaining reactivity and separation of concerns.

Quick Start

Help me create a new Vue component for a user list, ensuring it follows the front-end structure guidelines for stores, services, and reactivity.

Frequently Asked Questions about Front-End Structure

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure Vue 3 components with separate stores and services?▼

Enforce a three-layer architecture: Vue components handle UI only, Pinia stores hold state via ref/computed with synchronous setters, and services manage all API calls. This separation keeps concerns isolated and maintains automatic reactivity across your view-service-store flow.

Can I keep API logic out of my Pinia stores?▼

Yes. Services should handle all API calls and update stores afterward. Stores hold state exclusively; services use transport types to build type-safe requests, keeping business logic separate and preventing reactivity issues from mixed concerns.

What's the best way to maintain reactivity in Vue 3 when services update Pinia state?▼

Services call APIs and invoke store actions that update state via ref/computed with synchronous setters. This pattern ensures UI reactivity updates automatically as services complete requests, eliminating manual state synchronization.

Do I need transport types for API requests in Vue components?▼

Transport types belong in services, not components. Services build all requests using transport types to enforce type safety and isolate API concerns. Components receive only UI-ready data from stores, keeping the architecture clean.

How do I handle API errors while keeping stores data-only?▼

Services catch errors, optionally update store state, and handle logging or retry logic. Stores remain data holders; services orchestrate all side effects. This keeps reactivity predictable and stores focused on state representation only.