intra-martのロジックをTypeScriptで書くメリット

まとめ

何がいいの?

・プレーンなJavaScriptでは得られない型のサポートを受けれるのでビジネスプロセスを取り扱うintra-martと相性がいい

・スクリプト開発では速度を出したい時や小さなモジュールが多いけれど、後の人用に型とかの定義を残してバグの発生をはじく

反論

Javaで書いたらいいやん

→ 仰る通りです…この辺りは改修案件なのかスクラッチで開発するのか、人員のスキルセットによりそうなので案件によって違いそう。

 ただ、スクリプト開発はRhinoというエンジンでJavaに変換しているのでJSの対応バージョンが良くてES5、ちょっと古いとES3なんですよね。BabelやTS純正のポリフィル、トランスコンパイラが導入されることが望ましいと思います。

参考 Which JavaScript (ECMAScript) version does Java’s Rhino implementation implement (and what’s the update policy?)

 

 そうなってくると型付きのTS入れたらええやん!ってなります。

フレームワーク特有の関数でエラーが出るやん

→ そうなんです…もうintra-mart.d.tsをプロジェクト間で共有してインポートするしかないかなぁと思っています。公式から出ないかなぁ(チラッチラッ

ESLintの定義はあるんで、@type/intra-martも出ると信じています。

導入

Node.js入れる

Node.jsを取ってくる。

VSCode入れる。

TypeScriptといえばVSCode。軽いしオススメ。

eBuilderは.tsはプレーンなファイルとして認識するのでエディタの支援は受けれない。

npm初期化する

プロジェクトルートでCLIで

npm init

をする。

拘りなければ全部エンターでいい。

TypeScript入れる。

CLIで

npm i -g typescript

ファイルを.jsから.tsに変更する。

型のみ利用する場合はトランスコンパイル後に元のjsファイルに戻る。

エラーがいっぱい出るので型を定義したりする。

イントラマート固有の定義はi-mart.d.tsに定義してインポートしてる。

/// <reference path=”i-mart.d.ts” />

コンパイルする。

CLI上で

tsc tsファイルパス

で同じディレクトリにts→jsファイルにトランスコンパイルされる。

 

動いた! you win

型使っていこう!

シェアする

  • このエントリーをはてなブックマークに追加

フォローする