Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support custom participants #143

Merged
merged 10 commits into from
Nov 4, 2022

Conversation

zestsystem
Copy link
Contributor

Hello!

This PR is related to discussion #142.

Found that the best practice for using this lib with MongoDB is to store each tournament in its own document to minimize the number of database queries and guarantee atomicity on tournament updates. I ran into two issues following this approach:

  1. In order to get additional information about the contestant, like an avatar pic link or a nickname or a nationality or etc., I would have to query for the player info using the id stored in the participants field, but the Participant type only allowed id, tournament_id, and name, and because id field only allowed for number type, I would be forced to store MongoDB ObjectId in the "name" field.

  2. Rather than having to fetch from a string id, I wanted an option to use embedded documents to represent a list of participants.

In order to solve this, I implemented an option to pass in a list of javascript objects as seeding (previously just string, number, and null allowed).

How to Use

This is what a tournament document could look like:

import { Group, Match, MatchGame, Participant, Round, Stage } from 'brackets-model';
import { SharedObjects } from 'some-lib';

interface CustomSingleParticipant extends Participant {
    contestantId: string;
    nationality: string;
    profileImage: string;
    titles: string[];
    type: 'Single';
}

interface CustomTeamParticipant extends Participant {
    contestantId: string;
    members: UserDoc[] | TeamDoc[];
    type: 'Team';
}

interface TournamentDoc extends mongoose.Document {
    id: string;
    stage: Stage[] | [];
    group: Group[] | [];
    round: Round[] | [];
    match: Match[] | [];
    match_game: MatchGame[] | [];
    participant: CustomSingleParticipant[] | CustomTeamParticipant[] | [];
    extraEventInfo: SharedObjects['ExtraInfo'] | [];    
    schemaVersion: number;
}

And this is how you would fetch participant info like nationality or profile image instead of, well, querying against a user collection:

const contstantWithInfo = tournament.participants[match[0].opponent1.id]

What's Next

Currently, the CustomParticipant, CustomSeeding, and CustomInputStage types just extend the types from brackets-model lib. I think it would be cleaner to directly apply these changes in the brackets-model library, so they can all just drop the "Custom" qualifier and be called Participant, Seeding, or InputStage. I would be happy to make those changes in the brackets-model lib if I get the go-ahead.

@Drarig29
Copy link
Owner

Hey @zestsystem! Thanks for the PR. I'm in holidays so I won't have much time to review this (and to accept it, since I'll want to make the changes on brackets-model as you said).

In the meantime, could you remove those single-whitespace changes in the JSDoc comments? It clutters the diff of your PR, which makes it harder to review.

PS: You pushed a fixup! commit, I think you want to squash it 😉

Copy link
Contributor Author

@zestsystem zestsystem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yay! Thank you!

@Drarig29
Copy link
Owner

Drarig29 commented Nov 4, 2022

You're welcome! Thank you for waiting this long... 😅

@Drarig29 Drarig29 changed the title Feat/custom participant Support custom participants Nov 4, 2022
@Drarig29 Drarig29 merged commit 7883e0e into Drarig29:master Nov 4, 2022
@Drarig29
Copy link
Owner

Drarig29 commented Nov 4, 2022

Available in v1.5.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants