@lovebowls/leagueelements/src/elements/leagueAdminElement/ai_module_summary.md

League Elements package for LoveBowls

## AI Module Summary: leagueAdminElement

### 1. Module Name

`leagueAdminElement`

### 2. Purpose and Business Logic

The primary purpose of the `leagueAdminElement` module is to provide a user interface for administering leagues, teams, and potentially matches. It allows users to view, add, edit, copy, and delete league entries, manage teams within selected leagues, and interact with match data.

It solves the business problem of providing administrative control over the core entities (leagues, teams, matches) within the application's league management functionality.

### 3. Working Logic

`leagueAdminElement` is implemented as a Custom HTML Element. Its core logic is managed within the `LeagueAdminElement` class, utilizing the Custom Element lifecycle callbacks (`connectedCallback`, `disconnectedCallback`, `attributeChangedCallback`).

-   **Data Handling:** The element receives data for leagues and teams via `data` and `lovebowls-teams` attributes, respectively. It parses this JSON string data internally (`_parseAndLoadData`, `_parseLovebowlsTeamsData`) and manages the internal state (`_leagues`, `_lovebowlsTeams`, `_selectedLeagueId`, `_selectedTeamId`). It dispatches custom events (`dataLoaded`, `dataError`, `leagueSelected`, `attributeChanged`, `lovebowlsTeamsLoaded`, `requestAddTeam`, `requestUpdateTeam`, `requestRemoveTeam`, etc.) to communicate state changes, errors, or user-initiated actions requiring backend interaction.
-   **Rendering:** The element renders its UI based on the internal state and attributes (`render` method), including lists of leagues and teams, action buttons, and modals for editing/creating entities.
-   **User Interaction:** It handles user interactions such as selecting leagues and teams, clicking action buttons (New, Copy, Edit, Delete, Add Team, Edit Team, Remove Team, View Table, Reset League, Add Match, Edit Match), and interacting with modal forms. These interactions often trigger the dispatch of custom events to a parent component or application logic.
-   **Modals:** It includes logic for showing and hiding modals for league and team creation/editing (`_showModal`, `_hideModal`, `_populateModalForm`, `_handleSaveModal`, `_showTeamModal`, `_hideTeamModal`, `_populateTeamModalForm`, `_handleSaveTeamModal`).
-   **State Management:** Internal properties (`_isModalVisible`, `_modalMode`, `_teamModalMode`, etc.) track the UI state.
-   **Inter-component Communication:** It imports and seems to interact with `LeagueMatchesAttention` and `leagueMatch` elements, and uses shared styles and utilities. It primarily interacts with the backend *indirectly* by dispatching custom events that signal requested data operations.
-   **Responsiveness:** It appears to handle responsiveness based on the `is-mobile` attribute, potentially adjusting rendering or behavior (`_updateAttentionPanel`).

### 4. File and Folder Structure

The module is located at `/c:/lb/dev/leagueElements/src/elements/leagueAdminElement`. The primary files analyzed are:

-   `leagueElements/src/elements/leagueAdminElement/leagueAdminElement.js`: Contains the main class definition and logic for the custom element.
-   `leagueElements/src/elements/leagueAdminElement/LeagueAdminElement-styles.js`: Contains the CSS styles for the element, importing shared styles.
-   `leagueElements/src/elements/leagueAdminElement/ai_module_update.md`: Instructions for this analysis.

Other relevant files imported or referenced include:

-   `../LeagueMatchesAttention/LeagueMatchesAttention.js`
-   `../leagueMatch/leagueMatch.js`
-   `../shared-styles.js`
-   `../../utils/temporalUtils.js`
-   `../../test-data/league-test-data.js` (provides structure for test data, useful for understanding expected data format)

### 5. Database Table Structure

