Closed dci2112 closed 5 years ago
I do think we could have the default implementation do more as well as potentially derive some implementations from data as you suggest. But there are special cases everywhere that we need code for. For example:
1) Here we implement the "Legendary in every pack" rule for Dominaria: https://github.com/jjallaire/draftpod/blob/master/src/store/modules/draft/set/set-dom.js#L23-L30
2) Here we make sure that cards we select in the rare/uncommon/common slots for Unstable never include contraptions: https://github.com/jjallaire/draftpod/blob/master/src/store/modules/draft/set/set-ust.js#L19-L21
3) Here we implement the M19 probability distribution for dual vs. basic lands: https://github.com/jjallaire/draftpod/blob/master/src/store/modules/draft/set/set-m19.js#L23-L27
So I don't think we will be able to avoid having a JS file for most sets. Given that I think it's okay to leave things as they are (as doing automagic generation won't fully absolve us from some custom logic).
Ahh, I didn't look closely enough for those specific fixes requiring custom coding.
Looking at the sets-xxx.js, it seems this should be able to be generated on the fly and not require hard coding. The main point seems to generate the booster pack content. Scryfall doesn’t offer this data but this site does:
docs.magicthegathering.io
There is a JS api for this site: mtg-sdk-javascript
{ "set":{ "code":"KTK", "name":"Khans of Tarkir", "type":"expansion", "border":"black", "mkm_id":1495, "booster":[ [ "rare", "mythic rare" ], "uncommon", "uncommon", "uncommon", "common", "common", "common", "common", "common", "common", "common", "common", "common", "common", "land", "marketing" ], "mkm_name":"Khans of Tarkir", "releaseDate":"2014-09-26", "magicCardsInfoCode":"ktk", "block":"Khans of Tarkir" } }
This should be readily parsed into the existing data forms.
Should this be persisted in our firebase store, or just st generated on first call? The overhead should be tiny thus storing might be overkill.