Immer
Immutable.jsより学習コストが低く、型との相性が良い
Immutable.jsより剥がすのも楽
用語
current
現在の状態
全てのオブジェクトの現在の状態のことを言っている
draft
immer内で編集する部分
この中で好きなように編集する
immerから抜けたタイミングで新しいobjectが生成されてcurrentが新しいものを見る
arrayのn番目を更新したい
これの前にfindIndexかなにかでindexを特定しておく必要がある
code:ts
return produce(this, t => {
t.commentsindex = comment; });
//spliceのほうがええんか(?)
return produce(this, t => {
t.comments.splice(index, 1, comment);
});
idがnなものを消す
filterを使う
code:ts
return produce(this, t => {
t.items = t.items.fileter(item => item.itemId === itemdId);
}
v7かv8ぐらいで
code:ts
hooksもある
useImmer
API
produce
code:ts
const obj = { a: { b: { c: 1, d: 2 } }, e: 3 }
const newObj = immer(obj, draft => {
draft.a.b.d = 4
})
↑これ動かないかもmrsekut.icon
draft.なんかでアクセスできるのは一つまでっぽい(?)
draft.a = 4はいけるけど
draft.a.b = 4はだめ、みたいな
docsの中でその言及を探したいmrsekut.icon
setAutoFreeze(false)をするとできるようになった。
ということは結局、immerの扱い方がどこかおかしいのか
setAutoFreeze()
デフォルトでは、devモードではtrueになり、productionモードではfalseになる
trueにしているとパフォーマンスに影響するため。
trueにしていると、produceの外部では破壊的代入をできないようにする
逆にfalseにしているとimmerを使っている意味の半分ぐらいが無意味になる？
非同期関数の中でやつ
この辺も見ないとmrsekut.icon
draft.a.b = 4みたいにかいたときに、エラーになるときとならない時がある
message: "Cannot assign to read only property 'hogehoge' of object '#<Object>'"
draft.a.b = 4みたいにかいたときに、更新されてない時がある
ネスト深くなったときかなー、再現性がない
produceの中でproduceを使ったら動いた。意味がわからない
code:ts
// before
return produce(this, t => {
beforeGenreIds.forEach(beforeGenreId => {
).deletePostId(postId);
});
});
// beforeの書き換え
return produce(this, t => {
beforeGenreIds.forEach(beforeGenreId => {
const tmp = PostPicsFactory.create(t.genresbeforeGenreId.option.postPics).deletePostId(postId); // ここまでは正しい });
});
// after
// 最悪すぎる。冗長すぎ
return produce(this, t => {
beforeGenreIds.forEach(beforeGenreId => {
o => {
o.postPics = PostPicsFactory.create(
).deletePostId(postId);
}
);
});
});
似たライブラリ
死んだ
参考
作者が書いた記事