Vexlora Documentation Multipurpose React Admin
Modules Routes
Multipurpose buyer handbook · v1.0.0

Vexlora, from first install to production integration.

This guide explains what Vexlora ships, where to edit it, how the 491 page routes (473 buyer-facing application screens, 17 foundation/reference screens and 1 redirect) and 19 dashboards relate, and where your own backend, payment, AI, authentication and data services connect. It is written for buyers who may be new to the codebase.

473 application screens 491 page routes 19 dashboards React 19.3 TypeScript 5.9 Vite 8.3 Tailwind CSS 4.3.3

Start here

Vexlora is a React admin-panel template, not a customer-facing storefront and not a production backend.

473
APPLICATION SCREENS

Buyer-facing application routes are counted separately from foundation/reference pages and redirects.

19
BUSINESS DASHBOARDS

Each dashboard has a distinct operating story while sharing the React application shell and design system.

0
PRODUCTION BACKENDS BUNDLED

Databases, secrets, authentication, money movement and AI execution remain buyer-owned.

The most important boundary

Vexlora illustrates administration UX, data contracts and integration handoffs. Replace sample/mock/browser state with your own server/API where production persistence, authorization or sensitive operations are required.

Counting note

The generated React registry contains 491 routes: 473 application screens, 17 foundation/reference screens and 1 root redirect. For marketplace wording, do not present all 491 routes as buyer-facing application screens.

ThemeForest help-file format

This offline documentation covers installation, customization/use, deployment and asset credits for the React edition.

Recommended reading order

Install and run locally

Install npm dependencies and start the Vite development server.

Rebrand centrally

Change product identity, theme tokens, presentation and navigation from shared React/TypeScript configuration.

Understand module ownership

Learn which domain owns business records, payments, finance, integrations and AI actions.

Connect your backend

Swap mock/repository boundaries for your production API without rewriting the UI.

Certify before release

Run runtime checks, TypeScript validation and the Vite production build, then test critical routes in current browsers.

Installation

The React edition uses npm, TypeScript and Vite. Install dependencies once, then use the provided scripts for development, validation and production builds.

Requirements

  • Node.js 20.19.0 or newer
  • npm
  • Current Chromium, Firefox or Safari browser
  • Git is optional but recommended for buyer changes

Included stack

React 19.3.0, React DOM 19.3.0, React Router DOM 7.18.3, TypeScript 5.9.3, Vite 8.3.2, Tailwind CSS 4.3.3, Recharts, TanStack React Table, React Hook Form and Zod.

Fresh install

npm install
npm run dev

Vite prints the local development URL in the terminal. The default development port is normally 5173.

Validation and production build

npm run check:runtime
npm run typecheck
npm run build
npm run preview
Build output

The production bundle is written to dist/. npm run preview serves that production output locally for final checks.

Environment variables

Anything exposed through browser-side Vite configuration is public to the client. Never place private API keys, payment secrets or server credentials in VITE_* variables.

Project structure

The route layer stays thin; shared UI, business features, data contracts and configuration have separate ownership.

project-root/ ├── index.html # Vite HTML entry ├── package.json # scripts + React dependencies ├── vite.config.ts # Vite + Tailwind plugin config ├── src/ │ ├── main.tsx # React bootstrap │ ├── react-app.tsx # React Router route graph │ ├── app-providers.tsx # global providers │ ├── pages/ # 491-route page layer │ ├── layouts/ # dashboard/auth/nested layouts │ ├── components/ # reusable React UI │ ├── features/ # domain-owned feature modules │ ├── config/ # product/navigation/presentation │ ├── data/ # shared data fixtures │ ├── lib/ # repositories/security/i18n helpers │ ├── hooks/ # reusable React hooks │ ├── types/ # shared TypeScript types │ └── globals.css # Tailwind + semantic theme tokens ├── public/ # local static assets ├── scripts/ # runtime/source validation └── documentation/ # buyer documentation portal
Page composition rule

Keep pages focused on route composition. Put reusable UI in src/components/, domain behavior in src/features/, shared configuration in src/config/ and API/repository boundaries in src/lib/.

Customize safely

Most buyer changes have a central entry point. Start there before editing many React pages.

Brand identity

Edit src/config/product.ts for product identity and shared branding configuration. Replace project brand assets under public/brand/.

