セットでつかおうみたいなノリの記事はネットでよく見るが、じゃあなんでそのセットなの?という点に関してはあまり詳しく書かれていないことのが多い気がしたので、個人的にその理由っぽいのを雑に書き残しておこうと思う。大勢で開発してるとこっそりどこかで参照を持ったオブジェクトを書き換えてた、なんてことになりやすい。呼ばれて初めてビューの更新が予約される。この更新はミュータブルなステートの部分更新などではなく、新しいステートを丸ごと与える。まみれになるところが、Immutable.jsでスマートに書けたりする。使わないほうがパフォーマンス的にもよくなる気がするし、むしろ使うべきじゃなかったと思っている。オブジェクト間の差分チェックをして、もし差分があればそれをビューに適用していく仕組みになっている。パフォーマンスが向上する。ディレクティブなどとの相性が悪いらしく率直に言って使いづらそうだ。プレーン・オブジェクトへ変換する処理のオーバーヘッドがそこそこデカいので、ユースケース上ここがボトルネックになってくるとどのフレームワークと組み合わせていてもイミュータビリティが破綻し始める感がある。自体がそもそもイミュータビリティとの相性がいいフレームワークになっているという印象。他のフレームワークだと場合によっては微妙。入れておいて損がないよ、と言われる理由はだいたいこんなもんかな。全ての関数が最初からイミュータブル。オルタナティブが出たらしい。パット見ではコレクション系のクラスっぽいものがなくAPIが非常にシンプルという印象。こっちも要チェックっぽい。イミュータブルの概念を理解するにあたってはガベージコレクションなどのメモリに関する知識と、データに対する計算量などのアルゴリズム的な知識のふたつが必要になるのではないかと思う。アルゴリズムについて学ぶにあたっては、やはり「アルゴリズムとデータ構造」が一番おすすめであると言える。2019最終日の記事です。(8)はてなブログをはじめよう!IzumiSyさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。