Files
OSIT-AE-App-Svelte/GEMINI.md
Scott Idem 7e1eaba3bc feat: Migrate ESLint to flat config and resolve initial linting errors
Migrated the ESLint configuration to the new flat config format ()
and addressed several initial linting errors.

Key changes include:
- Updated ESLint configuration to treat  as warnings instead of errors.
- Fixed  errors in  by declaring  and .
- Corrected  error in  by using  instead of an out-of-scope .
- Resolved  error in  by replacing the undefined  directive with the  component.
- Addressed  errors in  by replacing  with  and  with .
- Fixed  errors in  by importing necessary modules (, , ) and adding missing props (, , , , ).
2025-11-17 18:46:54 -05:00

3.9 KiB

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

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.