Kyoto.js#14に行ってきた話
Kyoto.jsについて
みんな〜JS書いてる？？
振り返り
結構みんなjsを書いてなかった。そもそも自分もk8sのyamlかtfを書いてる。
京都には鴨川があるのに、なんで水車が設置されて無くて、なんでドネルケバブが回転していないのか不思議だった。
発表資料
自分はCycle.jsを使うことが多くて、業務でもここ最近はCycle.jsしか使ってないんだけど
そこらへんで溜まった知見のSESパターンの話をした。
そもそもSESパターンは自分でつけた名前なのでググっても出てくるわけがないんだけど、
もともと前職にいる時に3人ぐらいのおっさんで「Actionをdispatchってただのreduceだし、もうちょっとsimpleにかけるじゃん」みたいなとこから始まって、
現職で「いやぁ〜それってendomorphismですわ〜〜」みたいな人の発言から、Endo<T>をよく使うようになって、Stream<Endo<State>>がクソ長くて
type $ES = Stream<Endo<State>>からSESになりました。
資料ではあんまうまく書けなかったので書いてないメリットなんだけど、
言語特性上だいたいのRx系はEventやんというのは置いといて。
人の意図が絡んだアプリケーションをあらわすコードとされるものの中では
「このタイミングでこうしてほしい」っていうEvent系のものと、「Streamが表しているのはXXXという状態なんですよね〜」みたいなBehavior系があって
このSESパターンにおいてはそれらが区別しやすくなるですわね
結局このタイミングでこうしてほしいっていうのは、結局状態変化を望んでいるのでSESになるし（ioの特性上ならないのもある）、
俺のアプリケーションっていうのはこういうStateだ（そのState外でうまく適応しておきますね[外ではstateを使って別のSESになる]）という表現はStream<State>になる。
まぁどうやっても欺瞞感があるのはわかるけど、解釈を助けるためにパターンに落とし込む行為はリーダビリティを上げVNodeは流行った。
感想
もうちょっと現実的なところとか紹介したいけど、みんなCycle.js使ってないし(知っている人は結構いた)、Cycleの紹介とか入れると発表時間が足りなくなる。（5分オーバーした）
あとStreamの説明も割と雑にやってしまったが、説明し始めるとa few時間ぐらいかかりそうなので、また別の機会に。
なんかCycleとかPureScriptとかElmとかのFRP系のwebやってる人でmeet upしたいですね。
