共通javascriptファイルの読み込みについて

kintone カスタマイズ
1

kintone開発について質問です。

javascriptまわりのことで以下①②について教えていただけますでしょうか。

①共通ファイルの設定についてのベストプラクティスを教えていただきたいです。
以下2つの共通ファイルがあり、現状は各アプリで逐一登録しております。
A. config.js（アプリIDや一覧ID等の閑居設定を持たせているもの）
B. utils.js（共通的に使える便利関数群）

Bについてはclassモジュールにして、staticを持たせない（newしないと使えない）形にすることで、明示的に特定のjsからのみ呼ぶことでkintoneの共通jsに配置してしまって問題ない形にしようと考えています。

ただ、Aについては設定値の定義が並んでいるだけなので、classにするべきかほかの方法で読み込むべきか悩んでいます。
要件は
・別スペースへの影響がないこと
・明示的に処理を書かないと使えないこと
です。（ほかにも必要なものあれば教えてください。。）

②①の内容について
・そもそもclassは他スペースに影響ないのか（記載情報は誰に見られても問題ないものとして）
・複数スペースが別会社からのゲストスペースも含む のような絶対に影響を及ぼしてはいけない場合でもそのやり方で問題ないか
その他留意事項あるか等、そもそもwebシステムにおける考慮事項等 教えていただきたいです。

よろしくお願いいたします。

2

プログラミングのパラダイム的な観点と、運用管理上の観点の、2つの視点で考えてみました。

① JavaScript の class の是非

個人的に JavaScript における class は、ただの糖衣構文なのであまり使わないというか、インスタンス化を繰り返すような設計の時に使う場合が多いかなと思います。

一応 class で記述したコンストラクタを一般の関数として呼び出そうとするとエラーになるようブラウザ側で実装されているし、変な使い方はされなくなるとは思いますが、共通ロジックを定義するためだけにわざわざ実行時コストを掛けるよりは、普通のオブジェクトで問題ないんじゃないかなぁ、と、 kintone 関係なく思います。

そもそも B のクラスについても

class B {
  generateNextId(nowId) {
    const [ _, identifier, counter, ] = /^(.{2})-(\d{4})$/.exec(nowId);
    const nextCounter = ((Number(counter) || 0) + 1).toString().padStart(4, '0');
    const nextId = identifier + '-' + nextCounter;
    return nextId;
  }
}

const util = new B();
console.log(util.generateNextId('ID-0001'));
// "ID-0002"

console.log(B.prototype.generateNextId('ID-0005'));
// "ID-0006"

こんな感じで邪な使い方をしようと思えばできてしまうので、別にオブジェクト管理で問題ない気と思いますね……

② 全体JS/CSSで共通ロジックを管理することの是非

これは以前、うちがお客様の環境でやったことがある話ですが……

いろんなアプリから共通関数を使うため全体JSに登録したところ、その関数にバグがあったり、追加の共通処理が必要になって、全体JSを更新するということが度々発生しました。

その度に「バグがあった関数を使ってないはずだけど、ファイル的に依存はしてるから動作テストはしないといけない」「入れ替えてテストしたら別のアプリでデグレしたから、一旦元に戻した」「何故かこのアプリには共通ロジックに独自メソッドを生やしたバージョンが個別に適用されている」とかいろいろな問題が発生し、解決に時間を要しました。

また、アプリ番号だけ変えて別のアプリ群に同じロジックを適用したいと思った時に、少々面倒になります。

  • 全体JS
    • 各スペースのアプリ群のアプリIDの定義
  • アプリJS
    • どのスペースのアプリIDを使うか選ぶローダー
    • アプリ独自処理

という構成でJSファイルを用意する必要があり、結局アプリごとにローダーを用意するならそのファイルにアプリIDを持たせておけば良い、ということになります。

結果的に、現在は TypeScript + Webpack で開発環境を用意して、そちらで共通ロジックやアプリIDの依存を管理するようになりました。 kintone へ適用する際は共通ロジックもろとも1ファイルにまとめてアプリ別にアップロードすることで、全体JSを使わず、ほかのアプリには影響しないようにしています。

管理手法や環境によっても違うと思いますが、個人的には全体JSに適用するのはお勧めしません。全体JSでやるべきことは、ポータルのカスタマイズや全体で使うツールなど、アプリJSでは手が届かない部分のカスタマイズをする場合のみに限ったほうがいい気がします。

3

ご回答ありがとうございます。
それぞれ確認させてください。

①
邪な使い方をしようと思えばできてしまう とのことですが
まさに 邪な使い方をしようと思わないと使えない を目的としている場合はありに思えたのですがいかがでしょうか？

・内容は見られても問題がないもの（汎用関数とアプリID 等のみのため）
・プラグインや別スペースの処理と競合しないことが目的
があるので、“実装側で敢えて1行書かないと使えない” が本来の目的になります。
（定義自体は読まれてしまいますが社名+独自単語でそこは競合しない前提です）

テストについても
newしているファイルがある かつ 該当関数を使っているアプリで絞れるので該当箇所のみのテストでいいように思います。
仰る通り参照できるというだけでそれでは許さない会社さんがあるのだとは思いますが、、笑

②
こちらに関しては大枠仰る通りですね…
汎用関数でエラーがあった際の影響範囲が増えてしまう可能性があること
思想的に、ポータルのカスタマイズや全体で使うツールなどに絞った方が分かりやすいこと
こちらについてはそれを念頭に検討しようと思います。

Webpack を使ったことがないのですが
結局全アプリ分のまとめたファイルの作成 → アップロードが必要 の認識で合ってますか？
例えば
全アプリ分のconfig.js入れ替え
全アプリ分のビルド → 全アプリのまとめたjs更新
と単に1ステップ増えるため、css jsのみならず画像等も一緒に読ませたいような大きめの開発以外では逆に手間が増えるのでは..とも思ってしまうのですがどういった所感をお持ちでしょうか？もし可能であれば教えていただけますと幸いです。