Frontend Quickstart
This guide explains the fastest way to get oriented on the frontend side of the Cabloy framework repository.
If you want to create and use a Cabloy project, start with Fullstack Quickstart.
When to use this page
Use this page when you want to move from the framework repository root to the first visible routed screen in Zova with the right edition and script assumptions.
This page is the frontend narrative hub for framework-repository work such as:
- detecting the active edition
- choosing the right root scripts and frontend flavors
- understanding how startup and routing make the app routable
- understanding the app shell around routed pages
- reaching the first routed page and knowing what to read next
Step 1: detect the edition first
Before choosing frontend examples, scripts, or shell assumptions, detect whether you are working in:
- Cabloy Basic
- Cabloy Start
When working in this framework repository, the active edition is Cabloy Basic.
That matters because edition choice affects:
- frontend flavor names
- UI-layer assumptions
- available modules, layouts, and SSR site baselines
- project assets and examples
- which examples in the docs match the current repo directly
Read together with:
Step 2: start from root scripts
When working in the framework repository, begin from the root repository scripts.
These commands are repository-root workflows for framework development and verification, not the default bootstrap path for a normal Cabloy project.
Install and initialize the framework workspace
npm run initStart frontend development for Cabloy Basic
npm run dev:zova:admin
npm run dev:zova:webThese root wrappers currently map to the Basic flavors:
cabloyBasicAdmincabloyBasicWeb
Build frontend output for Cabloy Basic
npm run build:zovaUse the root wrappers as the normal entrypoint for this framework repository, then read the deeper script guide when you need appMode/flavor detail.
Read together with:
Step 3: understand runtime selection
Frontend behavior is not chosen by one flag only. It is shaped by:
modeappModeflavor
Those runtime choices affect:
- which config and env values are active
- which shell/layout components are resolved
- how startup and routing behave in the current frontend variant
- which edition-specific script examples apply
Read next:
Step 4: understand how the app becomes routable
A practical startup split is:
- system startup registers routes and loads system-level config before the app can really become routable
- app startup makes router, guards, and first-navigation behavior operational for the running app instance
That means the first visible screen is not only a page concern. It depends on the startup sequence that prepares routing and navigation behavior first.
Read in sequence:
Step 5: understand the app shell
A routed page does not appear alone. It appears inside an app shell.
In practice, the shell is the layout layer around the routed page. Route metadata chooses a logical layout such as default or empty, and env/config resolves that logical choice into the actual layout component for the active runtime variant.
In the current Basic source, the most important shell shapes are represented by:
- admin-style layout behavior
- web-style layout behavior
- empty/minimal layout behavior
This is why route metadata, guards, aliases, and theme/header/menu behavior should be understood together rather than as unrelated features.
Read together with:
Step 6: reach the first routed page
Once the edition and runtime path are clear, the fastest practical next step is to create a page and understand where it appears.
A useful frontend-first sequence is:
- create or choose a module
- create a page in that module
- let Zova generate the route record and page path
- confirm which shell/layout the route should use
- run the matching frontend flavor and inspect the result
The generated route path follows Zova’s module-oriented naming conventions, so the first page is part of the broader routing and shell model rather than a free-form standalone screen.
Read next:
Step 7: understand menu and CLI ergonomics
Zova supports both command-line and editor-driven workflows.
A practical distinction is:
- CLI is the canonical automation and scriptable workflow surface
- editor menus improve discoverability and ergonomics for the same underlying workflows
That means frontend onboarding should not force a choice between the two. Use menus when they help you discover commands quickly, and use the CLI when you need reproducible automation or explicit command history.
Read next: