OSIT-AE-App-Svelte/README.md

# One Sky IT's Aether App - SvelteKit v2 with Svelte v5

This uses SvelteKit version 2.x with Svelte version 5.x, DexieJS 4.x, TailwindCSS 4.1, and Skeleton.

# Modules

## Core (`/core/`)

Admin-only views for foundational Aether objects. Minimal UI — primarily used for data management.

- **Accounts** (`/core/accounts/`, `/core/accounts/[account_id]/`)
- **Activity Logs** (`/core/activity_logs/`)
- **Addresses** (`/core/addresses/`, `/core/addresses/[address_id]/`)
- **Contacts** (`/core/contacts/`, `/core/contacts/[contact_id]/`)
- **Lookups** (`/core/lookups/`) — Countries, subdivisions, time zones
- **People** (`/core/people/`, `/core/people/[person_id]/`)
- **Sites** (`/core/sites/`, `/core/sites/[site_id]/`)
- **Users** (`/core/users/`, `/core/users/[user_id]/`)

## Events (`/events/`)

The primary client-facing module for conference and event management.

### Event List (`/events/`)

### Event Detail (`/events/[event_id]/`)

Each event has four sub-modules, each in its own SvelteKit route group:

#### Presentation Management (`/(pres_mgmt)/`)

Manages the full conference program.

- `/events/[event_id]/pres_mgmt/` — Dashboard
- `/events/[event_id]/locations/` — Location list
- `/events/[event_id]/location/[event_location_id]/` — Location detail
- `/events/[event_id]/presenter/[presenter_id]/` — Presenter detail
- `/events/[event_id]/session/[session_id]/` — Session detail
- `/events/[event_id]/reports/` — Presenter, session, and file reports

#### Launcher (`/(launcher)/`)

Kiosk display system; runs on-site to show session schedules and presenter info.

- `/events/[event_id]/launcher/` — Launcher home
- `/events/[event_id]/launcher/[event_location_id]/` — Location-specific display

#### Badges (`/(badges)/`)

Badge printing and management for event attendees.

- `/events/[event_id]/badges/` — Badge list
- `/events/[event_id]/badges/[badge_id]/` — Badge detail
- `/events/[event_id]/badges/[badge_id]/print` — Print a single badge
- `/events/[event_id]/badges/[badge_id]/review` — Review before printing
- `/events/[event_id]/badges/print_list/` — Bulk print queue
- `/events/[event_id]/badges/stats/` — Badge statistics
- `/events/[event_id]/templates/` — Badge template management

#### Leads (`/(leads)/`)

Exhibitor lead capture via QR scan or manual entry.

- `/events/[event_id]/leads/` — Exhibit list
- `/events/[event_id]/leads/exhibit/[exhibit_id]/` — Exhibit detail and lead capture
- `/events/[event_id]/leads/exhibit/[exhibit_id]/lead/[exhibit_tracking_id]/` — Lead detail

#### Event Settings (`/settings/`)

- `/events/[event_id]/settings/` — Event configuration (basic info, pres mgmt, badges, abstracts)

## Journals (`/journals/`)

The "frontier" module — most fully-featured and used as the canonical implementation reference.

- `/journals/` — Journal list
- `/journals/[journal_id]/` — Journal detail and entry list
- `/journals/[journal_id]/entry/[journal_entry_id]/` — Journal entry detail and editor

## IDAA (`/idaa/`)

Custom module for the IDAA client. Built on core Aether objects (Events, Posts, Archives).

- `/idaa/` — IDAA home / dashboard

### Archives (`/idaa/archives/`)

- `/idaa/archives/` — Archive list with media player
- `/idaa/archives/[archive_id]/` — Archive detail and content list

### Bulletin Board (`/idaa/bb/`)

Built on the Posts and Post Comments objects.

- `/idaa/bb/` — Post list
- `/idaa/bb/[post_id]/` — Post detail and comments

### Recovery Meetings (`/idaa/recovery_meetings/`)

Built on the Events object.

- `/idaa/recovery_meetings/` — Meeting list with search/filter
- `/idaa/recovery_meetings/[event_id]/` — Meeting detail

### Video Conferences (`/idaa/video_conferences/`)

- `/idaa/video_conferences/` — Video conference list (Jitsi integration)
- `/idaa/jitsi_reports/` — Jitsi usage reports

## Hosted Files (`/hosted_files/`)

- `/hosted_files/` — File list and upload management
- `/hosted_files/video_util/` — Video processing utility

## Testing (`/testing/`)

Developer sandbox pages — not for production use.

- `/testing/ae_obj_field_editor/` — V3 field editor playground
- `/testing/data_store/` — Data store V3 playground
- `/testing/editor_test/` — CodeMirror / TipTap editor tests
- `/testing/hosted_files/` — File upload tests

# How to build and deploy SvelteKit:

The deployment is fully integrated into the unified **Aether Docker Environment** (`aether_container_env`). The application is built inside a clean Docker container using `vite build --mode <env>`, which reads the corresponding `.env.<env>` file for `PUBLIC_` variables.

## Environments

| Environment | Env file    | Vite mode | API server                |
| ----------- | ----------- | --------- | ------------------------- |
| dev         | `.env.dev`  | `dev`     | `dev-api.oneskyit.com`    |
| test        | `.env.test` | `test`    | `test-api.oneskyit.com`   |
| prod        | `.env.prod` | `prod`    | `api.oneskyit.com`        |

## Commands (from `aether_app_sveltekit/`)

