◆ enum 値を変数を通して引数に渡す必要はあるのか
  ◆ 動的言語だと一括置換も難しいし 計算して作る事も考えると全部見ていくことになる
  ◆ 引数に文字列そのままでも大差ない
  ◆ 変数名そのままで中身だけ変えるは個人的にナシ
  ◆ そもそも標準機能自体が 変数に入った値ではなく文字列渡すものにシフトしてきてる
◆ 変数に入れた場合 数値にするか文字列にするか
  ◆ 1 とか 8 とかを直接渡すのはさすがにありえないので変数に入れる場合
  ◆ 今の言語だと文字列も数値と同じように渡せる
  ◆ ビットフラグ時以外は文字列のほうがわかりやすい
  ◆ ビットフラグはオブジェクトでキーに対して true/false のほうがわかりやすい

C# など静的言語の場合は一括変換できたりメリットが大きいので enum 型があるなら使ったほうが良いと思います
しかし 動的な言語の JavaScript で必要なのかと考えるとあんまりメリットはないように思いました

実際 JavaScript では昔からあるものは enum 値のような使い方をしていますが 比較的最近はそのまま文字列で渡す事が多いです
例えば Node.ELEMENT_NODE には 1 という値が入っていて

document.body.nodeType === Node.ELEMENT_NODE
// true

という風に使います
TreeWalker にノードの種類の条件としてこの enum 値を渡すなどもあります

新しめのものだと IndexedDB のモードに文字列でモード名を渡したり

db.transaction("foo", "readwrite")

ShadowDOM のモードに文字列でモード名を渡したりします

document.body.attachShadow({mode: "open"})

どの機能だったかは覚えてないのですが 仕様がドラフト時には enum 値を変数に用意されていてそれを渡す方針だったものが 正式なものになるときには単純に文字列で渡すようになってました
そういうこともあるので JavaScript だと enum として使うものは数値が入った変数で渡すより固定文字列を渡すのが一般的かと思います

ShadowDOM の例で わざわざこういう事する人はいないんじゃないでしょうか

// 定数置き場
const SHADOW_DOM_MODE_OPEN = "open"
const SHADOW_DOM_MODE_CLOED = "closed"

// 使う場所
document.body.attachShadow({mode: SHADOW_DOM_MODE_OPEN})

少なくとも私は見た覚えはないです
静的言語などこういう書き方になれてる人だとするのかもしれません

わざわざこういうことするメリットは

  • 文字列の書き間違えが減る
  • 一括で名前の変換ができる

だと思います

ただ JavaScript の場合は静的言語ではないので 変数名が間違っていてもコンパイル時チェックなんてないです
実行時エラーなので 文字列にしていても対して代わりありません
TypeScript だとメリットあるのかも(使ってないのでわからないです)

一括変換は C# を VisualStudio で書いてるときにはすごく助かる機能です
ですがこれも JavaScript だと難しいところもあり エディタによってはある程度できますが動的に読むファイル中だったりサーバから埋め込んで出力する部分だったり 完全にすべてを把握して変換するのは難しいです

結局全体検索して 1 つずつ確認していくのが一番安全になるので それなら文字列であっても変数であっても変わりません
特に JavaScript などでは文字列結合など処理した結果として enum 値を取得することが少なからずあるので単純な検索だけでは全て変更できた保証もなくどちらにしても手間はかかります

一応変数を通した場合は 変数名は変えずに中の値だけ変えることはできます
仮に open だったのが active に変えないといけなくなったとします

// old
const OPEN = "open"

// new
const OPEN = "active"

これで動くといえば動きます
ただ 個人的にはこれがすごく嫌いで 中身と変数名が一致しなくなるなら全箇所直すべきと考えてます
変数名の OPEN を ACTIVE にして OPEN の使用箇所は全部 ACTIVE にします
変数名をただの記号としか考えてない人もいますが 変数名だけで読めるべきだと思うので 変数名とその中身が一致しないのはありえません
この場合だと OPEN って値を渡しているけどこれって中身 active なの?と思ってわざわざ確認しないといけないです
ヒドイ場合はいろいろな経緯があったらしく意味が反対になってるにもかかわらず変数名はそのままなのでコードだけみると意味不明でどう見てもバグってそうです
なのになぜか動いてるので読むのが一苦労になります

それを全く気にしないのであれば変数にしておくのもありかもしれませんが むしろそういうことをさせないためにも直接文字列書いたほうが良いとも思います



それともうひとつ 自分で作る enum 値を変数に入れたとして数値にするか文字列にするかというのも考えが分かれると思います

// 文字列
const OPEN = "open"

// 数値
const OPEN = 1

こういうのです
関数など enum 値を受け取る側で実体の型を何にするかです
古めの言語やってた人は数値一択な人が多いと思います

C だと基本は数値なので文字列を渡すのはポインタとか入ってきて一苦労なので単純な数値になるのはわかります
ですが 最近の高機能な言語では文字列はそのまま渡すことができて数値を渡すのと違いなく扱えます

そうなると わかりづらい数値より文字列を実体にしたほうが便利です
デバッグ時に今の値を見たときに文字列でそのままモード名などが見えるととてもわかり易いです
それが 1 とか 4 とかが表示されても毎回それの意味を調べる必要があって不便です
言語組み込みのものだけならともかく アプリケーション固有の値まで全部覚えるなんてやってられないですからね

とは言っても 数値型にしたほうが良いケースもあります
複数の機能の ON/OFF の組み合わせなど ビットフラグとして扱う場合です

ABCD の 4 つの機能があって A を有効にするなら 1 (0001) B を有効にするなら 2 (0010) C なら 4 (0100) D なら 8 (1000) と設定して A と C なら 1 と 4 なので 5 (0011) 全部なら 15 (1111) となります
それぞれ 1 ビットで表現して組み合わせることで 4 ビットで表せます

ただ これも最近の動的な言語だとあまり見なくなってきてる気がします
簡単にキーバリューのペアをその場で簡単に作れますし 複数渡して複数返すというのも当たり前です
そうなると わかりやすさを優先してオブジェクトや連想配列やディクショナリでキー名に対する true/false を書くほうが一般的に思います

こう考えると enum 値の仕組みって昔の限られた言語機能やマシンスペックで効率よく動かすために考えられたものって感じがしますね
それらが十分にある今ではわかりやすさ重視にするには特に使わなくてもいいように思います