the north.

同人いろいろやるサークル "the north." のブログ

今日やったこと: 2018/12/08

久々にブログに書けるくらいまとまったことをやったぞ。 ここのところコミティア原稿で忙しかったり、DJ業で忙しかったり細々した進捗が多かったので書くのが億劫だった。

今日はFleurをめっちゃいじってた。 ツイッターの様子

  • [fleur] Redux devtools に対応させた diff withReduxDevTools という関数を作った。こいつにappContextを与えると、AppContext#dispatchをオーバーライドして、redux-devtoolsにdispatchやdehydrateされたStoreを送りつけるようになる。 使い方はこれを見てくれ
  • [fleur-di] ライブラリ非依存のどシンプルなDIコンテナライブラリを作った
    詳細はREADMEを見てくれ
    これは @f_subal 先生の影響を受けて作ったものだ、詳細は気になったら聞いてくれ
  • [fleur-test] fleur用のモックファクトリーライブラリ、fleur-diと組み合わせればこれでOperation層のテストはそれなりにできるようになるはず
  • [fleur / fleur-route-store-dom] 放置してたSSR対応ブランチをmaster追従させてマージした。

[fleur / fleur-route-store-dom] 放置してたSSR対応ブランチをmaster追従させてマージした

これにあわせて動作確認のためにTodoMVC(TypeScript + React)をコピーしてきてFleur(SSR)で再実装してみたんだけど、 TodoMVCのコードがTypeScript的にもReact的にもめっちゃ古くて書き直しが面倒だった… 半日くらいの時間をこやつに奪われた…つらい…
fleur-diの使い心地検証もしたいので、時間があったらAPI部分を書いてそこらへんのテストも書いてみたいが、面倒なのでしばらくやりたくない

FleurのAPIがクソ

TodoMVCの再実装してて、やっぱりFleurのAPI長ったらしくて書くのが面倒くせぇという気持ちが浮上してきた Operationと名付けたのがよくなかった感がある、今のうちならUseCaseとかにしても誰も困らないから変えようかな…

this.props.context.executeOperation

お前な。これはUseCaseに変えてもクソ長いからそもそもpropsに直接生やしたほうが良いかもしれん。 コンフリクトが怖いけど、Reduxのprops.dispatchだってみんな被せずに使ってるしな、気にするほどでもなかったかもしれない

this.props.{execOperation,getStore} なら多少マシ感がある。

operation、お前必要?問題

TodoMVCみたいなかなりシンプルなプロジェクトだと、Operation層が極薄0.02mmって感じになり書くのが億劫になる。 ComponentContext#dispatch とか生やせばOperation層をスキップしてStoreに司令を送れるが それを許した先の.executeOperation.dispatchが混在する世界は、初見に対してハードモードって感じになりそうなので 強い気持ちで「無意味そうなoperation(...)にも設計の一貫性と一覧性として必要だよ」と言っていくことにした。

context.getStore(HogeStore).getXXX()

connectToStoresのお前だよお前。Redux触ってる立場になるとクソ長い。 stores.hoge.getXXX みたいなやつになりたい。でもAPIがBreaking Change過ぎてつらい。

operationの引数、型チェックは聞くがエディタ補完が効かないし引数渡しがオブジェクトなのがつらい

第二引数に受け取るオブジェクトの型定義がキレそうなほど面倒くさい これになってくれ。実際できるかは知らん。

export const hogeOp = operation(context => (arg: string, arg2: string) => {
  context.dispatch(hogeAction, {arg, arg2})
})

context.execOperation(hogeOp('arg1', 'arg2'))

// 今は
export const hogeOp = operation((context, payload: { arg: string, arg2: string }) => {
  context.dispatch(hogeAction, payload)
})

現行はTypeScriptの以前の型定義の制約上、関数の引数列の型を推論できなかったから1オブジェクトを受け取る形式にしたけど、 もう可変長引数の型を推論できるようになったし、Payloadを受け取るか引数を受け取るかは利用者が任意に選べばええじゃろ。 とりあえずオレはオブジェクトをぶっ壊して展開するやつを書き飽きたぞ… フレームワークとしてはどっちかに固めたいところだが。


というのが本日得た課題感でした。おしまい。