meta-issue: technical debt

[rsek]

since many of these touch the same files, here's an overview of tasks to improve code readability, semantics, or otherwise improve dev QoL without user-facing changes to appearance or basic functionality :) alternatively/additionally, i could open issues for all the ones that don't have an issue already; that might benefit from some appropriate tags/labels, though.

is there anything i've missed, or that bears adding to the wishlist?

• standardize formatting + its configuration: format all files #377
• migrate to FVTT v9 types: Dependency update (FVTT types v9, etc) #392
• update other dependencies: Dependency update (FVTT types v9, etc) #392
• where practical, migrate to typescript
  • build scripts? on one hand, handy to just have 'em ready to run without getting ts-node involved. on the other, they're complex enough that typings might save some grief
  • SFCs. this requires stricter tsconfig options (like noImplicitAny and noImplicitThis) that will require rewrites of significant chunks of code.
    • one of the biggest offenders here is handlebars' helper function registrations.... but we might be able to trim those out, see the next item
• where possible, do complex composition in Vue rather than in Handlebars, with handlebars acting mainly as a wrapper; having to track functionality across multiple files isn't ideal - SSoT, and all that
  • many ironsworn-specific sheets suffer from this; revist them once more component refactors are complete
• rewrite HTML for improved semantics + accessibility
  • all widgets should have implicit or explicit role attributes. this has the handy side effect of making the code easier to parse
  • descriptive, meaningful class names for html elements
  • where practical, prefer pre-existing HTML attributes over component methods or DOM manipulation. examples:
    • .disabled class + prevent click events w/ component method =>disabled=true and/or aria-disabled=true
    • prevent submit events with <button> w/ component method => use type=button on <button> so it doesn't default to type=submit
  • prefer CSS grid for grid-like layouts that currently rely on nested div.flexcol/div.flexrow
  • prefer CSS styling over HTML elements that have defined semantics but are being used presentationally. examples:
    • <hr> => CSS margin-* properties or :before pseudo-elements
    • <button><i class="fa-icon">[...]></button> decorator => CSS button:before pseudo-element containing icon
  • full keyboard accessibility
    • investigate a vue library to manage keybindings
    • investigate a vue library to manage focus
    • figure out how all this is going to interact with FVTT's native keybinding
  • investigate using SVG icons over icon fonts
• rewrite CSS for better modularity + easier retheming
  • prefer relative units (rem, em) over static px where practical
  • remove all inline HTML style elements; prefer descriptively-named classes instead, but still keep component-specific CSS encapsulated in the relevant component file
  • standardize CSS variables across all themes - underway in Style-sheet-vars #490
  • decouple layout/positioning from other styling concerns (typography, color + other decorative elements, etc)
• standardize Vue components to provide an readily-maintainable, modular set of building blocks for future expansion
  • rule of thumb: if a design pattern is (or is likely to be) used more than once, consider making it a component
  • i've got drafts of most of these on a general purpose semantic components branch already, but i'll be reworking them so that each can be its own, more-readily-reviewable PR instead of one monster PR
    • Buttons: Standardize + improve semantics of buttons #390
      • there's a couple straggler buttons that might bear standardizing with the same patterns, like "delete item", but the PR above was already huge - i'll circle back to them when i work on progress items specifically
    • Tabs: Tab components #396
    • condition meters and other slider-type components: New resource bar components w/ keyboard controls #501
    • progress tracks: Fancy progress #486
    • number spinners (e.g. stat widget)
    • xp tracks (particularly the 'classic' one)
    • simple collapsibles (e.g. completed progress items, asset items)
    • complex collapsibles (e.g. oracle tree, move tree)
    • plain text inputs like <textarea> and <input type=text> (e.g. character vitals)
    • any "building-block" components that i've forgotten above
    • widgets composed of the components above
    • pages composed of the widgets above