温泉自体は2回目やけど、ワイと入るのは初めての温泉。 風呂入る前から不安そうな顔しててばり嫌そう。

お風呂入ったら案の定離れたらすぐ泣くからずっと抱っこしながら体を洗わないといけなくて辛かった。 アヒルが浮いてるけど、そのアヒルを触ろうともしなかった。

潔癖症なのかなってレベルであまり好きではなさそう。家の風呂は好きなのに。 もう少し大きくならないとあんまり好きそうではないみたい。 ただ、その温泉にあったおもちゃ遊びできるところはめっちゃ楽しそうやった。

何が違うのか…?

複雑なコードをどう読むか

View側の変更自体はそんなに難しくなさそうなのに、実装コードが難しすぎた… 何が難しいのか、何が把握しにくいのか上手く言語化できないけど。

多分何を設定しているかが関数で隠蔽されてて、その関数みても何やってるのかわからず、なぜその値になっているのか分からないから? 処理の中で多くのことをやろうとしていたりするのは思ったよりも見にくいのかも。書いてるときはそんなことないから難しいよね。。

色んなコンテキストのデータが混じってて、コンポーネントの出し訳があってもそのコンポーネントに名前がついておらず条件分岐で出し分けてるとなぜそうなったのかが分からない。

挙動の把握に一番時間かかる。。 ブレークポイントで止めて、追う方がいいのかな?

テスト書いたりってのもできるかもしれないが、初心者にこのコードからテストを書くのは難しい。 何か分解したりしていって一つ一つやるようにしないといきなり全ては難しい。

Storybook

Storybookの勉強した。

勉強っていっても、どうやってコンポーネントを作るかみたいなのを簡単に触っただけ。 個人的に面白かった。

Atomic Designを採用しているので最初はAtomsから作ってみてる。

状態を一つのselectとかradioボタンとかで変更できるのでそっちにしようかと思ったけど、テストしていくって時にjest側でインポートできるし最初から状態を分けておくのでもいいかなとStoryは分けておいた。

合わせてjestでテストも書いていったのでだいぶ頑張った。 testing-libraryに少し詳しくなった(やったね)

testing-library/react

testing-library/reactはtesting-library/domの拡張で、screenとかrenderみたいなdom操作するための関数が増えるって感じみたい。

マッチャーを増やすのはtesting-library/jest-domでやってるみたい。 ややこしい。

一つのテストケースにまとめるのか分割するのかがあんまりよく分からなかったな。同じ処理を何回もやるからってbeforeEachにまとめたりとかし出すとわかりづらくなるし、そこまで長くないなら多少の冗長性は必要ってのもなんとなく分かったのでよし。

更新日時: