Skip to main content

Constants

The Competition Factory exports groupings of constants that are used throughout the codebase for consistent naming and type safety. Constants are organized into logical categories and can be imported individually or accessed via the factoryConstants object.

tip

The same vocabularies are also exported as runtime enumsMatchUpStatusEnum.COMPLETED instead of COMPLETED. The two surfaces carry identical values (machine-enforced), so they can be mixed freely.

Import Constants

// Import all constants
import { factoryConstants } from 'tods-competition-factory';

// Or import specific constant groups
import {
eventConstants,
genderConstants,
matchUpStatusConstants,
participantConstants,
drawDefinitionConstants,
} from 'tods-competition-factory';

Available Constant Groups

Event & Match Constants

eventConstants - Event types and category types

const { SINGLES, DOUBLES, TEAM, AGE, RATING, BOTH } = factoryConstants.eventConstants;
  • SINGLES / SINGLES_EVENT - Singles competition
  • DOUBLES / DOUBLES_EVENT - Doubles competition
  • TEAM / TEAM_EVENT - Team competition
  • AGE - Age-based category
  • RATING - Rating-based category
  • BOTH - Combined age and rating category

matchUpTypes - Match format types

const { SINGLES, DOUBLES, TEAM } = factoryConstants.matchUpTypes;

matchUpStatusConstants - MatchUp lifecycle states

const {
TO_BE_PLAYED,
IN_PROGRESS,
COMPLETED,
WALKOVER,
DEFAULTED,
RETIRED,
ABANDONED,
CANCELLED,
BYE,
SUSPENDED,
INCOMPLETE,
AWAITING_RESULT,
DEAD_RUBBER,
NOT_PLAYED,
DOUBLE_WALKOVER,
DOUBLE_DEFAULT,
} = factoryConstants.matchUpStatusConstants;

Status groupings are also exported:

  • directingMatchUpStatuses - Statuses that direct participants to next round
  • nonDirectingMatchUpStatuses - Statuses that don't advance participants
  • completedMatchUpStatuses - All terminal statuses
  • activeMatchUpStatuses - Statuses representing concluded matches
  • upcomingMatchUpStatuses - Statuses for future/ongoing matches
  • validMatchUpStatuses - All valid status values
  • particicipantsRequiredMatchUpStatuses - Statuses requiring participant assignment
  • recoveryTimeRequiredMatchUpStatuses - Statuses where recovery time applies

Draw & Structure Constants

drawDefinitionConstants - Draw types, stages, and positioning

const {
// Draw Types
SINGLE_ELIMINATION,
DOUBLE_ELIMINATION,
ROUND_ROBIN,
ROUND_ROBIN_WITH_PLAYOFF,
COMPASS,
OLYMPIC,
FEED_IN,
CURTIS_CONSOLATION,
FIRST_MATCH_LOSER_CONSOLATION,
FIRST_ROUND_LOSER_CONSOLATION,
AD_HOC,

// Stages
MAIN,
QUALIFYING,
CONSOLATION,
VOLUNTARY_CONSOLATION,
PLAY_OFF,

// Positioning
CLUSTER,
SEPARATE,
WATERFALL,
TOP_DOWN,
BOTTOM_UP,
RANDOM,

// Link Types
WINNER,
LOSER,
POSITION,
} = factoryConstants.drawDefinitionConstants;

Participant Constants

participantConstants - Participant types and states

const { INDIVIDUAL, PAIR, TEAM, GROUP, SIGN_IN_STATUS, SIGNED_IN, SIGNED_OUT } = factoryConstants.participantConstants;

participantRoles - Roles participants can have in a tournament. See Participant Roles.

const {
ADMINISTRATION,
CAPTAIN,
COACH,
COMPETITOR,
DIRECTOR,
HOSPITALITY,
MEDIA,
MEDICAL,
OFFICIAL,
OTHER,
SECURITY,
STRINGER,
SUPERVISOR,
TRANSPORT,
VOLUNTEER,
} = factoryConstants.participantRoles;

