📄️ App design principles
Every Conduction app — OpenRegister, OpenCatalogi, Procest, Pipelinq, MyDash, the dozen others — looks and works the same way on first sight. Same five structural pieces, same place, same behaviour. That recognisability isn't an accident: it's what @conduction/nextcloud-vue enforces, and what makes a user who's learnt one app productive in any of the others within minutes.
📄️ Architecture Overview
@conduction/nextcloud-vue is a Layer 2 component library that sits between Nextcloud's official Vue components and individual Nextcloud apps.
📄️ App manifest
The app manifest is the JSON contract that fills and configures the chassis. One file describes the app's pages, navigation, dependencies, and per-page slots; @conduction/nextcloud-vue reads it and mounts the right stacked views into the chassis automatically.
📄️ Schema-Driven Pattern
The core idea: define your data schema once, get a working UI automatically.
📄️ Schemas and registers
Every Conduction app stores its data in OpenRegister, the schema-driven object store that ships as a Nextcloud app. The schema is the single source of truth for that app's data — and @conduction/nextcloud-vue reads the same schema to drive the frontend. One JSON Schema → typed records on the backend, sortable columns + faceted filters + form fields + validation messages on the frontend.
📄️ Store Architecture
The library provides a Pinia-based store system for managing OpenRegister objects.
📄️ Customising Default Pages
CnIndexPage and its sub-components are designed to be extended without forking. This guide covers every customisation scenario with working code examples.
📄️ Slot naming conventions
All components follow a consistent slot naming scheme. This page documents the conventions so consumer apps use the correct slot names.