JavaScript で クラスベースの設計より関数指向の実装を薦める理由 + GraphQL について
最初に: 「Functional Programming 最高！」という話ではないです
JSは通信やストレージに保存するデータの扱いの関係で、JSONにシリアライズできることが至上命題になるケースが多いので、クラスベースの設計で自身に副作用を起こすメソッドより、イミュータブルな T => T なstatic methodとして切り離しておくと扱いやすいケースが多い
— 現場の声 (@mizchi) 2016年9月6日
複雑なオブジェクトのシリアライズは簡単だけど、逆にシリアライズされたオブジェクトからビルダを構築するのが難しいので、JSONの構造体自身とは別に独立して独立したメソッドとしてビルダが切り離されている方が扱いやすい
— 現場の声 (@mizchi) 2016年9月6日
一応コンストラクタ名を保存してシリアライズ/復元する方法はあって、RPGツクールMVのコードを読むとそういう感じになっていた。
— 現場の声 (@mizchi) 2016年9月6日
HTTPやWebSocketでJSONを構造体を投げ合う / サーバーサイドでMongo環境である / クライアントサイドでIndexedDbで保存する / 出力形式としてJSON フォーマットを持っている、などがJSONシリアライズを強く意識する環境で、とくに通信
— 現場の声 (@mizchi) 2016年9月6日
そういうドメイン的な都合とは別に、イミュータブルな構造体の変換(T -> T)の関数をインスタンスの実装から分離するといいよね、というのはモダンな言語でも流行りのアプローチなので、実際にはthisが第一引数へ、副作用の代わりに同じ型のインスタンス返す、というそれだけの話
— 現場の声 (@mizchi) 2016年9月6日
JSで immutable-js 使わなくても、強い心で副作用を起こさない、というアプローチを取ることは可能です。今なら object literal shorthand があるので const next = {…prev, foo: 1} と書けて記法的にもそこまで辛くはない
— 現場の声 (@mizchi) 2016年9月6日
こういうのもある https://t.co/MReB2a2NLf
— 現場の声 (@mizchi) 2016年9月6日
GraphQL について
mizchi さんに GraphQL(実装ではなく、仕様とコンセプト)について評してほしいの気持ち
— 21話 (@KOBA789) 2016年9月6日
GraphQL ちゃんと掘ってないけどクエリがだいたいJSONなんだからJSONでよかったやろと思っちゃいる。アレのせいでクラサバにパーサが必要になってだるい。サーバーはいいけどサイズ絞りたいクライアントはなーという。たぶんbabelみたいなプリプロで変換できるけど。
— 現場の声 (@mizchi) 2016年9月6日
GraphQL、コンセプト的にREST APIと対立するというかREST APIの否定感が強くて、クライアント本位なら別にいいけどREST倒すほどのものかというと厳しいのではという感じがある
— 現場の声 (@mizchi) 2016年9月6日
@Quramy なんとなくやってそうな気がしましたが、やっぱやってるんすねー
— 現場の声 (@mizchi) 2016年9月6日
JSONでクエリ書けばいいやん！ってのはやっぱ思っててコード中インラインでクエリ書くのは静的解析辛いだろうしシンタックスハイライトとかエディタ側でし辛い(できないとは言わないがだるい)
— 現場の声 (@mizchi) 2016年9月6日
Mongoのクエリは書きやすかったという話です(Mongoがよかったという話ではない)
— 現場の声 (@mizchi) 2016年9月6日
要約するとGraphQLは目的に対して独自構文まで持ちだしたのはやり過ぎなのとREST倒すだけのメリットを提示できてない、という感じですあとグラフデータベース的な側面はFacebookみたいなソーシャルグラフを扱ってないとあんまり生きないのでは、という気持ちもある
— 現場の声 (@mizchi) 2016年9月6日