genderConstants - Gender categories and abbreviations

const {
MALE,
FEMALE,
MIXED,
ANY,
OTHER,
MALE_ABBR, // 'M'
FEMALE_ABBR, // 'F'
MIXED_ABBR, // 'X'
ANY_ABBR, // 'A'
OTHER_ABBR, // 'O'
} = factoryConstants.genderConstants;

Short codes and normalization

The factory accepts the TODS Standard Codes short forms as input wherever a gender or sex is supplied (event.gender, person.sex, mock draw/event profiles, participant modifications). Short codes are normalized to the extended canonical form on write, so records are always stored canonically — event.gender: 'M' is persisted as MALE, person.sex: 'F' as FEMALE.

Two distinct vocabularies apply:

FieldExtended (canonical, stored)Short codeExcludes
gender (event, team, category)MALE FEMALE MIXED ANYM F X AOTHER
sex (person)MALE FEMALE OTHERM F OANY, MIXED

OTHER is a CourtHive/CODES extension for a person's sex and is not a TODS gender code. ANY and MIXED are gender-only (an individual's sex cannot be "any" or "mixed"). Because storage is always canonical, the published TODS schema enumerates only the extended forms.

Reads and comparisons honor short codes too. setState does no normalization, so externally-built records may store either form. To keep matching correct regardless, gender/sex comparisons coerce both sides to the canonical form before comparing — they are not limited to the write path:

  • Participant filteringgetParticipants({ participantFilters: { genders } }) matches a stored person.sex whether it is MALE or M, and accepts short-code filter values.
  • Team / collection definitionsmodifyCollectionDefinition coerces the gender diff and normalizes the stored value to the extended form.
  • Sanctioning — proposal validation coerces event.gender against a tier's allowedGenders so an abbreviated gender is not wrongly rejected.

In short: write paths normalize to the extended (canonical) form; read / filter / validate paths coerce for comparison without mutating stored data.

Entry & Status Constants

entryStatusConstants - Entry status values

const {
DIRECT_ACCEPTANCE,
ORGANISER_ACCEPTANCE,
ALTERNATE,
UNGROUPED,
UNPAIRED,
WILDCARD,
QUALIFIER,
LUCKY_LOSER,
JUNIOR_EXEMPT,
SPECIAL_EXEMPT,
REGISTERED,
CONFIRMED,
FEED_IN,
WITHDRAWN,
} = factoryConstants.entryStatusConstants;

The module also exports curated groupings — VALID_ENTRY_STATUSES, DIRECT_ENTRY_STATUSES, EQUIVALENT_ACCEPTANCE_STATUSES, STRUCTURE_SELECTED_STATUSES and DRAW_SPECIFIC_STATUSES — so consumers can test membership without re-deriving the sets.

ratingConstants - Rating system identifiers

const {
WTN, // World Tennis Number
UTR, // Universal Tennis Rating
NTRP, // National Tennis Rating Program
} = factoryConstants.ratingConstants;

Time & Scheduling Constants

scheduleConstants - Scheduling-related values

const { SCHEDULE_TIMING, START_TIME, END_TIME, SCHEDULED_TIME, SCHEDULE_DATE, COURTS, VENUES } =
factoryConstants.scheduleConstants;

timeItemConstants - Time item types

const { RANKING, RATING, SEEDING, PUBLISH, SCHEDULE, STATUS, SCORE } = factoryConstants.timeItemConstants;

weekdayConstants - Day of week values

const { MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY } = factoryConstants.weekdayConstants;

bookingTypeConstants - Why a court is occupied

const { SCHEDULED, PRACTICE, MAINTENANCE, DRYING, RESERVED, BLOCKED, CLOSED } = factoryConstants.bookingTypeConstants;

Generated from BookingTypeEnum — see Enums. DRYING is deliberately distinct from MAINTENANCE: maintenance is planned work, drying is a weather-driven delay, and schedulers treat the two differently.

