refactor(uniformbuilder): centralize award/MOS constants and data-drive the registry#130
Draft
JensGryspeert wants to merge 3 commits into
Draft
Conversation
JensGryspeert
force-pushed
the
refactor/constants-ribbons-awards-mos-to-enums
branch
2 times, most recently
from
abb9add to
7cdbbfd
Compare
Collaborator
Author
|
I've placed the PR in a draft to see if it's something that @Vercin-G wants or not. I do think it simplifies a bit of reading in the code. |
Collaborator
|
Will review after break. Need to do testing on this, but initial look throughs are promising |
Collaborator
|
@JensGryspeert this was affected by a number of changes that were pushed yesterday, in particular some further changes to the 155F. No rush but if you could review against main and see what still applies. |
added 3 commits
June 5, 2026 09:35
Introduce a constants/ module as the single source of truth for award types, ribbon attachment types (with their max-count map), MOS codes and groupings, and reused award-name fragments. Add an ordered AWARD_CATALOG data table plus hasValorDevice/stripValorDevice helpers. Unused until the consumers adopt it in the following commit.
…lify Replace duplicated award-type, attachment-type and MOS string literals across AwardRegistry, AwardClasses, getCanvasObject and GetUserInfo with references to the constants module. AwardRegistry now builds its Map by looping AWARD_CATALOG instead of ~100 imperative set() calls. Collapse the aviation/medical MOS if-chains to MosGroup membership checks and the MOS switches to enum cases. Route the valor-device strip through shared helpers and drop dead branches, redundant boolean comparisons and debug logging. MosGroup encodes the post-7Cav#129 aviation behavior: AVIATION includes 155F and AIRCREW is [15T] only, so 155F resolves to regular aviator wings. Behavior-preserving: enum values equal the original literals, catalog order and values match, and getMaxAwardCount returns the same numbers.
Rename the Mos enum keys from M<code> to the official S1 MOS titles from the 7cav wiki (e.g. ARMOR_CREWMAN: "19K", COMBAT_MEDIC: "68W"). Values stay the exact code strings, so all switch cases and membership checks are unchanged. S2 keeps three entries: S2_OFFICER (35A), S2_NCO (35B) and S2_ENLISTED (35F). 35F is added from the wiki list (no consumer yet, so inert); 35B is retained because the roster still uses it. Behavior-identical: every MOS-to-role mapping and the aviation badge logic resolve to the same codes as before.
JensGryspeert
force-pushed
the
refactor/constants-ribbons-awards-mos-to-enums
branch
from
7cdbbfd to
2b966c0
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Removes duplicated award-type, ribbon-attachment-type and MOS string literals scattered across the uniform-builder modules by introducing a single
constants/module, and turns the award registry into a data-driven loop.New
client/app/uniformbuilder/modules/constants/awardTypes.js—AwardTypetaxonomy (values equal the award class names)awardAttachmentTypes.js—AwardAttachmentType+MAX_AWARD_COUNT(the per-device max count, previously trapped in a switch)mos.js—Moscodes +MosGroupsets (aviation / medical / aircrew)awardNames.js— reused name fragments +hasValorDevice/stripValorDevicehelpersawardCatalog.js— orderedAWARD_CATALOGdata tableindex.js— barrelConsumers
AwardRegistrybuilds its Map by loopingAWARD_CATALOGinstead of ~100 imperativeset()calls;getMaxAwardCountis now a map lookup.AwardClasses,getCanvasObject,GetUserInforeference the enums; aviation/medical MOS if-chains becomeMosGroupmembership checks; MOS switches use enum cases.Behavior
Pure refactor, no behavior change. Enum values equal the original literals, catalog order and values match the old registry exactly, and
getMaxAwardCountreturns the same numbers. Adding or editing an award is now a one-line entry inawardCatalog.js.