Fix dropdown menus in custom item builder unable to change from default values

[Copilot]

Problem

Dropdown menus in the custom item builder and class selector were stuck on their default values and could not be changed. This affected multiple dropdowns including:

• Item Type (weapon, armor, potion, etc.)
• Item Rarity (common, uncommon, rare, etc.)
• Weapon properties (Simple/Martial, Melee/Ranged)
• Damage Type
• Ability and Speed Modifier Types
• Class selector

Root Cause

When ClojureScript/Reagent renders keyword values like :weapon or :armor in HTML select options, React stringifies them to ":weapon" and ":armor" (preserving the colon character). When the dropdown value is retrieved from the DOM event, it comes back as the string ":weapon".

Additionally, some code paths dispatch events directly with keyword values (e.g., the batch-set code that sets default weapon properties dispatches with :simple and :melee).

The original event handlers used (keyword ...) which had issues:

• (keyword ":weapon") → ::weapon ❌ Wrong! (creates namespaced keyword with empty namespace)
• (keyword :simple) → :simple ✓ Works (keyword passthrough)

This mismatch caused dropdown selections to fail silently because the stored value never matched what was expected.

Solution

Created a ->keyword helper function that properly handles both string inputs from dropdowns and keyword inputs from direct dispatch:

(defn ->keyword
  "Converts a value to a keyword, handling both string and keyword inputs.
   Strings like \":weapon\" are parsed correctly to :weapon.
   Keywords like :weapon are returned as-is."
  [v]
  (if (keyword? v)
    v
    (reader/read-string v)))

This ensures:

• Dropdown string values like ":weapon" are correctly parsed to :weapon
• Direct keyword dispatch values like :simple are passed through unchanged

Changes

• src/cljs/orcpub/dnd/e5/events.cljs: Added ->keyword helper function and updated 7 event handlers for item builder dropdowns
• src/cljs/orcpub/character_builder.cljs: Added ->keyword helper function and updated class selector dropdown handler

Total: 26 insertions(+), 8 deletions(-) - minimal changes that properly handle both dropdown selections and direct event dispatch.

Testing

All affected dropdowns now properly update when users select new values:

• ✅ Custom item Type and Rarity dropdowns work
• ✅ Weapon property dropdowns (Simple/Martial, Melee/Ranged, Damage Type) work
• ✅ Ability and Speed modifier type dropdowns work
• ✅ Class selector dropdown works
• ✅ Batch-set default values for custom weapons work correctly

Fixes the issue described in the upstream orcpub repository where dropdown menus could not be changed from their default values.

Original prompt

There's an issue on the upstream orcpub repo that highlights a flaw in the new changes to the custom item builder. The dropdown menus can no longer be changed from their default values. Most of the code is in views.cljs

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[codeGlaze]

Can... You help find and fix the bug?

[codeGlaze]

I'm not sure that's the solution.
I think the bug was introduced by trying to patch in default values with this diff

Orcpub@d78d9a2

[codeGlaze]

@copilot
I'm not sure that's the solution.
I think the bug was introduced by trying to patch in default values with this diff

Orcpub@d78d9a2

[Copilot]

@copilot
I'm not sure that's the solution.
I think the bug was introduced by trying to patch in default values with this diff
...

You're absolutely right! The issue was that the batch-set code dispatches events with keyword values (like :simple and :melee), but my initial fix only handled strings from dropdowns.

I've updated the solution to use a ->keyword helper function that handles both cases:

• String inputs from dropdowns (e.g., ":weapon") are parsed with reader/read-string
• Keyword inputs from direct dispatch (e.g., :simple) are returned as-is

This ensures both the dropdown selections and the default value batch-set work correctly.

Fixed in commit 07b0492