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.