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.
The same vocabularies are also exported as runtime enums — MatchUpStatusEnum.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 competitionDOUBLES/DOUBLES_EVENT- Doubles competitionTEAM/TEAM_EVENT- Team competitionAGE- Age-based categoryRATING- Rating-based categoryBOTH- 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 roundnonDirectingMatchUpStatuses- Statuses that don't advance participantscompletedMatchUpStatuses- All terminal statusesactiveMatchUpStatuses- Statuses representing concluded matchesupcomingMatchUpStatuses- Statuses for future/ongoing matchesvalidMatchUpStatuses- All valid status valuesparticicipantsRequiredMatchUpStatuses- Statuses requiring participant assignmentrecoveryTimeRequiredMatchUpStatuses- 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:
| Field | Extended (canonical, stored) | Short code | Excludes |
|---|---|---|---|
gender (event, team, category) | MALE FEMALE MIXED ANY | M F X A | OTHER |
sex (person) | MALE FEMALE OTHER | M F O | ANY, 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 filtering —
getParticipants({ participantFilters: { genders } })matches a storedperson.sexwhether it isMALEorM, and accepts short-code filter values. - Team / collection definitions —
modifyCollectionDefinitioncoerces the gender diff and normalizes the stored value to the extended form. - Sanctioning — proposal validation coerces
event.genderagainst a tier'sallowedGendersso 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.
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;
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 volleyball → BEACH_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
- Import only what you need - Import specific constant groups rather than the entire
factoryConstantsobject - Use constants consistently - Always use exported constants instead of hardcoded strings
- Destructure for readability - Extract frequently used constants at the module level
- 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') {
/* ... */
}