Lycolog

検索条件

タグで絞り込み Node.js(1) Node.js::Jest(1) ジャンル::思考(1) ジャンル::調査(3) ライブラリ(1) ライブラリ::React(1) 言語::JavaScript(1) 言語::JavaScript::CommonJS(1) 言語::JavaScript::ES Module(1) 開発(1) 開発::テスト(1)

日付で絞り込み 2021年(1) 2022年(1) 2023年(1) 2024年(1)

全4件 (1/1ページ) 一覧表示に切り替え記事本文を表示

お知らせ

現在サイトのリニューアル作業中のため、全体的にページの表示が乱れています。

ここ最近TypeScriptを書いている理由を考えてみる

投稿日：: 2024/05/04

言語::TypeScriptジャンル::思考

ここ5年間くらいTypeScriptを書くことが多いが、何故TypeScriptで書いているかについてメリデメを大まかに整理してみる。

メリットに感じている部分

静的型付けがある
- IDEで入力保管が出るのは便利だし、型ミスによるバグも見つけやすい
マルチプラットフォーム
- OSの差を意識せず開発しやすい
VSCodeで書きやすい
- IntelliJ使いたくないので…
テストコードを書くのが楽
- Jestは扱いやすい
大抵のことができる
- CLIアプリからWebサーバー、Webフロントエンドまでこれ一本でできるのは嬉しい

デメリットに感じている部分

依存地獄
- node_modules配下が地獄になりがち
Node.jsの頻繁なバージョンアップ
- TypeScriptはNode.jsに依存しているため、どうしてもこの部分に引っ張られがち（DenoとかBunとかそういうのは関知しない）
  - fsを中心に破壊的変更がよくあり、割合壊れる
デバッグがめんどくさい
- C#だとデバッガを上げるのは楽だがNode.jsはめんどくさい
- たまに素直にブレークポイントにはまってくれないこともあり辛い
言語エンジンが重い
- 入力補完や型情報の照会などはコードが肥大化するにつれ重くなる
- そのためにキャッシュ機能があるようだが、ブランチを切り替えるとキャッシュされた型情報を見てくるせいでうまく動かないなど面倒

コメント（0件）

swc/jestでESM, CJS混在のコードをJestを使ってテストする有力な方法は今のところ多分ない

投稿日：: 2023/10/11

言語::TypeScript言語::JavaScript::CommonJS言語::JavaScript::ES ModuleNode.js::Jest開発::テストジャンル::調査

ESM化が叫ばれて久しいですが、未だにJestはESMとCJSが混在したコードを処理してくれません。

Getting StartedにもSWCに対する言及がないので、きっともう忘れられているのでしょう。swc-project/jestの方も特にやる気はなさそうだし、やりたければ自分でPR書きましょうって感じだと思います。きっと。

確認環境

node_modules配下にESMで作られたモジュールが存在し、コードはTypeScript、トランスパイルにはSWCを利用する。

Env	Ver
@swc/cli	0.1.62
@swc/core	1.3.92
@swc/jest	0.2.29
@swc/register	0.1.10
jest	29.7.0
typescript	5.2.2

やったけど意味がなかったこと

package.jsonのtypeをmoduleにする
jest.config.jsのtransformIgnorePatternsにESMモジュールのパスだけ除外する設定を書く
上記に加えてtransform.jsc.pathにpkg-name: ['node_modules/pkg-name']を追記する
node --experimental-vm-modules node_modules/jest/bin/jest.jsで実行する
- 多少マシになったがコケるものはコケる
ESMで書かれたモジュールを丸ごとモックする
- 一切効果なし

所感

多分Webpackでバンドルしてnode_modulesの中身も外も関係ない状態にするのが一番無難なのではないかと思いました。

Node.jsの組み込みテストランナーにすれば解決するかな？と思ったものの、こちらは現状SWCでは使えそうにないので諦めました。
参考までに以下のコマンドで走らさせられます。

node --require @swc/register --test ./src/**/*.spec.ts

取り敢えずESMに引っかったモジュールはCJS時のバージョンを維持しておくことにしましたが、このままだとSWC使えないし、なんとかなって欲しいですね。Webpack使えば解決できるのはわかるんですが、このために使いたくないので、テストを重視する場合、Vitestを持つViteが有力候補になって来そうです。

2024-02-17追記

esbuild + Node.js built-in test runnerの組み合わせであればテストはできるが肝心の実行ができず無意味だった

コメント（0件）

TypeScriptの型推論の穴についてのメモ

投稿日：: 2022/02/13

言語::TypeScriptジャンル::調査

TypeScriptをぼちぼちやってきた中で、型推論が素直に決まらないみたいな所が出てきたので書き置きとして残しておきます
具体的には何かしらの関数を通して処理を隠蔽すると上手くいかなくなるケースがあります

型が推論されないケース

検査関数的なものを通した場合に、後続処理で期待通り型が推論されなくなるケースです

その1

type HogePiyo = 'hoge' | 'piyo';

type InputProps<ValueT> = {
  value: ValueT;
  error: string;
};

const required = (val: string) => {
  return val === '';
};

const registerHogePiyo = (value: HogePiyo) => {
  console.log('register', value);
};

const input: InputProps<HogePiyo | ''> = {
  value: '',
  error: '',
};