Based on the structure of the data handled by the frontend element (as seen in `league-test-data.js` and the element's internal logic), the backend database likely contains collections or tables for:

-   **Leagues:** Contains fields like `_id`, `name`, and possibly references to associated teams and matches. League-specific settings are also stored (e.g., `pointsForWin`, `rinkPoints` settings).
-   **Teams:** Contains fields like `_id` and `name`. Teams might be stored globally or within the context of a league. The frontend data structure suggests teams in a league might have additional league-specific statistics (played, won, etc.), which could be stored in a separate linking table or embedded within the league structure.
-   **Matches:** Contains fields like `key`, `date`, references to `homeTeam` and `awayTeam` (likely via their `_id`), and `result` (containing `homeScore` and `awayScore`).

*   **Note:** This is an inference based on frontend data structures. Confirmation requires analyzing backend migration files or ORM models.

### 6. Tech Stack and Library Versions

-   **Frontend:** Custom Elements API, JavaScript (ES6+), HTML, CSS.
-   **Styling:** Utilizes shared CSS variables and classes imported from `../shared-styles.js`.
-   **Date/Time Handling:** Uses `Temporal` API utilities imported from `../../utils/temporalUtils.js`.
-   **Component Interaction:** Integrates with `LeagueMatchesAttention` and `leagueMatch` custom elements.
-   **Backend Interaction:** Communicates via custom events, implying the use of standard web technologies (e.g., Fetch API, Axios) in a parent component to interact with backend API endpoints.

*   **Information Needed:** Specific versions of any major frontend frameworks (if used in the wider project) or backend technologies.

### 7. Architecture and Code Organization Style

-   **Architecture:** Frontend is built as a self-contained Web Component (`LeagueAdminElement`) extending `HTMLElement`. It uses Shadow DOM for style and DOM encapsulation.
-   **Code Organization:** Follows a class-based structure with distinct methods for handling attributes, lifecycle events, rendering parts of the UI, managing modal state, and handling user input. Styles are separated, and shared utilities/components are imported.

### 8. Module Routes

This module is a frontend custom element and does not define its own application routes. It is designed to be embedded within a larger application structure. Navigation and routing to the page containing this element are handled externally.

Interactions that would typically involve routing in a traditional application (e.g., viewing a league table, editing league rules) are handled by dispatching custom events (e.g., `requestViewLeagueTable`, `requestEditLeagueRules`), allowing the parent application to manage navigation or display other components/pages.

### 9. Controllers and their Meaning

As a frontend component, this module does not contain backend controllers. However, its dispatched custom events imply the existence of corresponding backend controller methods or API endpoints responsible for handling operations such as:

-   Fetching league and team data (likely triggered by the parent component that provides data via attributes).
-   `requestAddTeam`: Endpoint/method to add a new team to a specific league.
-   `requestUpdateTeam`: Endpoint/method to update an existing team within a specific league.
-   `requestRemoveTeam`: Endpoint/method to remove a team from a specific league.
-   Similar endpoints/methods would be expected for league and match operations (e.g., `requestAddLeague`, `requestDeleteLeague`, `requestSaveMatch`, `requestDeleteMatch`).

These backend controllers would handle the business logic for data validation, database interaction, and updating the application state, which would then presumably lead to the frontend element receiving updated `data` attributes.

### 10. Module Services and their Logic

Similar to controllers, this frontend module does not contain backend services. The backend services consumed by the parent application on behalf of this element likely include logic for:

-   Retrieving lists of leagues, teams, and matches.
-   Persisting new league, team, and match data to the database.
-   Updating existing league, team, and match data.
-   Deleting leagues, teams, and matches.
-   Performing validation and business rules checks before data operations.
-   Handling relationships between leagues, teams, and matches.

These services encapsulate the data access and core business logic related to league administration.

### 11. Interaction with Other Modules

-   **Frontend:**
    *   Imports and uses `LeagueMatchesAttention` and `leagueMatch` custom elements within its template/rendering logic.
    *   Uses shared styles (`../shared-styles.js`) for consistent theming and appearance.
    *   Utilizes `TemporalUtils` (`../../utils/temporalUtils.js`) for date and time operations.
    *   Communicates state changes and user actions to its parent context by dispatching custom events.
-   **Backend:**
    *   Interacts *indirectly* with backend services and controllers by dispatching custom events (e.g., `requestAddTeam`, `requestDeleteLeague`). The parent application is responsible for listening to these events and making actual API calls to the backend.
    *   Receives data from the backend via observed attributes (`data`, `lovebowls-teams`), which are populated by the parent application, likely after fetching data through backend endpoints.