dayStateConstants - A person's self-declared willingness to be scheduled on a given day

const { AVAILABLE, IF_NEEDED, UNAVAILABLE, NOT_SET } = factoryConstants.dayStateConstants;

NOT_SET is the implicit state of any day absent from a declarations payload.

caution

This is person day-state, not court availability. Court availability is BLOCK_TYPES in the Availability Engine — a different vocabulary answering a different question. The two even share the literal 'AVAILABLE' while meaning unrelated things: here "this person said yes", there "no block covers this court time".

availabilityConstants is a deprecated alias for this same object, kept so the rename is not a breaking change. It is slated for removal in the next major — prefer dayStateConstants.

Policy & Configuration Constants

policyConstants - Policy type identifiers

const {
POLICY_TYPE_SCORING,
POLICY_TYPE_SEEDING,
POLICY_TYPE_DRAWS,
POLICY_TYPE_SCHEDULING,
POLICY_TYPE_AVOIDANCE,
POLICY_TYPE_MATCHUP_ACTIONS,
POLICY_TYPE_ROUND_NAMING,
} = factoryConstants.policyConstants;

extensionConstants - Extension name constants

const {
ALTITUDE,
APPLIED_POLICIES,
CATEGORY,
COURT_BOOKING,
ENTRIES,
FLIGHT_PROFILE,
SCHEDULE_TIMING,
SURFACE,
TALLY,
} = factoryConstants.extensionConstants;

Competition Format Constants

tieFormatConstants - Team match tie format values

const { AGGREGATE, TEAM_TIEBREAK, WIN_RATIO } = factoryConstants.tieFormatConstants;

surfaceConstants - Court surface types

const { CLAY, GRASS, HARD, CARPET, ARTIFICIAL_CLAY, ARTIFICIAL_GRASS } = factoryConstants.surfaceConstants;

scaleConstants - Scale/ranking system types

const { SEEDING, RANKING, RATING } = factoryConstants.scaleConstants;

Action & Modification Constants

matchUpActionConstants - Available matchUp actions

const { REFEREE, SCORE, STATUS, SCHEDULE, START, END, PENALTY, OFFICIAL } = factoryConstants.matchUpActionConstants;

positionActionConstants - Position assignment actions

const {
ASSIGN_BYE,
ASSIGN_PARTICIPANT,
LUCKY_PARTICIPANT,
REMOVE_ASSIGNMENT,
SWAP_PARTICIPANTS,
WITHDRAW_PARTICIPANT,
} = factoryConstants.positionActionConstants;

actionMethodConstants - Engine method names carried on actions

Every action returned by positionActions() and matchUpActions() looks like { type, method, payload, … }, where method names the engine method to invoke. actionMethodConstants enumerates those method names in one place.

const { ASSIGN_PARTICIPANT_METHOD, ASSIGN_BYE_METHOD, SUBSTITUTION_METHOD, SCHEDULE_METHOD } =
factoryConstants.actionMethodConstants;
note

Most consumers do not need this. Actions are meant to be forwarded verbatim — { method: action.method, params: action.payload } — and code that branches on an action should key off action.type, which positionActionConstants and matchUpActionConstants already expose. This aggregate exists primarily as a type anchor: it is typed against the generated engine-method union, so renaming an engine method fails the factory's own type check rather than surfacing as "method not found" in a consumer.

penaltyConstants - Penalty types

const { BALL_ABUSE, VERBAL_ABUSE, PHYSICAL_ABUSE, COACHING, DELAY_OF_GAME, UNSPORTSMANLIKE_CONDUCT } =
factoryConstants.penaltyConstants;

Data & Resource Constants

auditConstants - Audit trail action types

const { ADD, MODIFY, DELETE } = factoryConstants.auditConstants;

resultConstants - Result outcome types

const { WIN, LOSS } = factoryConstants.resultConstants;