Colors, radius, font

Use semantic tokens in src/globals.css and presentation settings in src/config/presentation.ts. Avoid page-by-page hardcoded styles.

Default layout

Layout behavior is centralized in src/config/layout-engine.ts and the components under src/layouts/.

Application shell

Shared shell behavior/configuration lives in src/config/application-shell.ts, src/components/layout/ and the global providers.

Do

  • Change semantic design tokens
  • Reuse shared React components and feature patterns
  • Keep business data feature-owned
  • Run quality gates after structural changes

Do not

  • Fork shared components per page without need
  • Scatter API credentials through browser code
  • Duplicate table or chart engines per feature
  • Put production card/CVV or banking secrets in client state

Shell & navigation

React Router, the dashboard/auth layouts, breadcrumbs, command discovery and topbar behavior are driven by shared route and navigation configuration.

Navigation

Edit the matching area file under src/config/navigation/. The composed navigation registry is src/config/navigation.ts.

Layouts

src/layouts/ contains the dashboard, authentication, CRUD Builder and invoice workspace layouts.

Routing

src/react-app.tsx owns the React Router graph, route-level lazy loading, loading boundaries and 404 behavior.

Add a permanent navigation item

Create the React page first.

Place the page under src/pages/<area>/... and keep business logic in the owning feature module.

Register the route.

Add the route to src/react-app.tsx using the same dashboard/auth layout ownership pattern.

Add navigation only when permanent.

Update the appropriate file under src/config/navigation/.

Validate.

Run the runtime checker, TypeScript check and production build.

npm run check:runtime
npm run typecheck
npm run build
Contextual routes

Create, edit, details and preview screens usually should not become permanent sidebar destinations. Link to them from the owning workspace.

The 19 dashboards

Dashboards share shell/theme/responsive foundations, but their composition, charts and operating questions are deliberately different.

Executive

Leadership posture, board signals, growth quality and strategic decisions.

/dashboard/executive

SaaS

MRR, ARR, churn, retention, activation and subscription growth.

/dashboard/saas

eCommerce

Sales, orders, conversion, fulfillment and commerce health.

/dashboard/ecommerce

CRM

Pipeline, forecast, account health, activities and seller performance.

/dashboard/crm

Analytics

Traffic, engagement, conversion, attribution and realtime signals.

/dashboard/analytics

Finance

Treasury, cash flow, close readiness, receivables and spend.

/dashboard/finance

Projects

Portfolio delivery, project capacity, milestones and blockers.

/dashboard/projects

Marketing

Campaign performance, channel mix, creative quality and growth.

/dashboard/marketing

HR

Workforce, recruiting, attendance, payroll and learning.

/dashboard/hr

Support

Queues, SLA, agent operations, self-service and escalation.

/dashboard/support

Logistics

Shipments, carrier performance, network flow and exceptions.

/dashboard/logistics

Inventory

Stock health, replenishment, aging, transfer and count controls.

/dashboard/inventory

ERP

Procurement, suppliers, warehouse, MRP, sales and finance handoffs.

/dashboard/erp

Energy

Grid, demand, metering, storage, assets and sustainability.

/dashboard/energy

Construction

Portfolio, site operations, workforce, safety and cost.

/dashboard/construction

Hospital

Patient flow, ICU, beds, theatre, staffing and revenue cycle.

/dashboard/hospital

Education

Enrollment, attendance, learning outcomes, faculty and fees.

/dashboard/education

Real Estate

Portfolio, occupancy, leasing, listings, deals and cash flow.

/dashboard/real-estate

AI

Models, agents, usage, cost, governance and business impact.

/dashboard/ai
Customization path

Dashboard pages live under src/pages/dashboard/<name>.tsx ; business data/charts live under src/features/dashboards/ ; shared chart behavior lives under src/components/charts/ and src/config/chart-system.ts .

How the modules relate

Vexlora avoids duplicating ownership. A business domain owns why something happens; shared control planes own cross-cutting execution.

Commerce order to money and fulfillment

eCommerce Order / customer intent
→
Payment Core Pay-in / routing
→
Finance Settlement / accounting
→
Inventory + Logistics Stock / fulfillment

SaaS customer lifecycle

SaaS Plan / subscription
↔
CRM Account / renewal
↔
Support Service / health
→
Finance + Payments Invoice / collection

