水曜日
Elasticsearchを触った
やったこと
光センサを用いて、Kibanaで可視化までできた。
オシャレグラフに近づきつつある pic.twitter.com/CGPB8QjClc
— 周到な準備が勝利を導く (@akameco) 2016年9月21日
Kibanaのグラフは5秒ごとにポーリングするみたい。
ちょっとはまったけど、特につまることなくできた。 明日あたりQiitaにインストールからarduinoのセンサーデータを使ったグラフ表示までの流れを整理を兼ねて書くつもり。
Slackのコード
次のバージョンのSlackのコードがasarを展開すると読める。
slackのソースコード全然読み進められなくて悲しい
— 周到な準備が勝利を導く (@akameco) 2016年9月21日
もうちょっとrxについて知見貯めないときつそう
— 周到な準備が勝利を導く (@akameco) 2016年9月21日
うーんslackアプリすべてがSmart Componentsなんだよな
— 周到な準備が勝利を導く (@akameco) 2016年9月21日
React.Componentを継承したstoreに紐付いた一つのコンポーネントを継承していく形どうなんだろう
— 周到な準備が勝利を導く (@akameco) 2016年9月21日
何をしてもrxに辿り着くのやばい
— 周到な準備が勝利を導く (@akameco) 2016年9月21日
すべてのaction createrをStore.dispatchでくるむのどんなデメリットあるんだろう。 #slack_memo
— 周到な準備が勝利を導く (@akameco) 2016年9月21日
や、普通にテストしずらいのか #slack_memo
— 周到な準備が勝利を導く (@akameco) 2016年9月21日
reduxのミドルウェアにactionを起点にしてapiコールなどを行う多いけど、slackappはactionはstoreを変更させるのみに注力して、storeを変更させる以外のイベントは単にreactコンポーネントからメソッドを実行してるっぽい #slack_memo
— 周到な準備が勝利を導く (@akameco) 2016年9月21日
規模に対してactionが多くない #slack_memo
— 周到な準備が勝利を導く (@akameco) 2016年9月21日
グローバルのwindowオブジェクトのwinssbネームスペース以下にそれぞれのクラスのインスタンスを入れて、reactコンポーネントからそれを叩く #slack_memo
— 周到な準備が勝利を導く (@akameco) 2016年9月21日
これをelectron-remoteのexecuteJavaScriptMethodを通して発行してる https://t.co/izlR1FuDwP #slack_memo
— 周到な準備が勝利を導く (@akameco) 2016年9月21日
うーん、プロダクションにテストコードを残すポカをしてくれれば色々ありがたかった #slack_memo
— 周到な準備が勝利を導く (@akameco) 2016年9月21日
slackapp、webアプリにxssなど存在しないという強い意志をもってweb版のurl開いているので、俺に真似できる感じではなかった
— 周到な準備が勝利を導く (@akameco) 2016年9月21日
Slack appのガワだけを提供して、リストなどの中身はweb版を表示している。 全部で２万行程度なので、ざっと目を通すのにちょうどいいぐらいの規模感。
slackのコードはrxの部分など参考になるところも多いが、reduxの組み合わせなどでview、Reactでいうところのコンポーネントにロジックがかたまりすぎていて色々大変そう。
ロジック
最近だと、reduxのロジックをどこに置くのか？という議論がよくされている。 素のJavaScriptだとredux-sagaがよさそうではあるが、flowを使い型情報を利用したとき、ほんとうにこれがベターなのかという気持ちになる。 ジェネレーターもあまり好きではないしね。 これは、redux-observableにも言える話。
以下の記事では、色々なことを考慮した結果redux-logicというライブラリを書いたという記事。
でも、react-logic、書くことが多すぎてちょっと好きになれない。