```bash
# Active development — Vite HMR, no Docker
npm run dev

# Build Vite output only (no Docker)
npm run build:dev
npm run build:test
npm run build:prod

# Build Docker image and restart container locally
npm run build:docker:dev
npm run build:docker:test
npm run build:docker:prod

# Deploy to remote server (SSH → linode.oneskyit.com → deploy.sh)
npm run deploy:remote:test
npm run deploy:remote:prod
```

### Technical Details

- **Unified Orchestration**: All services (API, UI, Redis) are managed via `~/OSIT_dev/aether_container_env/docker-compose.yml`.
- **Dockerfile**: Multi-stage build. Stage 1 (builder) runs `vite build --mode $BUILD_MODE` using `.env.$BUILD_MODE`. Stage 2 (runtime) creates the final lightweight Node image.
- **Environment Handling**:
    - `PUBLIC_` variables are baked into the image at build time via the `.env.<mode>` file.
    - Private runtime variables are passed via the Docker Compose `.env` file in `aether_container_env/`.
- **Remote deploy**: `aether_container_env/deploy.sh` handles git pull + Docker build + restart on the server. Triggered via `npm run deploy:remote:*`.

### Client-Side Cache & IDB Version Management

The app uses Dexie (IndexedDB) as a local cache for API data (SWR pattern). To prevent
stale cached records from persisting across deploys, two version-tracking systems exist
in `src/lib/stores/store_versions.ts`:

**localStorage store versions (`AE_LOC_VERSION`, etc.)**
Track the schema of persisted Svelte stores (`ae_loc`, `ae_events_loc`, etc.).
Bump when a store's shape changes in a breaking way (field type change, required rename).
The check runs synchronously at module import time, before any store hydrates.

**IDB content versions (`IDB_CONTENT_VERSIONS`)**
Track the content shape of Dexie table rows — specifically what `properties_to_save`
writes to each table. Bump when `properties_to_save` in an object file changes in a way
that makes existing cached rows stale (fields added/removed/renamed, computed field behavior
changed). The `check_and_clear_idb_table()` helper reads a localStorage key per table and
clears the Dexie table on mismatch. Call it from the module's layout on mount.

**When to bump `IDB_CONTENT_VERSIONS`:**
If you change `properties_to_save` in `ae_events__event.ts` (or any other object file),
bump the matching entry here. Failure to do so has historically caused silent "no data"
states that are extremely difficult to diagnose — stale rows pass silently, filter to zero,
and the error looks identical to a genuinely empty result.

Currently wired: `events.event` (via `src/routes/idaa/(idaa)/+layout.svelte`).
All other tables are defined but not yet wired — see the comment block in `store_versions.ts`.

---

## Developing (Local HMR)

For the best developer experience with Hot Module Replacement (HMR), start a local development server on your host machine:

```bash
npm run dev
```

The local dev server will communicate with the **FastAPI backend running in Docker** (typically via `dev-api.oneskyit.com`). This gives you the speed of local Svelte development with the power of the full Aether stack.

# Rebuild the node_modules directory and manually install extra Svelte packages

Run the npm update to fix the node_modules directory and package.json

```bash
npm list
npm outdated
npm update
npm outdated
npm list
```

Other installs?:
Are both still needed? I know at least one of these is. 2024-07-23

```bash
npm install --save-dev svelte-highlight
npm install --save-dev typescript-svelte-plugin
```

---

# Set up and run

## Packages and dependencies

```bash
npm install --save-dev svelte-highlight typescript-svelte-plugin
npm install flowbite flowbite-svelte tailwind-merge @popperjs/core
```

I am slowly switching from Font-Awesome to Lucide

## Tiptap Editor

- Eventually use Edra? https://edra.tsuzat.com/
    - Best Rich Text Editor, made for Svelte Developers with Tiptap
    - ShadEditor is "evolving" to be Edra.
- ShadCN is still stuck on Tailwind 3. Waiting to upgrade to Tailwind 4.x. Tailwind 4.x was released in late January 2025. ShadCN is still being worked on as of late March 2025.
- [https://github.com/huntabyte/shadcn-svelte/issues/1643](https://github.com/huntabyte/shadcn-svelte/issues/1643)

Need to install ShadCN and Lucide for the Tiptap editor.

```bash
npm install shadcn-svelte
npm install lucide-svelte
npm install mode-watcher
```

Now we initialize the ShadCN and ShadEditor packages. Follow the command line instructions.

```bash
npx shadcn-svelte@next init
npx shadcn-svelte@next add dropdown-menu button tooltip input popover separator
npx shadeditor init
```

More packages related to the Tiptap editor???

```bash
npm install @tiptap/extension-link @tiptap/extension-bullet-list @tiptap/extension-history @tiptap/extension-typography @tiptap/extension-underline
```

### Environment file

The application uses standard SvelteKit `.env` files for build-time configuration (specifically for `PUBLIC_` prefixed variables).

- **`.env.dev`**: Used by `npm run build:docker:dev` and `npm run build:dev`.
- **`.env.test`**: Used by `npm run build:docker:test` and `npm run build:test`.
- **`.env.prod`**: Used by `npm run build:docker:prod` and `npm run build:prod`.
- **`.env.local`**: Used during local development (`npm run dev`).

**Note:** Runtime variables (like private API keys or DB credentials) are managed in the deployment directory's `.env` file and passed to the containers via Docker Compose.

---

## Developing

Start a local development server:

```bash
npm run dev

# or start the server and open the app in a new browser tab
npm run dev -- --open
```

## Deployment

```bash
# Build Docker image locally and restart container
npm run build:docker:dev
npm run build:docker:prod

# Deploy to remote server (linode.oneskyit.com)
npm run deploy:remote:test
npm run deploy:remote:prod
```

These commands use the multi-stage **Dockerfile** to build the app in a clean environment and automatically restart the corresponding Docker containers.