0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@DaokFrontier

TypeScript 5.xで進化！イミュータブル実装を堅牢にする3つの秘訣

0
Posted at

多くのTypeScript開発者が「デコレーター」と聞いて、かつての--experimentalDecoratorsフラグと不安定な仕様を思い浮かべるかもしれません。しかし、TypeScript 5.xでデコレーターはECMAScript標準機能として生まれ変わり、その型安全性と堅牢性は飛躍的に向上しました。これを知らないまま古い知識でいると、現代のTypeScriptプロジェクト、特にReduxを用いたイミュータブルな状態管理で思わぬバグやパフォーマンス劣化に繋がる可能性があります。

この記事では、TypeScript 5.xの新しいデコレーターと、Reduxにおけるイミュータブルなデータ操作を組み合わせることで、アプリケーションのバグを削減し、再レンダリングを最適化し、そして保守性を向上させる3つの秘訣を、具体的なコード例と共に解説します。

TypeScript 5.xにおけるデコレーターの進化と基本

このセクションでは、TypeScript 5.xで標準化されたデコレーターの基本と、以前の実験的なデコレーターとの決定的な違いを理解します。

--experimentalDecoratorsは過去のものに

TypeScript 5.0以降、デコレーターはECMAScriptのStage 3プロポーザルに準拠した標準機能として実装されました。これは、もはやtsconfig.jsonで"experimentalDecorators": trueを設定する必要がないことを意味します。この変更により、デコレーターはより予測可能で型安全な形で利用できるようになりました。

tsconfig.json の設定例 (TypeScript 5.0以降)

{
  "compilerOptions": {
    "target": "ES2022", // またはそれ以降
    "module": "ESNext",
    "strict": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "skipLibCheck": true
    // "experimentalDecorators": true は不要！
  }
}

新しいデコレーターAPIのシグネチャ

TypeScript 5.xのデコレーターは、以前のバージョンとは異なるAPIシグネチャを持っています。特に重要なのは、デコレーター関数が第2引数としてcontextオブジェクトを受け取る点です。このcontextオブジェクトには、デコレーターが適用される対象の種類（kind）、名前（name）、およびデコレーター間で共有されるメタデータ（metadata）などの情報が含まれます。

メソッドデコレーターを例に、新しいAPIを見てみましょう。

秘訣1: メソッドの振る舞いを安全に拡張するデコレーター

メソッドの呼び出し前後にログを出力するデコレーターを実装してみます。これにより、関心事を分離し、横断的なロギング処理を簡潔に記述できます。

// logMethod.ts
function logMethod<T, A extends any[], R>(
  originalMethod: (this: T, ...args: A) => R,
  context: ClassMethodDecoratorContext<T, (this: T, ...args: A) => R>
) {
  const methodName = String(context.name);
  return function (this: T, ...args: A): R {
    console.log(`LOG: Entering method '${methodName}' with arguments:`, args);
    const result = originalMethod.apply(this, args);
    console.log(`LOG: Exiting method '${methodName}' with result:`, result);
    return result;
  };
}

class Calculator {
  @logMethod
  add(a: number, b: number): number {
    return a + b;
  }

  @logMethod
  subtract(a: number, b: number): number {
    return a - b;
  }
}

const calc = new Calculator();
calc.add(5, 3);
calc.subtract(10, 4);

実行結果例

LOG: Entering method 'add' with arguments: [ 5, 3 ]
LOG: Exiting method 'add' with result: 8
LOG: Entering method 'subtract' with arguments: [ 10, 4 ]
LOG: Exiting method 'subtract' with result: 6

この例では、logMethodデコレーターがCalculatorクラスのaddとsubtractメソッドに適用され、各メソッドの実行前後にログを出力しています。context.nameからメソッド名を取得し、originalMethod.applyで元のメソッドを呼び出すことで、柔軟な拡張が可能です。

イミュータブルなデータ操作を堅牢にする秘訣

このセクションでは、TypeScript 5.xのデコレーターとRedux Toolkitを組み合わせることで、イミュータブルなデータ構造をより安全に扱う方法を深掘りします。

秘訣2: プロパティのミューテーションをコンパイル時・実行時に防ぐ

イミュータビリティは、状態管理において予測可能性を高め、バグを減らす上で非常に重要です。TypeScriptのreadonly修飾子はコンパイル時のチェックに役立ちますが、実行時のミューテーションを防ぐには不十分な場合があります。ここでデコレーターが役立ちます。

プロパティを読み取り専用にするデコレーター

フィールドに適用することで、そのプロパティが初期化後に変更されるのを防ぐデコレーターを実装します。