Outgoing obligation

HR / ERP / Projects / Construction Approved obligation
→
Finance Payable / funding
→
Payment Core Payout rail

AI operating layer

Business module Safe context
→
AI copilot / agent Reason / propose
→
Human approval Governed action
→
Buyer API Server-side write
Reporting ownership

Finance Reports owns financial statements, eCommerce Reports owns commerce reports, CRM Reports owns sales/customer reporting, and Analytics Reports owns cross-module correlation.

Replace mock data with your API

Vexlora keeps rendering separate from persistence so buyers can replace sample repositories without rebuilding the visual system.

React page / featureUI + interaction
→
Repository / route-data hooktyped data boundary
→
Your APIauth + validation + DB

Mock repository foundation

src/lib/data/mock-repository.ts supports sample/frontend data boundaries.

REST integration foundation

src/lib/data/rest-repository.ts, src/lib/data/contracts.ts and src/hooks/use-route-data.ts provide the main integration patterns.

Expected list shape

type PaginatedResult<T> = {
  items: T[]
  page: number
  pageSize: number
  total: number
  totalPages: number
}
Keep secrets server-side

React/Vite code runs in the browser. Authentication secrets, private provider credentials, payment secrets and privileged mutations belong behind your server/API.

eCommerce & Online Store

The eCommerce suite owns product/order/inventory/checkout/marketplace operations. Online Store is an admin-side content/navigation configurator for a buyer-owned storefront.

Core eCommerce

Products, Orders, Inventory, Checkout & Pricing, Marketplace, Reports and Commerce AI.

Engineering reference →

Online Store Studio

Overview, Menus & Navigation, Pages, Blog, Testimonials, Contact us and Popups.

Detailed reference →

Mega-menu flow

Source library pages / products / posts / categories / brands / image
→
Builder drag / nest / reorder
→
Behavior direct · dropdown · mega 2–6 col
→
Your storefront render / animate / persist

Static Pages

Use the Online Store Pages workspace for About, Privacy, Terms and other storefront pages. The HTML editor supports source/preview modes, inline/featured media, SEO and publication controls. Production HTML should be sanitized according to your backend policy.

Blog / media

Blog supports categories, archives, featured images, social-link handoff and Menu Builder sources. Browser image handling is sample-oriented; replace it with your media/CDN API for production.

No customer-facing storefront is bundled

The menu builder and content studio expose admin configuration. Your customer-facing storefront owns final navigation rendering, animation, routing, content delivery and consent/analytics behavior.

Payments & money movement

Payment Core is provider-neutral infrastructure. Finance remains the accounting/reconciliation owner; business domains own the document that explains why money moves.

Business document order / invoice / fee / rent / payroll
→
Payment Core pay-in / split / payout / adjustment
→
Provider + backend secure execution
→
Finance settlement / ledger / reconciliation

Payment Core workspaces

Transactions, Methods, Providers, Accounts, Marketplace, Checkout, Routing, Refunds & Disputes, Payout Routing and Domain Flows.

Frontend can show

  • provider capability and status
  • masked method/account references
  • routing and checkout configuration
  • refund/dispute workflow presentation

Backend must own

  • API secrets and tokens
  • raw card/CVV handling through compliant provider surfaces
  • webhook signature verification
  • idempotency and amount validation
  • actual money movement

See PAYMENT_CORE.md , PAYMENT_INFRASTRUCTURE_2026.md and ECOMMERCE_CHECKOUT_PAYMENTS.md .

AI platform

AI is a flagship operating layer with dedicated workspaces plus contextual copilots across business modules.

Build

Agents, automations, prompts, knowledge, models and media workflows.

Govern

Safety, approvals, identity/access, evaluation, policy and observability.

Operate

Runs, usage/cost, reliability, production operations and cross-module actions.

Contextual action model

Read safe module context
→
Reason model / RAG
→
Propose explain action
→
Approve human / policy
→
Execute buyer server
Provider boundary

The bundled template contains no production AI provider secret and does not execute privileged business writes. Connect your model gateway, RAG service and action API server-side.

Start with AI_FLAGSHIP.md , AI_CROSS_MODULE.md and the specialized AI engineering notes in docs/AI_*.md .

Authentication, users & RBAC

The template includes complete identity/admin presentations, but real session issuance and authorization must be integrated by the buyer.

