設計について考えた前半

2017年から2018年にかけ、担当事業のフロントエンド再設計を担当した。「Redux と OOP は混在可能か？」という取り組みや「Redux に IDDD の思想を取り込むとどうなるか？」という構想を2月に発表。今振り返ってみると、今年の大きな出来事は2017年から連鎖している。

2月 : TechCon2018 登壇

DeNA の年間で一番大きなエンジニアイベントで登壇する機会を貰えた（2年連続登壇も 2019年は叶わず）その時の記事がこちら。

https://design.dena.com/engineering/dena-techcon-2018-frontend-ddd/

今現在も破綻することなく、手詰まりは発生していない。複雑で要件のシビアなヘルスケア事業ドメインでも「UI設計で攻める余裕」が出来たのは大きく、ユーザーとの対話をフロントエンド実装がどう引率するのか？という本質に向き合えている。

Redux でしか実現できない設計パターンは封じ「概念レベルのフレームワーク」を重視。特定技術から独立したドメインモデルを探求し、パラダイムシフトに耐えうる設計を目指した。

Redux に持たせている Immutable.js 製の UIドメインモデルを Hooks にそのまま移植できそうなので、一つ目標をクリアした実感がある。既存のコードを Immutable.js から書き換える予定はないが、今後も使い続ける予定はない。

6月 : redux-aggregate リリース

Redux Store にドメインモデルを構える一環として、それを純関数で書けるものを提唱した。

https://www.npmjs.com/package/redux-aggregate

Immutable.js は Pure でないため、ドメインモデルとして残すには耐年数が低い事は把握していた。それを打破するべく作ったヘルパーライブラリが redux-aggregate。主旨は型パズルの自動化よりも、ドメインモデルを書くコードベースに自然となるところにある。redux-aggregate の利用者は、必要に応じて Redux から Hooks へマイグレーション出来るコードを既に得ている。

https://qiita.com/Takepepe/items/a79e767b38981c910c3f

ドメインモデルの置き場所はどこでも良い。Backend・Store・View、どこが持とうが冪等でなければ Universal ドメインモデル とは呼べず、redux-aggregate はそれを Store が持てる様にハブを提供しているだけだ。「State を 中心とした Read・Write スタック」がドメインモデルの実体だと思っているので、class構文は重要ではなかった。

置き場所や記法に固執し、線の引き直しの足枷になる方が問題だ。どこでも通用する設計図はやはり無く「相手を見極めて線を引く力・引き直す実行力。これを怠るといつか破綻が訪れる」というのが設計云々に対する自分の決着で、状態管理設計の探求はこの時点で終了した。

TypeScript が楽しかった後半

flow はずっと使っていたが、お気持ち程度の型付け。それなりの効能があったので不満はなかった。しかし、世論は TS に流れる一方。折角なので、「redux-aggregate は TS で作るか」と思い偶然発見した  Conditional Types が全てを変えた。「まだリリースされて三ヶ月、これは熱すぎる。Conditional Types 広めたい」という想いと、技術書典サークル参加が重なった。

10月 : 技術書典サークル参加

Conditional Types の魅力を広めたい欲求が高じ、TypeScript の同人誌を書いた。技術書典というハードルを自らの口にねじ込んで乗り越える。

https://note.mu/takepepe/n/nca1765996976

この時のご縁で、TypeScript の商業誌を執筆することになった。実力というより、TSオンリーの書籍が自サークルしか頒布してなかったので、単にラッキーだった。もちろん商業誌執筆は初めての体験なで、来年なんとかするしかない。良い事づくしなので各位熱意があれば、同人誌執筆をためらう理由はないと思われる。

12月 : React Hooks 大喜利

10月末、Hooks が発表されてから一ヶ月間、11月は毎日 Hooks 弄りをして、アウトプットを一人アドベントカレンダーに仕立てた。

https://qiita.com/advent-calendar/2018/react-hooks-ogiri

UI に絞ったのは、自分が元々UI 作りが好きだったから。「FC を美しく書くべし」という無言の圧力に黙殺されてきたインタラクションの価値を取り戻したいとも思っていた。

Hooks が全体設計に何か大きな影響を与えるか？という疑念は、冒頭の通り信念が出来上がっていたので生まれなかった。より良い UI を背徳感なく作り易くなるのであれば、ひたすら撃ちこむ。そうして 24作を送り出した。今後も時間の許す限り、このシリーズは増殖させていく予定。UI のロジックは本当に楽しいので、誰かと語り合いたい。

2019年取り組み

非機能要件で定量価値が確立されていない分野がフロントエンドエンジニアの裁量にまだまだ埋もれていると思う。「画面設計・インタラクション」がまさにそれ。

何もしなければ口には何も入ってこず、無理やり押し込むと、より一層押し込まれが発生することが分かった一年でした。口が割けない程度に来年も頑張ります。