function ReadOnly<T, V>(
  _target: undefined, // フィールドデコレーターの場合、第一引数はundefined
  context: ClassFieldDecoratorContext<T, V>
) {
  if (context.kind === 'field') {
    // フィールド初期化時に実行される関数を返す
    return function (initialValue: V): V {
      Object.defineProperty(this, context.name, {
        value: initialValue,
        writable: false, // 書き込み不可に設定
        configurable: false,
        enumerable: true,
      });
      return initialValue;
    };
  }
  throw new Error(`ReadOnly decorator can only be applied to fields, but was applied to ${context.kind}`);
}

class Product {
  @ReadOnly
  title: string; // 初期値はコンストラクタで設定

  constructor(title: string) {
    this.title = title; // コンストラクタでの初期化は可能
  }
}

const product = new Product("Awesome Gadget");
console.log(product.title); // Output: Awesome Gadget

try {
  // 実行時にエラーが発生する
  (product as any).title = "New Title";
} catch (e: any) {
  console.error("Error:", e.message); // Output: Error: Cannot set property title of #<Product> which has only a getter
}

このReadOnlyデコレーターは、フィールドの初期化時にObject.definePropertyを使ってwritable: falseを設定します。これにより、一度値が設定されたプロパティは、その後変更しようとすると実行時エラーを発生させ、意図しないミューテーションを強力に防ぎます。

秘訣3: Redux ToolkitとImmerでイミュータブルな状態更新を簡潔に

Reduxにおいてステートのイミュータビリティは基本原則ですが、手動でスプレッド構文などを使って状態をコピーし続けるのは煩雑になりがちです。ここでRedux ToolkitとImmerが真価を発揮します。

Redux ToolkitとImmerによるイミュータブルな状態更新

Redux ToolkitのcreateSliceは内部的にImmerライブラリを使用しており、まるで直接状態をミューテーションしているかのようにコードを書けるにもかかわらず、実際にはイミュータブルな更新が行われます。

// store.ts
import { configureStore, createSlice, PayloadAction } from '@reduxjs/toolkit';

interface Todo {
  id: string;
  text: string;
  completed: boolean;
}

interface TodosState {
  todos: Todo[];
}

const initialState: TodosState = {
  todos: [],
};

const todosSlice = createSlice({
  name: 'todos',
  initialState,
  reducers: {
    addTodo: (state, action: PayloadAction<string>) => {
      // Immerのおかげで直接ミューテーションしているように書けるが、実際はイミュータブルに更新される
      state.todos.push({
        id: new Date().toISOString(),
        text: action.payload,
        completed: false,
      });
    },
    toggleTodo: (state, action: PayloadAction<string>) => {
      const todo = state.todos.find((todo) => todo.id === action.payload);
      if (todo) {
        todo.completed = !todo.completed; // ここもImmerが処理
      }
    },
    removeTodo: (state, action: PayloadAction<string>) => {
      // filterで新しい配列を返すこの書き方でも問題なく動作し、より明示的。
      // Immerは配列のミューテーションも検出するため、state.todos.splice()のような書き方も可能。
      state.todos = state.todos.filter((todo) => todo.id !== action.payload);
    },
  },
});

export const { addTodo, toggleTodo, removeTodo } = todosSlice.actions;
export const store = configureStore({
  reducer: {
    todos: todosSlice.reducer,
  },
});

export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

// 使用例
store.dispatch(addTodo('Learn TypeScript'));
store.dispatch(addTodo('Write a blog post'));
console.log("Initial todos:", store.getState().todos);

const firstTodoId = store.getState().todos[0]?.id;
if (firstTodoId) {
  store.dispatch(toggleTodo(firstTodoId));
}
console.log("After toggling first todo:", store.getState().todos);

const secondTodoId = store.getState().todos[1]?.id;
if (secondTodoId) {
  store.dispatch(removeTodo(secondTodoId));
}
console.log("After removing second todo:", store.getState().todos);

このコードでは、addTodoやtoggleTodoレデューサー内でstate.todos.push()やtodo.completed = !todo.completedといった直接的なミューテーションに見える操作を行っています。しかし、Immerが内部でこれらの操作を捕捉し、実際には新しい状態オブジェクトが生成されて返されます。これにより、Reduxのイミュータビリティ原則を守りつつ、コードの可読性と記述効率を大幅に向上させることができます。

よくある落とし穴と回避策

このセクションでは、TypeScript 5.xのデコレーターやイミュータブルな状態管理を導入する際によく遭遇する問題と、その解決策を解説します。

