# Aether (AE) SvelteKit Application

This project is a Svelte and SvelteKit based application, part of the Aether (AE) system. It uses Tailwind CSS and Skeleton for styling and some elements. This is the frontend UI/UX. The backend API uses Python FastAPI.

Core Aether modules
* accounts - client account, not user account
* hosted_files
* people
* users
* sites and site_domains

Additional Aether modules
* events
    * presentation management - import the program data (events, session, presentations, presenters, event files, locations/rooms, devices)
    * launcher - Technically this is used with presentation management. It is part of the native app that uses Electron. One of the libraries is for functions that only work when the site is opened in an Electron app. For example the regular browser can not move files around on the local computer or run local commands.
    * badge printing
    * lead retrieval - attendee tracking; QR codes
* journals - journal, documentation, notes, diary, blog, etc
* idaa - One of my clients

## Documentation
* TODO.md

## Ignored Directories

The following directories are ignored for various operations (e.g., search, file listing) to focus on relevant source code:
- `build`
- `node_modules`
- `tests`

---

## Refactoring Notes

### `process_ae_obj__*_props()` Refactoring (2025-11-13)

The `process_ae_obj__*_props()` family of functions, which are responsible for transforming API data for frontend use, have been refactored to standardize their structure and improve maintainability.

The refactoring strategy involved creating a local, non-exported `_process_generic_props` helper function within each module (`ae_journals`, `ae_events`, `ae_archives`, `ae_posts`, `ae_core`). This approach was chosen to avoid altering the module import graph, which had previously caused a critical `InternalError: module record has unexpected status: New` in the SvelteKit development server when a shared utility file was introduced.

**Key aspects of the refactoring:**

*   **In-file Generic Helper (`_process_generic_props`):** This function handles common data transformations:
    *   **`*_random` ID Aliasing:** It automatically iterates over object keys and creates a non-suffixed alias for any key ending in `_random` (e.g., `person_id_random` becomes `person_id`). This is crucial for client-side logic that expects standard ID fields.
    *   **`tmp_sort` Field Generation:** It creates a set of basic `tmp_sort` fields for client-side sorting.

*   **`specific_processor` Callback:** Module-specific logic is handled by a `specific_processor` callback function passed to the `_process_generic_props` helper. This allows for:
    *   **Unique `tmp_sort` Logic:** Modules can override the default `tmp_sort` fields with their own specific sorting requirements.
    *   **Content Processing:** Asynchronous operations like Markdown parsing (using `marked.parse`) are handled within the `specific_processor` for the relevant modules (e.g., `ae_journals__journal_entry.ts`).
    *   **Other Special Cases:** Any other module-specific data transformations are handled in this callback.

*   **`core__crud_generic.ts` Cleanup:** The generic CRUD functions in `src/lib/ae_core/core__crud_generic.ts` were simplified:
    *   The `process_ae_obj__props` function in this file was deprecated.
    *   All calls to `process_ae_obj__props` and `db_save_ae_obj_li__ae_obj` were removed from the generic CRUD functions (`load_ae_obj_id`, `load_ae_obj_li`, etc.).
    *   These functions are now responsible only for API interaction, delegating all data processing and caching to the module-specific functions that call them. This enforces a cleaner separation of concerns.