Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/SdazaP/ruTournament/llms.txt

Use this file to discover all available pages before exploring further.

ruTournament is built as a fully offline-first single-page application. There is no backend server, no user account system, and no network calls for data persistence. Everything — tournaments, categories, competitors, results, scrambles, and groups — lives entirely inside your browser on the device where the app is running. This architecture makes the app fast and completely self-contained: it works without an internet connection after the initial page load. The trade-off is that data is bound to a single browser on a single device, so understanding the storage model is essential before running a real event.

How it works

ruTournament uses Dexie.js as a wrapper around the browser’s native IndexedDB API. Dexie provides a clean, promise-based interface for reading and writing structured objects, along with index-based querying that would otherwise require verbose IndexedDB boilerplate. The database is named RuTournamentDB and contains a single object store: tournaments. The store is indexed on four fields to enable efficient lookups and filtering:
// src/common/db.ts
export class RuTournamentDexie extends Dexie {
  tournaments!: Table<TournamentLocal, string>;

  constructor() {
    super('RuTournamentDB');

    this.version(1).stores({
      tournaments: 'id, name, status, date', // indexed fields
    });
  }
}

export const db = new RuTournamentDexie();
Each record in the tournaments store is a TournamentLocal object — a deeply nested document containing the complete state of one tournament: its metadata, all categories with their rounds and results, all competitors with their category assignments and roles, and all groups and scrambles. The entire tournament is read and written as a single document rather than across relational tables.

Accessing tournament data

The three primary Dexie operations used throughout the app are:
// Read a single tournament by its ID
const tournament = await db.tournaments.get(id);

// Insert a brand-new tournament
await db.tournaments.add(tournament);

// Update an existing tournament (full document replace)
await db.tournaments.put(tournament);
db.tournaments.get(id) is used by virtually every page that needs to read or mutate a tournament — results pages, the competitor manager, the schedule editor, and the scramble generator all follow the same pattern: fetch the full document, modify the relevant nested fields in memory, then call db.tournaments.put(updatedTournament) to persist the change. db.tournaments.add(tournament) is called once, at the end of the tournament creation wizard, after the organiser completes all three setup steps and presses Finalizar y Crear.

Browser compatibility

IndexedDB is supported in all modern browsers. ruTournament is tested and works well in:
BrowserNotes
Chrome / ChromiumBest experience — highest IndexedDB performance and most reliable storage quotas. Recommended for live events.
Microsoft EdgeEquivalent to Chrome (Chromium-based). Fully supported.
FirefoxFully supported.
SafariSupported in normal browsing. Known caveat: Safari aggressively evicts IndexedDB data in Private Browsing / Incognito mode and may also purge data after 7 days of inactivity in some versions. Avoid Safari Private mode for active tournaments.
Mobile browsersFunctional but not the primary target. On iOS, all browsers use WebKit, inheriting Safari’s storage behaviour.

Data persistence considerations

Clearing browser data will permanently delete all tournaments. Actions that erase IndexedDB include: clicking “Clear site data”, “Clear browsing data” (with cookies/storage checked), or opening the app in an Incognito / Private window. There is no cloud backup and no way to recover deleted data. Never clear site data for the app’s domain while a tournament is in progress.
Beyond explicit clearing, keep these additional constraints in mind:
  • Device and browser scoped. A tournament created in Chrome on your laptop is invisible in Firefox on the same laptop, and completely inaccessible from a different device. If you need a second operator to view or enter results, they must use the same browser on the same machine, or you must transfer the app entirely.
  • No built-in export or sync. ruTournament is intentionally designed for single-organiser use on a dedicated machine. There is no built-in way to export a tournament to a file or import it on another device. Plan for this: designate one computer as the event computer and use only that browser for the duration of the event.
  • No multi-tab isolation. If you open ruTournament in two tabs simultaneously and both tabs write to the same tournament, the second write will silently overwrite the first. Avoid running the app in multiple tabs at the same time.

Storage limits

IndexedDB does not have a fixed hard limit. Browsers grant storage up to a quota based on available disk space — typically 60 % or more of free disk. A ruTournament database containing dozens of tournaments, each with hundreds of competitors across multiple rounds with full scramble sets, will comfortably fit within a few megabytes. You are very unlikely to hit browser storage limits under normal usage.
To protect your data during an active event: bookmark the app URL so you always open the correct origin, and do not clear site data or browser history for that origin until after the event is fully concluded and archived. If you use a shared or school computer, check whether any automatic cleanup policies run overnight — those can wipe IndexedDB between competition days.

Build docs developers (and LLMs) love