-
Notifications
You must be signed in to change notification settings - Fork 38
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
Conversation
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 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 |
b6eda85
to
ad5cbc0
Compare
b60830a
to
e9d1658
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yay! Thank you!
You're welcome! Thank you for waiting this long... 😅 |
Available in v1.5.0 |
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:
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.
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:
And this is how you would fetch participant info like nationality or profile image instead of, well, querying against a user collection:
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.