if (required(input.value)) {
  input.error = 'ERR';
  console.error(input.error);
} else {
  // ここでは input.value は 'hoge' | 'piyo' となるはずだが
  // TSC は 'hoge' | 'piyo' | '' と解釈する
  registerHogePiyo(input.value);
}

その 2

type HogePiyo = 'hoge' | 'piyo';

type InputProps<ValueT> = {
  value: ValueT;
  error: string;
  hasError: boolean;
};

const required = <ValueT>(obj: InputProps<ValueT | ''>) => {
  if (obj.value === '') {
    return { value: '', error: '必須入力です', hasError: true };
  } else {
    return { value: obj.value, error: '', hasError: false };
  }
};

const registerHogePiyo = (value: HogePiyo) => {
  console.log('register', value);
};

const input: InputProps<HogePiyo | ''> = {
  value: '',
  error: '',
  hasError: false,
};

const result = required(input);
if (result.hasError) {
  console.error(result.error);
} else {
  // ここでは input.value は 'hoge' | 'piyo' となるはずだが
  // TSC は 'hoge' | 'piyo' | '' と解釈する
  registerHogePiyo(result.value);
}

export {};

型を推論されるようにしたケース

オブジェクトに型判定用のプロパティを生やしasで型を明示することでクリアしています

type HogePiyo = 'hoge' | 'piyo';

type InputProps<ValueT> = {
  value: ValueT;
  error: string;
  hasError: boolean;
};

const required = <ValueT>(obj: InputProps<ValueT | ''>) => {
  if (obj.value === '') {
    return { value: '', error: '必須入力です', hasError: true } as {
      value: '';
      error: string;
      hasError: true;
    };
  } else {
    return { value: obj.value, error: '', hasError: false } as {
      value: ValueT;
      error: string;
      hasError: false;
    };
  }
};

const registerHogePiyo = (value: HogePiyo) => {
  console.log('register', value);
};

const input: InputProps<HogePiyo | ''> = {
  value: '',
  error: '',
  hasError: false,
};

const result = required(input);
if (result.hasError) {
  console.error(input.error);
} else {
  registerHogePiyo(result.value);
}

export {};

あとがき

Assertion Functionsを使う方法もあると思いますが、何も考えずAssertion Functionsを書くと次のような弊害があり、積極的に採用しづらいと考えています
- 何もしていなければ基本的にバンドル後のソースコードに出てくる
  - 要するにバンドルサイズが大きくなります
- throwを書く必要性があり、バンドル後に残っている以上、このthrowをcatchする必要性がある
  - 無意味な実装工数が生まれる
- そもそも論としてAssertion Functionsを書く工数が生まれる
- Assertion Functionsの振る舞いを見ている限り、asに限りなく近く、ぶっちゃけasで書いたほうが楽
絶対にasを使わず現実的な工数で開発するというのは、割と非現実ではないかという感触があります
- 個人的に型推論はIDEが勝手にやってくれるおかげで楽ができるシステムだと考えているので、型推論の補佐をする仕組みに工数をかけるというのは本末転倒な気がしています
品質は大切なことですが、反面で少なくないビジネスには期限もあります
- 品質に寄せすぎた過剰に冗長なコードも、納期に寄せすぎた脆弱性不具合山盛りスパゲティコードもどちらも考えものであり、その辺のバランスが上手くとれるやり方がなんかないかなーと考えることはしばしばあります

コメント（0件）

Reactでのページ間データ保持について

投稿日：: 2021/04/24

ライブラリ::React言語::TypeScriptジャンル::調査

ReactでSPAを組んでいてブラウザバックしたときのフォームの入力内容が消し飛んで気になったので、ブラウザバックした時にどうなるのかというのを軽く調査した結果

確認したパターンとしては次の2つ

フォームの入力値をDOMに保持させるステートレスな方式
フォームの入力値をJSに保持させるステートフルな方式

LocalStorageに画面情報を保存して復元するとか、条件分岐を使ってDOMを隠して保持させるとか、そういう系は考慮しない

結果

	DOM 保持	JS 保持
SPA 内ブラウザバック	消える	保持される
SPA 外ブラウザバック	保持される	消える
コード記述量	少ない	多い

Env	Ver
react	17.0.2
react-dom	17.0.2
react-router-dom	5.2.0

1. フォームの入力値をDOMに保持させるステートレスな方式

大正義ステートレスです
Function Componentはステートレスなので、こうあってほしいですよね～
コードもシンプルで管理しやすいのが素敵なところです

export const StatelessPage = () => {
  const history = useHistory();
  return (
    <div>
      <form>
        <input type="text" />
        <button onClick={() => history.push(AppRoute.dom2.path)}>submit</button>
      </form>
    </div>
  );
};

2. フォームの入力値をJSに保持させるステートフルな方式

ギルティなステートフル方式です
Class Componentを捨てたはずなのにどうしてこうなった…
コードが煩雑で管理が大変です

export const StatefullPage = () => {
  const ctx = useContext(ExampleContext);
  const history = useHistory();
  const onChange = (ev: React.ChangeEvent<HTMLInputElement>) => {
    ctx.text = ev.target.value;
  };

  return (
    <div>
      <form>
        <input
          type="text"
          defaultValue={ctx.text}
          onChange={(ev) => onChange(ev)}
        />
        <button onClick={() => history.push(AppRoute.ctx2.path)}>submit</button>
      </form>
    </div>
  );
};

コメント（0件）