雰囲気でSWRを使ったらハマった話

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

6 ©2023 Loglass Inc. 従来あらゆる集計作業を自動化工数を削減し、意思決定精度・速度の向上集計・誤り探しの煩雑な手作業が中心属人化した手作業の連続、ミスの温床 ● 出所ごとにバラバラのフォーマットを手作業で統合。数値の正確性担保に時間を取られる ● いつ・誰が・何を変更したか履歴を追うのがほぼ不可能であり、ミスが発生していても発見しづらい ● 集計作業に時間がかかるため、詳細なデータをレポートまで落としきれない ● 細かな閲覧権限制御が追いつかず、経営レイヤー以外に詳細な情報を共有しづらい ● Excel、スプレッドシートのデータを自動統合することで、集計作業時間を極限まで縮小 ● システム上でバージョン管理を徹底し、変更点が可視化されるため、いつ・どこでミスが発生したか分かる ● 配賦などを含む詳細なデータがリアルタイムで可視化されるため、意思決定の精度が上がる ● レイヤーごとの細かな閲覧権限設定が容易で、センシティブな情報をケアしながら情報を透明化できる Loglassで変わる経営管理

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

11 ©2023 Loglass Inc. 原因のコードの全体像を簡単に紹介動作イメージ ‧SWRで組織図の⼀覧を取得する ‧useEﬀectOnceでプライマリ組織図のツリーを取得する ‧result.treeMapsを使ってセレクトボックスを表⽰する ‧result.treeを使ってツリーの部分を表⽰する ‧画⾯で組織図を変更した場合は、loadTreeが呼ばれる結局どうなっていたのか ‧result.dataがundeﬁnedのままになってしまっていた ※ コードはイメージです

Slide 12

Slide 12 text

12 ©2023 Loglass Inc. なぜundeﬁnedのままになっていたのか実はまだ完全に理解できていないのですが... 不具合発⽣時は以下のような流れです ‧fetchTreeMaps によるデータ取得中 ‧useEﬀectOnce から loadTree が呼び出される ‧if (!data) return; で早期リターンされるそうなると、後にfetchTreeMapsの結果を取得してもキャッシュの更新はされないままとなってしまうフロントエンド強いマンいたら解説してほしい...

Slide 13

Slide 13 text

Slide 14

Slide 14 text

14 ©2023 Loglass Inc. SWRとの決別をすることに ‧SWRを使うのをやめて、初期表⽰とセレクトボックスの変更時の毎回APIを叩くように変更した ‧そもそもSWRである必要のない画⾯だった ‧SWRを使うとなると、APIの構成的にもちょっと複雑な作りになってしまうことを避けられない ‧愚直に直列にデータを取得するようにした ‧まずは組織図の⼀覧を取得する ‧次に選択している組織図があればそのツリーを、なければプライマリのツリーを取得する ‧最後にこれらをいい感じに組み⽴ててレスポンスを返せばオッケー無事に解決！わーい！

Slide 15

Slide 15 text

Slide 16

Slide 16 text

16 ©2023 Loglass Inc. 振り返って反省してみる ‧そもそもSWRのことを雰囲気で使っていた ‧キャッシュの更新をカスタマイズするの、複雑になるから避けたいよねという感覚はあった ‧データのフェッチングとmutateが同時に動いたらどうなるのかを理解してなかった ‧修正範囲を⼩さく済ませようとしすぎた ‧最初の段階でSWRをやめる検討もしたが、修正量多くなるし⼀旦やめとくかとなった ‧最初の不具合⾃体もそこまで重要じゃなかったので、あまり時間をかけたくなかった ‧hooksの単体テストを書いていなかった ‧フロントエンドのテストに対してコスパが悪いイメージを個⼈的に持っていた ‧今回はUI関連ではなくロジックのテストだったのでちゃんと書くべきだった

Slide 17

Slide 17 text