Authentication screens

Sign in, registration, recovery, verification, OTP, 2FA, magic link and social-login presentation.

Administration

Users, profile/details, activity, sessions, login history, devices, API-key inventory, roles, permissions, teams and departments.

Authorization is server-side

A frontend checkbox or hidden menu item is not a security boundary. Re-evaluate permissions on every sensitive backend request.

Reference: AUTH_RBAC.md and IDENTITY_ACCESS_2026.md .

Forms, tables & charts

Vexlora centralizes interaction engines so buyers change business content without forking foundations.

Forms

React form controls and shared validation patterns. Preserve labels, errors, aria-invalid, accessible descriptions and server revalidation.

Data tables

Shared pagination, sorting, selection, visibility and responsive patterns under src/src/components/data-table/ .

Charts

Chart components use shared chart tokens/config. Keep chart data feature-owned.

Engineering references: FORMS.md , DATA_TABLE.md , CHARTS.md .

Localization & RTL

Locale definitions and formatting are centralized. Direction and presentation state are shared through React providers so LTR and RTL reuse the same components.

Locale config

src/config/i18n.ts defines locale behavior and src/components/providers/locale-provider.tsx provides it to the app.

Formatting

src/lib/i18n/format.ts owns number/date/currency formatting helpers.

RTL presentation

Use the shared presentation provider and logical-direction utility patterns; avoid hardcoding left/right behavior into individual pages.

Responsive, accessibility & quality

Responsive adaptation is intentionally limited to 320–1280px. Above 1280px, preserve the original desktop composition; larger widths should be spot-checked for overflow or regressions without redesigning the layout.

Viewport verification matrix

320 375 430 640 768 1024 1280 1366 1440 1536 1920 px
Layout preservation rule

From 320–1280px, apply only the minimum fixes needed for real responsive issues. Above 1280px, do not reorder blocks, change dashboard composition, make cards full-width, or alter established desktop card geometry.

Responsive checks

  • No page-level horizontal overflow
  • Charts/cards keep readable minimum geometry
  • Tables use mobile cards or explicit overflow
  • Dialogs remain usable at short viewport heights
  • Topbar/sidebar actions remain reachable

Accessibility checks

  • Keyboard-only navigation
  • Visible focus states
  • Named icon buttons and form controls
  • 200%/400% zoom/reflow
  • Screen-reader landmarks, dialogs and tables
npm run check:responsive
npm run check:accessibility

Security architecture

Vexlora includes defensive browser defaults and a buyer-facing Security Center, while clearly separating frontend safeguards from production security controls.

Included frontend defaults

CSP, nosniff, referrer policy, permissions policy, cross-origin opener policy, file preflight, client-side validation and masked credential presentations.

Buyer-owned production controls

Secret vaults, database authorization, WAF/rate limiting, webhook verification, malware scanning, server validation, session issuance and audit persistence.

CSP environment hooks

# Copy .env.example to .env.local, then configure only the keys you need.
# Keep the exact variable names shipped in .env.example.

This keeps the documentation accurate if the product prefix is renamed in a future release; .env.example remains authoritative.

ThemeForest preview

The default frame-ancestor policy allows the ThemeForest preview parent while avoiding broad unrestricted embedding. Add only explicitly trusted origins.

Reference: HIGH_SECURITY.md .

Media, images & asset credits

Sample assets are isolated so buyers can replace them without rewriting page logic. Redistribution evidence must be handled carefully before marketplace submission.

Brand assets

Place buyer-owned logos under assets/brand/ and reference them through productConfig.brand.logoSrc .

Sample imagery

Product, construction and real-estate images live under assets/images/ . See the dedicated credits page before redistribution.

Asset release status

The v1.0.0 source records the Pexels product-photo sources. Real Estate and Construction imagery still requires author-side replacement or retained redistribution/license evidence before final ThemeForest submission. Use the dedicated asset register as the release source of truth.

Open Assets & Credits →

Add a new page or module

Use the existing React Router graph and shared foundations; do not create a parallel application shell.

Create the page.

src/pages/your-area/index.tsx

Create feature ownership.

Put components, data, schemas and types under src/features/your-area/.

Compose shared foundations.

Reuse PageHeader, Card, DataTable, form and chart components instead of copying markup.

Register routing/navigation.