デコレーター移行時の注意点

  • --experimentalDecoratorsとの非互換性: TypeScript 5.0+の標準デコレーターは、以前の実験的なデコレーターとは互換性がありません。既存のコードベースで--experimentalDecoratorsを使用している場合は、新しいAPIに合わせてデコレーターをリファクタリングする必要があります。
    • 回避策: tsconfig.jsonから"experimentalDecorators": trueを削除し、デコレーター関数のシグネチャを新しい標準（contextオブジェクトを受け取る形式）に合わせます。
  • パラメーターデコレーターとemitDecoratorMetadata: 新しい標準デコレーターでは、パラメーターデコレーターと--emitDecoratorMetadataはサポートされていません。これらに依存するライブラリ（NestJSやAngularなど）は、引き続きレガシーな--experimentalDecoratorsフラグを必要とする場合があります。
    • 回避策: ライブラリのドキュメントを確認し、必要であればレガシーデコレーターの使用を継続するか、新しい標準に準拠した代替手段を検討します。

Reduxにおける意図しない状態のミューテーション

  • ネストされたオブジェクトの直接変更: Reduxの状態が深くネストされている場合、誤ってオブジェクトの参照をコピーせず、直接ミューテーションしてしまうことがあります。
    • 回避策: Redux ToolkitのcreateSliceを積極的に利用し、Immerの恩恵を受けます。手動で更新する場合は、常にスプレッド構文やstructuredClone（ES2023）などを使って新しいオブジェクトを作成します。
    • readonly修飾子の活用: TypeScriptのreadonly修飾子をインターフェースや型定義に適用することで、コンパイル時に意図しないミューテーションを防ぐヒントを得られます。

noUnusedParametersとデコレーターのコンテキスト

  • 未使用のcontext引数: tsconfig.jsonでnoUnusedParametersが有効になっている場合、デコレーター関数でcontext引数を受け取っているにもかかわらず、その引数を使用していないとコンパイルエラーになることがあります。
    • 回避策: 使用しない引数にはアンダースコア（_）をプレフィックスとして付ける（例: _context）ことで、未使用パラメーターのチェックを回避できます。

設計上のトレードオフとベストプラクティス

このセクションでは、デコレーターとイミュータブルな設計を採用する際の考慮事項と、それぞれのベストプラクティスをまとめます。

デコレーターの設計判断

  • トレードオフ:
    • 複雑性の増加: デコレーターは強力ですが、多用しすぎるとコードの振る舞いが隠蔽され、デバッグが難しくなることがあります。
    • 学習コスト: デコレーターの概念や新しいAPIには学習コストがかかります。
  • ベストプラクティス:
    • 横断的な関心事への適用: ロギング、バリデーション、認証など、複数の箇所で共通するロジックをカプセル化するために使用します。
    • シンプルさを保つ: デコレーターの内部ロジックはできるだけ簡潔にし、複雑な処理はヘルパー関数に委譲します。
    • 型安全性の確保: デコレーター関数を正確に型付けし、ClassMethodDecoratorContextなどの型を活用して堅牢性を高めます。
    • 新しいプロジェクトでは標準デコレーターを使用: experimentalDecoratorsフラグなしでTypeScript 5.xのデコレーターを積極的に活用しましょう。

イミュータブルなデータ操作の設計判断

  • トレードオフ:
    • パフォーマンスオーバーヘッド: 深くネストされたオブジェクトのコピーは、特に大規模な状態ツリーでパフォーマンスに影響を与える可能性があります。
    • 記述の冗長性: Immerを使用しない場合、手動でのコピー操作はコードを冗長にします。
  • ベストプラクティス:
    • Redux ToolkitとImmerの活用: これらはイミュータブルな状態更新を最も効率的かつ簡潔に行うためのデファクトスタンダードです。
    • 状態の正規化: 深くネストされた状態は避け、可能な限りフラットな構造に正規化することで、更新時のコピー範囲を最小限に抑えます。Redux ToolkitのcreateEntityAdapterも有効です。
    • セレクターの最適化: reselectのようなライブラリを使用してメモ化されたセレクターを作成し、派生データの再計算を最小限に抑え、パフォーマンスを向上させます。
    • ローカル状態とグローバル状態の分離: すべての状態をReduxストアに入れるのではなく、コンポーネントのローカル状態として保持すべきものは適切に分離し、Reduxストアの肥大化を防ぎます。

まとめ

この記事では、TypeScript 5.xの標準化されたデコレーターと、Reduxにおけるイミュータブルなデータ操作をより堅牢かつ効率的に実装するための3つの秘訣を解説しました。

  1. TypeScript 5.xデコレーターでメソッドの振る舞いを安全に拡張する
  2. デコレーターとObject.definePropertyでプロパティのミューテーションを実行時に防ぐ
  3. Redux ToolkitとImmerでイミュータブルな状態更新を簡潔に記述する

これらの技術とプラクティスを組み合わせることで、アプリケーションのバグを減らし、パフォーマンスを最適化し、そして長期的な保守性を向上させることができます。TypeScript 5.xの進化を最大限に活用し、より高品質なコードベースを目指しましょう。

さらに深く学びたい方は、TypeScript公式デコレータードキュメントやRedux Toolkit公式ドキュメントを参照してください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?