Eozilla App

Eozilla App is a Vite + React + TypeScript frontend for OGC API - Processes services.

It lets you connect to a OGC API - Processes service, browse processes, inspect jobs, and review inputs, outputs, and results in a split-panel interface.

At A Glance

• Purpose: interact with OGC API - Processes services from a browser UI
• UI library: Mantine
• State management: Zustand
• Data flow: service registry and provider adapters in src/service
• Persistence: local app state in src/state
• Testing: Vitest

What You Can Do

• Select and load a service provider
• Browse available processes
• Inspect process descriptions, inputs, and outputs
• View the job list and job details
• Open job results and error tracebacks
• Persist selected service and UI state locally

Repository Map

src/
  components/   UI building blocks, dialogs, and panels
  service/      OGC API - Processes models, providers, registry, and helpers
  state/        Persisted app state and related types
  store/        Zustand store, actions, and hooks
  utils/        General helpers, field utilities, and JSON/schema logic
  main.tsx      Application entry point

Useful entry points when exploring the code:

• src/main.tsx initializes providers, notifications, and the app root.
• src/components/Main.tsx defines the main split-panel layout.
• src/service/index.ts re-exports service-related modules.
• src/store/store.ts sets up application state.

Getting Started

Prerequisites

• Node.js and npm
• Optional: Pixi and a checkout of eozilla for team development and the local Eozilla Dev-Service backend, see below.

Team Development Workspace

Eozilla App is maintained as a separate Git repository, checked out inside the Eozilla repository. This is the standard team workspace layout:

eozilla/
  eozilla-app/

Create the workspace with:

git clone https://github.com/eo-tools/eozilla.git
cd eozilla
pixi install
git clone https://github.com/eo-tools/eozilla-app.git eozilla-app
cd eozilla-app
npm install

Install Dependencies

npm install

Run The Frontend

npm run dev

Run With The Local Dev Service

The eozilla:dev script expects the standard nested checkout described above. From eozilla/eozilla-app/, run:

npm run eozilla:dev

In a second terminal in the same directory, run:

npm run dev

In the app, select the Dev Service provider.

Useful Scripts

npm run dev            # Start the Vite dev server
npm run eozilla:dev    # Start the local wraptile API server for testing
npm run build          # Type-check and build production assets
npm run eozilla:build  # Type-check and build production assets into eozilla cuiman
npm run tests          # Run the Vitest suite
npm run checks         # Run TypeScript type checking and ESLint
npm run format         # Format source files with Prettier
npm run preview        # Preview the production build locally

Build Versioning

The footer displays the package version plus a release-relative build number:

v0.1.0-dev.0 build 12

The package version comes from package.json. The build number is resolved in this order:

1. VITE_BUILD_NUMBER
2. BUILD_NUMBER
3. The number of commits since the latest reachable public release tag
4. 0

Public release tags are expected to use the vX.Y.Z format, for example v0.1.0. Development or prerelease tags such as v0.1.0-rc.1 are ignored for the reset point.

To manually override the build number for local testing or deployment, set an environment variable before building:

$env:VITE_BUILD_NUMBER="12"
npm run build

VITE_BUILD_NUMBER=12 npm run build

Working On The Codebase

• UI work usually belongs in src/components.
• Process and service integration work usually belongs in src/service.
• Shared app state and actions belong in src/store.
• Persisted app state belongs in src/state.
• Tests live next to the implementation as *.test.ts files.
• Substantial code changes must update the relevant canonical app documentation in ../docs/eozilla-app/ (overview, service providers, schema forms, or dynamic expressions).

For LLMs

• Start with src/components/Main.tsx to understand the app layout.
• Read src/service/* before changing request/response models or provider behavior.
• Read src/store/* before changing cross-component state.
• Keep OGC API - Processes terminology intact:
  • A Process describes a capability exposed by the service.
  • A Job is an execution instance of a process.
• Prefer small, local changes over broad rewrites.
• If you change behavior, run npm run checks and npm run tests before finishing.

License

MIT. See LICENSE.