sortingConstants - Sorting options

const { ASCENDING, DESCENDING } = factoryConstants.sortingConstants;

displayConstants - Display format options

const { ABBREVIATED, FULL } = factoryConstants.displayConstants;

Other Constants

flightConstants - Flight-related constants

const { FLIGHT, FLIGHT_PROFILE, SPLIT_LEVEL_BASED, SPLIT_WATERFALL } = factoryConstants.flightConstants;

tournamentConstants - Tournament identifiers

const { TOURNAMENT_RECORDS } = factoryConstants.tournamentConstants;

venueConstants - indoorOutdoor values

const { INDOOR, OUTDOOR, MIXED } = factoryConstants.venueConstants;

INDOOR, OUTDOOR, and MIXED are the values of the indoorOutdoor field (IndoorOutdoorUnion) on tournament, event, and matchUp records.

disciplineConstants - known discipline values (open vocabulary)

const { TENNIS, BEACH_TENNIS, WHEELCHAIR_TENNIS, PADEL, PICKLEBALL, VOLLEYBALL, BEACH_VOLLEYBALL } =
factoryConstants.disciplineConstants;

event.discipline is an open, sport-agnostic vocabulary (DisciplineUnion): any well-formed value is accepted, so new sports need no factory release. The constants above are the curated known set (used for autocomplete and typo defense). Input is normalized to a canonical form on write (beach volleyballBEACH_VOLLEYBALL), and a fixed list can be enforced where required via the allowedDisciplines policy (e.g. a sanctioning tier). Per-sport defaults (applicable matchUpTypes, default scoring format) live in the discipline profile registry, resolved with fixtures.getDisciplineProfile({ discipline }) and extensible at runtime via fixtures.registerDisciplineProfile({ discipline, matchUpTypes, defaultMatchUpFormat }).

competitionFormatConstants - Competition format profiles and timing scopes

const {
PICKLEBALL_STANDARD,
INTENNSE_STANDARD,
TENNIS_STANDARD,
MATCHUP,
SET,
HALF,
SEGMENT,
BETWEEN_GAMES,
BETWEEN_POINTS,
ANY,
} = factoryConstants.competitionFormatConstants;

PICKLEBALL_STANDARD / INTENNSE_STANDARD / TENNIS_STANDARD name format profiles (fixtures.competitionFormats); the remainder are the scopes a timing or interruption rule can apply to. A profile carries what a matchUpFormat code cannot: server rule, timeouts, penalties and the sport's point vocabulary.

swissConstants - Swiss pairing tiebreak and grouping methods

const { BUCHHOLZ, MEDIAN_BUCHHOLZ, SONNEBORN_BERGER, PROGRESSIVE_SCORE, SCORE_GROUP, RATING_BASED } =
factoryConstants.swissConstants;

tallyConstants - Tally method identifiers

const { GEM_SCORE } = factoryConstants.tallyConstants; // 'GEMscore'

rankingConstants - Ranking-points pipeline vocabulary

const { RANKING_POINTS, QUALITY_WIN, FULL_TO_EACH, SPLIT_EVEN, TEAM_ONLY } = factoryConstants.rankingConstants;

FULL_TO_EACH / SPLIT_EVEN / TEAM_ONLY are doubles points-distribution modes. The module also exports CATEGORY_SCOPE_FIELDS and PROFILE_SCOPE_FIELDS, the field lists a points profile may scope on. See Ranking Points Pipeline.

pointsAuthorityConstants - Bodies that award ranking points

const { ATP, WTA, ITF, ITF_JUNIOR, ITF_WHEELCHAIR, TENNIS_EUROPE, USTA, LTA, FFT, DTB, PPA, BWF, UTR, UNSPECIFIED } =
factoryConstants.pointsAuthorityConstants;

POINTS_AUTHORITIES is exported as the full array.

sanctioningConstants - Sanctioning proposal lifecycle

