Open hrddd opened 4 years ago
やっぱり公式 https://typescript-jp.gitbook.io/deep-dive/type-system/generics#dezainpatnnajenerikku ここからおパクリ遊ばす、、、 配列型を通すのが難儀だった。要はジェネリクス、、、 typeに代入していたのがよくなかったよなあ、、、単純な配列ならtypeに突っ込むほどでもないね。使うときに指定するのも疲れない、、、
3時間
とりまハンドラ入れる。30分。 お次、選択したパネルの色を変える、ためにデータを整える。文字ごとにidがなきゃね。30分 クリックハンドラにイベント以外のデータ渡すのに、moleculesの中で関数宣言してるのが嫌になった。 カリー化する。（初めて使った可能性がある） 30分（調査） + 30分（実装）
https://qiita.com/tanakyut/items/97975e21af8c7bb4de9d
カリー化する。
をやっている時に、画面をみるのがダルかった。 データの流れの部分はTypeScript + テスト、で十分な予感がしてきているのだ、、、。 TSで型はつけてはいるが、所詮僕がつけたもの。自分で自分を信じられぬ、、、
この辺、、、綺麗にするところはテストで進めて、機能が実装できたぞいってとこで画面確認、が楽チンそう。 リファクタは手元だけでも発生するんだもんな、当たり前か、、、
テストを入れよう！
やってみた。 テストから書く。なるほどみ。入れる。
https://typescript-jp.gitbook.io/deep-dive/intro-1/jest コレ
入れて、そして実装したものがテスタビリティが低いことがわかった。 testありきで書かないとハードルが高そう。情報構造はできるだけ、シンプルなのがいいな、、、APIから取得したものを処理したくなった時に、「シンプル」に行かないとすごいめんどい。モジュールごとの範囲はできるだけ狭めておく、、、
30分（チュートリアル期間のぞく）
ui→アナグラムパズル専用 resource→使えるデータ形式を吐き出し（今コレをuiでやってる。よくない。shuffule機能もあり、一個のテストがでかくなっちゃう） 開発中なので、リファクタではあるけど、許して、、、 いや、、、こういう時に役立つ・・・？もしかして、、、 やってみる
1.5時間くらい？(テストを書く、シンプルなデータ構造にする。問題作成機能は残してみた)
3時間くらい？
4時間くらい
2時間くらい
文字入れ替え、正解、、、まで一応作る。 シンプルなのはやはりいいのだろうな、、、 一個一個の機能に最低限な変更をしていく、、、と綺麗にできる感じ。次の機能を予想しながら作ると逆にうまく行かない。 職人みたいだな。 例えば、answersを配列で作っていたが、実際はnormalizeされてた方が、、、ということ、、、。 answersなんて最初は作らない方がよかった。 isCompleteなんかも、正解したものを登録した方がテストしやすいやね、、、 コレ必要ですよね、という驕りがよくないのだ、、、。
selectorの調整とcomponentの調整。 reduxとcomponentはお互いにシンプルに作っておき、セレクター、コンテナーで複雑さを吸収する、、、のが良いかなあ コンテナにもロジック入れたくない、というのはやりすぎ感。(その分reduxの方にどん詰まり感が) 無駄に悩んだ。
しかし、、、カスタムhooksで非同期書いたの、、、微妙だった（読みにくい）ような、、、うーん、、、
しかし、テスト書いてから配置すると、やりやすいなあ。。。 組み込んだところで、テスト書いたアクションにバグなかったしな
個々の問題、全て正解を設置。 テストでselectorを書いていて、全て正解でこけてた。 問題0個の時に、正解扱いになってしまう、というやつ。 コレにさくっと気づけたのはテストならでは
1時間くらい
10個選んでシャッフル
やっぱり公式 https://typescript-jp.gitbook.io/deep-dive/type-system/generics#dezainpatnnajenerikku ここからおパクリ遊ばす、、、 配列型を通すのが難儀だった。要はジェネリクス、、、 typeに代入していたのがよくなかったよなあ、、、単純な配列ならtypeに突っ込むほどでもないね。使うときに指定するのも疲れない、、、
かかった時間
3時間
こちこちクリックして入れ替える
とりまハンドラ入れる。30分。
お次、選択したパネルの色を変える、ためにデータを整える。文字ごとにidがなきゃね。30分
クリックハンドラにイベント以外のデータ渡すのに、moleculesの中で関数宣言してるのが嫌になった。
カリー化する。（初めて使った可能性がある） 30分（調査） + 30分（実装）
※他の方法のがいいかもだがまあ、、、あとで！
https://qiita.com/tanakyut/items/97975e21af8c7bb4de9d
ここで画面と行き来するのがダルくなる
をやっている時に、画面をみるのがダルかった。 データの流れの部分はTypeScript + テスト、で十分な予感がしてきているのだ、、、。 TSで型はつけてはいるが、所詮僕がつけたもの。自分で自分を信じられぬ、、、
この辺、、、綺麗にするところはテストで進めて、機能が実装できたぞいってとこで画面確認、が楽チンそう。 リファクタは手元だけでも発生するんだもんな、当たり前か、、、
テストを入れよう！
（一旦中断して）テスト入れる
別途チュートリアルやる、、、（テストまでが長い）
やってみた。 テストから書く。なるほどみ。入れる。
とりま
https://typescript-jp.gitbook.io/deep-dive/intro-1/jest コレ
やってわかったこと
入れて、そして実装したものがテスタビリティが低いことがわかった。 testありきで書かないとハードルが高そう。情報構造はできるだけ、シンプルなのがいいな、、、APIから取得したものを処理したくなった時に、「シンプル」に行かないとすごいめんどい。モジュールごとの範囲はできるだけ狭めておく、、、
かかった時間
30分（チュートリアル期間のぞく）
（テスト前に）責務分けをする
ui→アナグラムパズル専用 resource→使えるデータ形式を吐き出し（今コレをuiでやってる。よくない。shuffule機能もあり、一個のテストがでかくなっちゃう） 開発中なので、リファクタではあるけど、許して、、、 いや、、、こういう時に役立つ・・・？もしかして、、、 やってみる
かかった時間
1.5時間くらい？(テストを書く、シンプルなデータ構造にする。問題作成機能は残してみた)
テスト書いて既存を調整、、、
かかった時間
3時間くらい？
テスト書いて既存を調整その２
かかった時間
4時間くらい
テスト書いて既存を調整その3
かかった時間
2時間くらい
テスト書いて既存を調整その4
かかった時間
2時間くらい
テスト書いて既存を調整その5
文字入れ替え、正解、、、まで一応作る。
シンプルなのはやはりいいのだろうな、、、
一個一個の機能に最低限な変更をしていく、、、と綺麗にできる感じ。次の機能を予想しながら作ると逆にうまく行かない。
職人みたいだな。
例えば、answersを配列で作っていたが、実際はnormalizeされてた方が、、、ということ、、、。 answersなんて最初は作らない方がよかった。 isCompleteなんかも、正解したものを登録した方がテストしやすいやね、、、 コレ必要ですよね、という驕りがよくないのだ、、、。
かかった時間
4時間くらい
テスト書いて既存を調整その6
selectorの調整とcomponentの調整。 reduxとcomponentはお互いにシンプルに作っておき、セレクター、コンテナーで複雑さを吸収する、、、のが良いかなあ コンテナにもロジック入れたくない、というのはやりすぎ感。(その分reduxの方にどん詰まり感が) 無駄に悩んだ。
しかし、、、カスタムhooksで非同期書いたの、、、微妙だった（読みにくい）ような、、、うーん、、、
しかし、テスト書いてから配置すると、やりやすいなあ。。。 組み込んだところで、テスト書いたアクションにバグなかったしな
かかった時間
4時間くらい
正解の状態を表示
個々の問題、全て正解を設置。 テストでselectorを書いていて、全て正解でこけてた。 問題0個の時に、正解扱いになってしまう、というやつ。 コレにさくっと気づけたのはテストならでは
かかった時間
1時間くらい