Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.drpn.ai/llms.txt

Use this file to discover all available pages before exploring further.

Darpan’s frontend is the user control surface for the backend engine. It helps users set up connections, define schemas and RuleSets, start reconciliation runs, and reopen saved output without moving that work into the browser. The app is implemented in toaditi/darpan-ui. The current PWA direction is about shell behavior, route structure, keyboard access, responsive layout, and durable browser workflows. It is not currently an offline-first or installable app.

What PWA means today

AreaCurrent behavior
App shellsrc/App.vue owns the shared shell, floating actions, user menu, tenant switcher, theme toggle, and command palette.
Routingsrc/router/index.ts is the route registry and auth gate. Route metadata tells the shell whether the page is static, workflow, authenticated, or public.
NavigationAsk Darpan is the primary global navigation model. The command palette combines static destinations with limited record-backed actions such as saved outputs and SFTP records.
Workflow continuityStatic pages launch workflows with origin state. Workflow pages can return to the originating static page instead of forcing users back through the dashboard.
Browser behaviorRoutes are linkable, page reloads keep route intent, the app respects focus states, and the shell provides a skip link for keyboard users.
User preferenceTheme selection is persisted through the frontend theme helper and reflected in CSS variables.
The frontend does not currently ship a service worker, install prompt, manifest-driven install flow, background sync, or offline reconciliation mode. Those capabilities become documentation topics when they are implemented.

Surface model

Darpan pages are split into three surface types.
SurfacePurposeExamples
ShelllessEntry points without the authenticated app shell.Login.
StaticSaved-record dashboards, editors, and review pages.Dashboard, Schema Library, SFTP Servers, RuleSet Manager, Run Result.
WorkflowGuided create, edit, and run paths.Create Schema, Create Reconciliation Flow, Run Reconciliation, connection edit flows.
Static surfaces are where users inspect durable state. Workflow surfaces are where users make a focused change or start a run. The route metadata contract keeps those surfaces visible to the shell, tests, and shared styling.

Command-first navigation

Darpan avoids assuming a permanent left sidebar or nested application menu. Users start from Ask Darpan, search for the destination, and land directly on the right surface. This matters because the product has several setup records and run-review surfaces. The command model keeps the user focused on intent: open a saved schema, edit an SFTP server, create a run, or review generated output. The command palette is still part of the frontend shell. It routes users to app surfaces while backend search, authorization, reconciliation logic, and output filtering remain service-owned.

Workflow posture

Workflow pages are built to reduce setup ambiguity.
  • Create flows prefer one question per step.
  • Edit flows can use compact single-page layouts when the record already exists.
  • Shared controls own common actions such as save, cancel, selection, inline validation, and shortcut choice cards.
  • Plain Esc can abort an active workflow back to its static origin when one is available.
  • Route state preserves the origin label and path so workflow exits feel tied to where the user started.
This model keeps workflow pages smaller and keeps long-lived records on static surfaces.

Frontend and backend boundary

The frontend stays thin around durable business behavior. It collects user intent, shows saved records, manages browser interactions, and calls JSON-RPC facade services. Tenant filtering, reconciliation rules, output path logic, and service-side validation remain backend-owned. Backend-owned behavior belongs in the Darpan Moqui component. Frontend code consumes those contracts through typed API helpers and presents the result through shared page surfaces.

Future PWA layer

Installability and offline behavior can be added later within the current shell model:
  • Add a manifest only when install behavior is intentional and tested.
  • Add a service worker only with clear cache invalidation and session handling.
  • Treat offline UI as a product state, not a silent network failure.
  • Keep reconciliation execution and generated-output durability on the backend.
  • Document which surfaces work without a network before calling the app offline-ready.
Until then, Darpan is a responsive browser app with PWA-oriented shell patterns, not a fully offline PWA.