破壊的メソッドのことをあまり良く分かってなかった

今年のはじめの方に追加されたES2023のメソッドを改めて見直してたら、破壊的メソッド・非破壊的メソッドという言葉が出てきて、そもそもそういったものがどんなものなのか知らなかったので、備忘録として残しておくことにしました。

ミュータブルとイミュータブル

イミュータブル (英: immutable) なオブジェクトとは、作成後にその状態を変えることのできないオブジェクトのことである。対義語はミュータブル (英: mutable) なオブジェクトで、作成後も状態を変えることができる。mutableは「変更可能な」、immutableは「変更不可能な、不変の」という意味を持つ形容詞である。

Wikiより引用

つまりミュータブルは変更できるがイミュータブルは変更できない、そして現代のモダンなフロントエンド開発において「ミュータブルが悪とされている」らしい。

なんでミュータブルが悪なの？

無知全開です。
AIだったらどう答えるだろうと気になったので、Microsoft Copilot（Bing AI）に聞いてみました。

私の質問: 現代のフロントエンド開発においてmutableは悪とされています。なぜmutableが悪なのでしょう？

Copilotの回答

現代のフロントエンド開発では、mutable（変更可能）な状態は避けるべきとされています。これにはいくつかの理由があります。
予測不可能な変更: mutableな状態は、コードの異なる部分から予期せずに変更される可能性があり、バグの原因となります。

• 並行処理の問題: 複数のプロセスが同時に同じデータを変更しようとすると、競合が発生しやすくなります。
• 再利用性の低下: mutableなオブジェクトは、変更された後の状態に依存するため、再利用が難しくなります。
• テストの困難さ: mutableな状態はテストを複雑にし、特定の状態を再現するために追加のセットアップが必要になることがあります。

不変性（immutability）を持つオブジェクトは、これらの問題を回避するのに役立ちます。一度作成されたら変更されないため、より安全で信頼性の高いコードを書くことができます。
Reactなどのモダンなフロントエンドフレームワークでは、この不変性の原則が推奨されており、状態管理においてもimmutableなアプローチが取られています。
ただし、すべてのケースでmutableが悪というわけではなく、状況に応じてmutableな状態が適切な場合もあります。
重要なのは、mutableとimmutableの違いを理解し、適切な場面で適切なアプローチを選択することです。
また、モジュールバンドラーやトランスパイラーを使用することで、開発の効率を上げることができます。

なるほど、以下の記事にも予測不可能な変更について書かれていました。

例えば、jQuery で手続き的に DOM を変更すると、どの状態からどの状態へ遷移したか、変更後からはわからない。今何を行っていて、どのような状態にあるか？を意識する必要をなくし、差分更新はフレームワークで行うので、ゼロから状態を作っていいことにしたのが React の意義。

もう少しCopilotに聞いていきます。

私の質問: mutableな状態が非推奨とされる具体的な実例を教えてください。

Copilotの回答

mutableな状態が非推奨とされる具体的な実例について、いくつかの情報を見つけました。以下にその要点をまとめてみます。

1. JavaScriptでの配列操作: mutableな操作としては、配列に対してpush, pop, spliceなどのメソッドを使用することが挙げられます。これらのメソッドは元の配列を直接変更するため、予期せぬバグを引き起こす可能性があります。一方、immutableな操作としては、concat, slice, mapなどのメソッドがあり、これらは元の配列を変更せずに新しい配列を作成します。

2. 破壊的なメソッドの例: JavaScriptにおいて、破壊的なメソッドは元のデータを変更してしまうため、非推奨とされています。例えば、sort()メソッドを使用する際にスプレッド演算子を使って元の配列を変更せずにソートする方法が推奨されています。

3. Reactでの状態管理: Reactでは、状態をmutableに扱うことは非推奨です。状態を更新する際には、setStateやフックのuseStateを使用して新しい状態を生成し、Reactが効率的に再レンダリングを行えるようにします。直接状態を変更すると、コンポーネントの予測不可能な挙動を引き起こす可能性があります。

これらの実例は、mutableな状態の扱いが非推奨とされる理由を示しており、開発者がより安全で予測可能なコードを書くためのガイドラインとなります。もし、これらのトピックについてさらに詳しい情報やコード例が必要であれば、お知らせください。私はそのような情報を提供することができます。

なるほど〜、簡潔にまとめて答えてくれました。
ありがとうCopilot。

参考