Add the lazy route to src/react-app.tsx and update src/config/navigation/ only if the destination is permanent.

Certify.

Run runtime, TypeScript and production-build validation.

npm run check:runtime
npm run typecheck
npm run build

Build & deployment

Vexlora builds as a Vite-powered React single-page application. Deploy the contents of dist/ and configure SPA history fallback for React Router.

Build

Install dependencies, run validation, then create the optimized production bundle.

npm install
npm run typecheck
npm run build

Preview locally

Test the generated production bundle before upload.

npm run preview
React Router history fallback is required

Direct visits such as /dashboard/executive must return the application index.html. Configure your host to rewrite unknown application routes to the SPA entry.

Vercel example

{
  "rewrites": [
    { "source": "/(.*)", "destination": "/index.html" }
  ]
}

Netlify example

/*  /index.html  200
Subdirectory deployments

If hosting below the domain root, configure the Vite base path and React Router basename for that environment before building.

Updates & upgrade safety

Keep buyer customization centralized and use version control so source upgrades can be merged predictably.

Recommended workflow

  • Commit your current customization
  • Read the new release notes
  • Apply the new source in a separate branch/folder
  • Reapply central config changes first
  • Run upgrade cleanup/preflight gates
  • Run build and browser-test the static package

Protected architecture

The project includes upgrade cleanup/preflight scripts that protect canonical routes and remove retired aliases/files during in-place upgrades.

npm run upgrade:preflight
npm run check:upgrade-preflight-safety
npm run check

Release QA & certification

Use the package scripts to validate the React route graph, TypeScript source and production bundle before release.

Buyer release sequence

npm install
npm run check:runtime
npm run typecheck
npm run build
npm run preview

Runtime graph

check:runtime validates local imports, reachable Next.js runtime imports, route counts, dashboard-shell ownership, CRUD/invoice nested layouts, lazy page loading, loading boundaries and custom 404 wiring.

TypeScript

npm run typecheck runs the TypeScript project build without emitting the production bundle.

Production build

npm run build runs TypeScript validation and creates the Vite dist/ bundle.

Browser QA still matters

After automated checks pass, test navigation, refresh/deep links, light/dark mode, RTL, forms, tables, charts, responsive layouts and critical domain flows in current browsers.

Troubleshooting

Start with the exact failing command and message. For React issues, verify Node/npm versions, dependency installation, TypeScript output, Vite build output, browser-console errors and SPA hosting rewrites before changing application code.

Problem What to check Recommended action
Fresh install mismatch Node/npm version, package-lock, incomplete node_modules or unsupported runtime version Remove node_modules and run npm install again.
Stale Vite/build cache dist/, generated CSS, or other local build output Run npm run clean , then build/test again.
Navigation gate fails Route exists but registry/navigation is stale Run npm run registry:generate , then review the intended navigation owner.
Browser-storage sample behaves strangely Old sample state from an earlier release Use the relevant reset action or clear the Vexlora sample storage for local testing.
CSP blocks an API Production API/WebSocket origin is not allowed Add only the required API/WebSocket origin to the CSP connect-source variable defined in .env.example .
Upload works in sample but must persist Browser adapter is not a production media service Connect the picker to your own upload/CDN API and store safe returned URLs/IDs.

Frequently asked questions

Short answers to the questions buyers most often have when adapting a large admin template.

Does Vexlora include a backend?

No. It is a frontend-only admin template with mock/sample state and integration-ready contracts.

Can I use it with my existing storefront or backend?

Yes. The admin is intentionally isolated. Online Store exposes content/navigation configuration; your storefront owns customer-facing rendering.

Can I use a REST, GraphQL or different backend?

Yes. The visual layer is provider-neutral. Adapt the data/integration boundary to your backend.

Are payments live?

No. Payment Core is configuration/workflow UI. Connect actual providers and webhooks through secure server code.

Is AI required?

No. Core business workflows remain usable without an AI provider. AI is an optional flagship enhancement layer.

Where do I change the brand?

Start with src/config/product.ts , then update semantic theme tokens if needed.

Engineering references included with the source

The docs/ directory contains detailed architecture notes for AI, payments, eCommerce, CRM, data layer, security, accessibility, responsive behavior, settings, reporting, industry suites and more. This buyer portal summarizes those contracts; the Markdown files provide implementation depth.