const { DRAFT, SUBMITTED, UNDER_REVIEW, APPROVED, CONDITIONALLY_APPROVED, REJECTED, WITHDRAWN } =
factoryConstants.sanctioningConstants;

Also MODIFICATION_REQUESTED, ACTIVE, POST_EVENT, CLOSED, ISSUES_FLAGGED, plus VALID_STATUS_TRANSITIONS — the state machine mapping each status to its legal successors. See Sanctioning Policy.

officiatingConstants - Official certification, evaluation and assignment states

const { CERT_ACTIVE, CERT_EXPIRED, CERT_SUSPENDED, CERT_REVOKED, CERT_PENDING_RENEWAL } =
factoryConstants.officiatingConstants;

Three prefixed groups — CERT_* (certification), EVAL_* (evaluation workflow: DRAFT, SUBMITTED, REVIEWED, APPROVED, REJECTED) and ASSIGN_* (assignment: PROPOSED, CONFIRMED, DECLINED, CANCELLED, COMPLETED) — each with a VALID_*_TRANSITIONS map. The prefixes exist because the raw values collide across groups (APPROVED is both an evaluation and a sanctioning status). See Officiating Engine.

keyValueConstants - Key bindings for keyboard-driven score entry

const { OUTCOMEKEYS, SIDE1KEYS, SIDE2KEYS, MODIFIERS, PROMPT, MOVEUP, MOVEDOWN, HOTKEYS } =
factoryConstants.keyValueConstants;

Used by the keyValue scoring helper to map keystrokes onto score mutations.

topicConstants - Notification/subscription topic types

const { AUDIT_TOPIC, MODIFY_MATCHUP_TOPIC, PUBLISH_TOPIC } = factoryConstants.topicConstants;

errorConditionConstants - Error codes for validation and operations

// Import the large collection of error condition constants
const { INVALID_VALUES, MISSING_VALUE, NOT_FOUND } = factoryConstants.errorConditionConstants;

requestConstants - Request parameter constants

const { REQUEST_PARAMS } = factoryConstants.requestConstants;

resourceContants - Resource type identifiers

const { MATCHUP, EVENT, PARTICIPANT } = factoryConstants.resourceContants;

Usage Examples

Event Creation

const { eventConstants, genderConstants } = factoryConstants;

const event = {
eventType: eventConstants.SINGLES,
gender: genderConstants.FEMALE,
};

MatchUp Status Checking

const { matchUpStatusConstants, completedMatchUpStatuses } = factoryConstants;

if (completedMatchUpStatuses.includes(matchUp.matchUpStatus)) {
// Handle completed match
}

// Or check specific status
if (matchUp.matchUpStatus === matchUpStatusConstants.COMPLETED) {
// Process result
}

Draw Generation

const { drawDefinitionConstants } = factoryConstants;

const drawProfile = {
drawType: drawDefinitionConstants.SINGLE_ELIMINATION,
stage: drawDefinitionConstants.MAIN,
drawSize: 32,
};

Participant Filtering

const { participantConstants } = factoryConstants;

const individuals = participants.filter((p) => p.participantType === participantConstants.INDIVIDUAL);

Type Safety

All exported constants are typed and provide autocomplete support in TypeScript-enabled editors. Using these constants ensures:

  • Consistent naming across your application
  • Reduced typos and bugs
  • Better IDE autocomplete
  • Easier refactoring
  • Self-documenting code

Best Practices

  1. Import only what you need - Import specific constant groups rather than the entire factoryConstants object
  2. Use constants consistently - Always use exported constants instead of hardcoded strings
  3. Destructure for readability - Extract frequently used constants at the module level
  4. Check status arrays - Use exported status arrays (like completedMatchUpStatuses) for status checking rather than listing values manually
// Good
const { SINGLES, DOUBLES } = eventConstants;
if (event.eventType === SINGLES) {
/* ... */
}

// Avoid
if (event.eventType === 'SINGLES') {
/* ... */
}