久々に麻婆豆腐作ったら塩味になってしまった
Spider-Man: Homecoming, Thor: Ragnarok - osa_k’s diary http://osak.hatenablog.jp/entry/mcu-11 #はてなブログ
金曜がなんでもない日おめでとうで休みになり、月曜がMemorial Dayで休みであることが判明したので、いきなり4連休が出現した
Fetch APIを途中で中断したいときってGoのContextみたいなことしないといけないのか……せっかくPromiseで待ちを抽象化してるのに漏れてるじゃん
@collappsar Thanks, but that's exactly what I mean. I'm not satisfied with this design because fetch API call is often wrapped in a utility function that just returns a Promise, which makes it quite tricky to deal with the signal param
定期的にポーリングしつつ、サーバがあまりにも長い時間返事を寄越さなかったら諦めて次のループを始める的なことをしたい
Promise.race的なので待ちを諦めるのはできるけど、コネクションが残るのはちょっと気持ち悪さがある
サーバーが自主的にタイムアウトしないならリトライしても無理だからおとなしく待ってろという立場はあり得る
@collappsar Hmm yeah, it could be an option. However such object is hard to type in TypeScript without using `any`...
@collappsar oooh, I thought Object.assign would work only on object literals! This approach definitely works. Thank you for the help!!
@collappsar I love TypeScript too :) I recentely started writing a webapp after a few years of blank, and I'm surprised seeing how comprehensively React & Redux are typed. It's the best web development experience ever.
@charsiuCat I/Fの公開度とか副作用の有無みたいな外形的な基準でテスト対象かどうかを判断すると訳分からなくなりがちなので、なぜテストを書くのかの原点に戻って、とにかく壊れたらヤバいロジックをカバーすることを第一目標にする(重要度が低いとこは最悪諦める)のが結局一番良いという気持ちになっています
privateなメソッドにテストを書くなというやつ不勉強ながら原典を知らないんだけど、おそらく元々は「書くな」とは言ってなくて、privateメソッドをテストしただけで公開I/Fがテストされたと思うなよ?の意味なんじゃないかと思っています
個人的にはだいたい「対象になる関数やロジックのinvariantを一息で説明できなければテストを書いた方がいい」くらいの基準でやっています
Genericsの話題で出てくるinvariant/covariant/contravariantって元々どの分野の言葉なんだろう