フロントエンドGUIの状態の整理

昨日の🍺のあとに考えていた雑感。フロントエンドから見たGUIの状態を個人の主観をもとに整理しています。

背景

複雑なJavaScriptアプリケーションを考えながら作る話

と

id:Pasta-K がReact + Canvasで色々やっていた話

などなど。

Reactなどの現代フロントエンドはたいへんしんどいGUIであるという前提もあります。

GUIの状態の種類

人間

諸悪の根源。

だいたいこいつが状態を変更してくる。バリデーションが必要なのもこいつのせい。

わかりやすいUIを提供しないと人間が弱る。

View

Viewの中の状態。UI上の選択状態とか。

Viewに状態を持ちたくない宗派としては、できれば非永続化層（メインのビジネスロジックと状態を持った層）か永続化層（DB）にすべての状態を持っていて欲しいが、パフォーマンス上の問題でthis.stateに状態を持つことはありえる。ReactとCanvasでやっていくにはここに状態を持ってもパフォーマンスが厳しいとかなんとか。

コンポーネント単位でのユニットテストは書けるが、非永続化層よりはめんどくさい。結合テストはもっとめんどくさい。

状態がUIコンポーネントの中に閉じている、パフォーマンス上仕方ないといった条件が揃ったらここに状態を持つ設計を選択したい。

非永続化層

main()にあたる我々がよくいじっているレイヤ。メモリの中の永続化されていない状態とロジックを持つ。PDS（Presentation Domain Separation）を推し進めると、ここと永続化層ですべての状態を管理することになる。

FluxにおけるStoreとかStateとか言ってるやつがここ。Fluxの場合はImmutableであると扱いやすいと思う。適切に責務ベースでドメインモデルを分割していればテストも楽。

永続化層から取り出した状態、サーバへ投げるための状態、UIの状態などもここに突っ込まれるので、ちゃんと設計しないと簡単にカオスになる層。

たぶん低〜中程度の複雑さのアプリなら永続化層を扱わなくてもなんとかスケールできると思う。複雑度が高くなると状態をいったん永続化層に逃して正しくCQRS（コマンドクエリ責務分離）したほうが楽になるはず。*1

永続化層

サーバ屋的にはDB. インメモリなDBであることもある。ブラウザでなければファイルでもよい。高級なDBであるほどトランザクション処理に対応してたりしてとても便利。フロントエンド環境ではインメモリDBが主な対象。よくシングルトンなMapオブジェクトで実装されているような気がするが、欲を言うとブラウザ内にACIDなDBがほしい。IndexedDBは使ったことないので何も言えません。

ここの層もちゃんとデータ構造を設計しないとスケールしない。永続化層へのデータ挿入は非永続化層にいるロジックたちの責務なので、テストはロジックを通して行われる。

サーバ

ネットワーク越しにつながれた状態で、非永続化層から適切なタイミングで状態を反映してやる必要がある。

フロントエンドで非同期処理といったらだいたい半分がこれ。役割とかについては特に説明不要でしょう。

図ではサーバへの状態の反映しか描かれてないが、サーバから状態を取り出すこともある。どんなリクエストを送ったとしても、レスポンスの結果を切り出して非永続化層の状態とマージすることが多い。また、人間による状態の変更をブロックするためにリクエスト中であることを示す状態を必要とすることもある。

各アプローチ

人間 -> View, 非永続化層のループ

フロントエンドGUIはブラウザという環境の制約からここに閉じることが多い。FluxはこのループにCQRS的な発想を導入したものだと思ってる。上でも述べたようにサーバが登場したり状態が複雑になるとこれらの層だけではスケールしなくなることがある。

this.stateやReduxは永続化層を扱うことを想定していないし、扱うのも直接は難しい気がする。

上図全部のスタック

複雑なJavaScriptアプリケーションを考えながら作る話 が対象としているもの。おそらくネイティブアプリと基本的な構成は変わらない？

その他

状態を変更するのは誰か

ふつうのFluxだと人間による状態の変更を特別扱いしている問題がある。

Fluxの一派？であるCycle.jsはその点ぶっ飛んだ発想をしていて、main()ロジック以外のすべてが状態を変更してくると言っている。Cycle.jsはRxでだいたいすべてのロジックを実装しろという恐ろしいフレームワークだが、誰が状態を変更するかという問いに対してはおそらく正しいことを言っていて、たしかに我々が書くmain()の状態を変更してくるやつはユーザ操作もサーバとの通信も平等に作用(action)である。

だから、Reduxではユーザ操作以外の作用をミドルウェアで解決するしかないのであり、Redux単体では特別扱いしたユーザ操作作用の問題解決のみに注力しているのだと私は思っている。

そしてユーザ操作作用以外の作用が登場すると、それは競合状態のはじまりであり、作用と作用の間でどちらを優先するかという問題が出てきたりするがそれはまた別のはなし……。*2

どの設計方針を選択するか

所属する組織の特徴*3と要件をよく観察して考えて各位で判断するしかない。やっぱり銀の弾丸はないし、現実に合った選択を都度やっていくしかない。流行りものも上記の問題点がいくつかあり、場合によっては合う合わないがある。

おまけ

Cheek Pouch — moko-oxygen: はかどる！ハッカドール3号くんのSlack用カスタム絵文字 を配布します ...

Cheek Pouch

上で概念を説明した図に登場するハッカドール3号くんです。 

*1:非永続化層で行う状態の監視やトランザクションのロジックを永続化層に移譲する

*2:reduxは非永続化層への作用はatomicであるという制約をいれてるということか？

*3:組織構造によって技術選択は変わる

えも

理性、論理的な言動がエモやエモ的な言動より「よい」いうことは言えない。

おそらく教育とか社会の洗脳の結果ではあるのだけど、エモい状態になって自分のエモい気持ちを絶対に譲る気はないのに、言語インターフェイスとしては論理的にやる人が多い。私もやる。

いったんエモい状態になってエモ度が高まると、言葉ではどんなに論理的であっても自分の気持を変えることはなかなか難しいので、そのエモい気持ちを素直に言語化して感情として伝えたほうが効率的なコミュニケーションになるのではないかと思っている。*1

また、我々は勝手に論理がエモに優越すると勘違いしているが、1対1のコミュニケーションで相手も論理を重視する宗教であればそうかもしれない。しかし、多人数の目がある場だとコミュニケーションによる説得の裁定者は会話をしている二者ではなくまわりの聴衆であることが多い。つまり、論理がエモに優越するかどうかは背景にいる聴衆の属性によるとしかいえない。事実として、人間はエモ説得に弱く、public度合いが高いテレビなどではエモ言説がかなり多くみられる。

なので、論理とエモのどちらが優れているかという価値判断は意味がなく、会話をしている場の特性によってどちらがより効率的に人間を説得できるかが決まるまでしか言えない。

じゃあどうすればいいのかという話に入ると、自分がエモってる時はそれを自覚した時点で、できれば自分のエモい状態を伝え、できなければ一旦引くとよさそうだ。逆に相手がエモい状態になってきたら、一旦相手のエモい気持ちを汲み取ってとりあえず肯定してやるのがよい。あるいは、自分が悪いことがわかっていたらさっさと謝罪したほうがいい。

とはいうものの、実は文章を介したコミュニケーションでは自分の出力した言語をセルフレビューで直していくことができるので、エモよりは純粋に論理ベースな会話をしやすい特徴はある。しかし、これもセルフレビューをする訓練を積んだ人ができるという話であって、おそらくほとんどの人はできない。また、文章を書き始める取っ掛かりの気持ちが強いエモだった場合はもうどうしようもない。

という、以上のこの文章も論理嗜好宗派で書かれている。ここで私がこの文章を書くに至ったエモを素直に書いておきたかったのだが、書いているうちに気持ちを忘れてしまったのが正直なところだ。「プライド高いやつらめんどくさい（自分を含む）」くらいだったかもしれない。皆さん負けるのがいやなのでプライド高いのは生物的なレベルでしょうがない*2とは思うのだけど、自覚しておくと得をするシーンも多いのではないかという話になる。

*1:なぜなら、コミュニケーションの目的が説得や意思決定である場合は、誰かが意思を絶対に曲げない状態だと会話をしても無駄だから

*2:合理的な判断しかしない人間を経済人と呼ぶが、そんなもんは存在しないという立場がさいきん流行っている行動経済学

Optimizing React Apps in Practiceの記事がよかった

marmelab.com

がよかった。

書いてある知見

• プロファイリングツールの使い方
  • ChromeでDeveloper Toolを開いてrecordした間のイベントから、どの処理に何ミリ秒かかったか表示される
• 遅いのはだいたいre-renderだよという話
  • わかるけどついやっちゃう
• shouldComponentUpdate()のはなし
• acdlite/recomposeを使うとPureComponentもfunctional componentでらくらく書けるよという話
  • Reduxでもますますべんりなrecomposeのpure()
• reselectでmapStateToPropsのコストを削減
• Beware of Object Literals in JSX
  • JSXでcomponentのpropsに{{ marginTop: 10 }}みたいな渡し方すると毎回オブジェクトが作られて毎回renderされちゃうよという話
  • これ気づかなかった
  • ちゃんとconstで定義しておきましょう

所感

私はあんまりfunctionalなReact派ではないので宗教的に使えない知見もあったが、acdlite/recomposeとかObject Literalの話は役に立ちそうだった。

今日ようやくReact Componentの切り方について悟りを得たのだけど、「propsが変わったときに同じタイミングでrender()される必要があるか」という基準でドンドコ分けていけば良いと思った。
よくやりがちだったのが、同じComponent classの中にrender_hoge()を定義して、それをrender()の中から呼ぶというやつ。これはrender関数の中身をきれいにはするのだけど、本質的にはrenderされる対象が減っていないので塵が積もるとどんどん重くなる。
なので、ここではfunctionalなReactの教えに従ってrender_hoge()のかわりにfunctional componentを書いていくべきである。もともといたComponent classがpropTypesはだいたいチェックしてくれるだろうから、ほんとうにrenderだけするpure functionを定義すればよいはず。
こうすれば、ファイルをえいやっと分けたり面倒なことはしなくともある程度re-renderを減らせるはず。render_hoge()を定義するならfunctional componentにせよというのはコーディング規約にしてもよいと思う。

とは考えたのだけど、pure React界はこのくらいとっくの昔に普及してそうだなぁ。

おまけ

ラフなレイヤでのComponentをどう切るか問題は、そのGUIアプリケーションでドメインモデルをどう設計するかという問題に言い換えられるので悩むしかない。

— ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年4月6日

データ構造とアルゴリズム

アルバイトも含めてプログラマとしてはそこそこ経験を積んだが、年々データ構造とアルゴリズムの偉大さを噛みしめるばかり。とはいえまだデータ構造とアルゴリズムを理解した！といえるほどメンタルモデルができてないので、その理由についてはうまく言語化することができない。

計算機科学をやる学科では最初の頃にこの分野を習うのだけど、コードを書いた経験が少ないうちはなかなか有り難みが理解できなかった。習うより使わないとわからん度が高い領域ではあると思う。

私はインターネットを使ったシステムを作る屋さんだからだとは思うが、超難しいアルゴリズムを駆使して実装なんてことはほとんどなくて、実際にはデータ構造の定義で難しい問題がシュッと解けることが多い。

つまり実務であてはめるとモデル設計の時点で多くの問題を解決できるともいえる。ではあるのだけど、我々は想像力が足りないのである時点での局所最適なモデル設計をしてしまって、あとから改修するはめになる。

しかし、データ構造の設計は解こうとしている問題、つまりその場その場での要求や仕様に依存するので、一般的な解はなく、我々の経験に暗黙知が蓄積されて各々の問題に対していい感じにやるしかないのが現状かもしれない。

注意しておきたいのは、データ構造とアルゴリズムが可分でデータ構造のみを称揚する意図はないという点である。現実の問題を解くという点ではデータ構造だけで解決できるものはなく、両方を使ってようやくまともな解ができるような気がする。つまり、データ構造もアルゴリズムも両方手足として使えるようになり、全体最適を目指しましょうというオチになりました。

さいきんReact, Reduxでやっている設計

はじめに

ブラウザでGUIアプリケーションを作らなくても良い牧歌的な時代は終わりつつあります。個人的な意見としてはブラウザはドキュメントビューアのままでいて、複雑なGUIアプリケーションはネイティブアプリケーションとして実装されてほしいのですが、そうは言ってもお仕事で人間にとって負担の低いUIを作っていく必要があるのです。
Railsでサーバアプリケーションを書きつつ管理画面はネイティブでなんてことはコスト的に実現できません。かといって長期的に運用されるシステムを作ると、システムを運用するためのUIが操作しやすいに越したことはありません。Bootstrapを使っててきとうなフォームを並べただけの画面を作って怒られた経験はありませんか？ たとえサーバ開発者だとしても、我々は使いやすいUIを求め続ける必要があります。

react, redux

複雑なGUIを作るためのフレームワークも乱立の時代を終えて、react, vue, angularなどに人気とリソースが集約されてきたような気がします。私はたまたまreact, reduxという組み合わせを習得しましたが、本質的にはfluxによるコマンドクエリ責務分離なデータフローができていればどれをつかってもなんとかなるんじゃないかと思っています。

今回作ったもの

みんな大好きTODOアプリです。
TODOアプリ簡単かと思いきや、ユーザ入力がそれなりに多いので実験としてはよい対象だと思います。
我々サーバ開発者はたくさんの入力フォームを相手にしなければならないので、実務と共通する知見も多いでしょう。

ソースコードはこちら github.com

model, stateたち

redux design models

特徴としてはImmutable.jsを使っている点、StateもImmutable.Recordとして実装している点でしょうか。
このTodoStateは自身と他のモデルたちの状態を適切に管理する責務を持っており、ユーザ入力に起因する状態の変更は各メソッドをactionとして呼び出してもらうようになっています。
つまり、TodoStateはTaskやその他オブジェクトのFacadeになるように設計しています。
また、Recordのメンバとしてtasksを持っているので、TodoStateインスタンスをルートコンポーネントに渡せば勝手に値を参照してもらうことができます。

reducer

redux design ducks

ユーザ入力によって発行されたアクションをTodoStateのメソッドへ適切に振り分けるのがreducerの責務です。
このファイルはducksと呼ばれるスタイルになっており、action定義、reducer, action creator, ついでにsagaをひとつのファイルに混ぜ込んでいます。

github.com

reducerにとってのinitial stateをTodoStateクラスとして定義しているので、newすれば良いだけなのも便利です。

非同期処理

redux本体が非同期処理と相性の悪いフレームワークだからか、redux-*はほんとうにたくさん存在します。
今回はその中でもredux-sagaを用いてコードの見た目としては同期的に書けるようにしています。
sagaのcall作用とtask.submit()を共存させるのが今回一番悩んだところでした。結論としては、sagaを経由するactionにTaskインスタンスをそのままぶちこんでやることになりました。(33, 34行目)
正直なところちょっとダサい方法だとは思うのですが、Taskインスタンスではなくidを突っ込んだにしても、select作用でstateを取ってきてからTaskインスタンスを取得するだけなので、パフォーマンスに影響がでない限りはこれでもいいんじゃないかと思っています。
あるいは、task.submitParams()のようなメソッドを作り、requestに必要な情報だけを切り出して非同期処理を引き起こすactionに託すのもありだと思います。

components

redux design components

さいきんPropTypes.funcとtypeするのに疲れてきたので思い切ってactionsはcontextで流すことにしました。
なにか困ったことが起きたら真面目にpropsドンブラコをしていこうと思います。お困りポイントに見当がつくかたはお知らせください。
上の例では、Container Componentで定義したchangeInputTargetアクションとcheckTaskアクションがcontext経由で受け渡されているのがわかるかと思います。

これは内容とはまったく関係のない挿絵です

まとめ

pros, cons

pros

• reducerが見通しやすくなる
• stateとmodelsに対するテストが書きやすくなる
• stateとmodelsをちゃんと設計しておけばreduxを捨てるのも簡単

cons

• Facadeになるstateクラスが肥大化する

所感

• stateクラスがFacadeになっていることが最重要なので、Immutableに依存する必要はない
  • ピュアES6で書くとより移植性が増す
  • しかし個人的にはImmutable + TypeScriptでやりたい
• stateクラスが肥大化する問題はそれこそreduxが得意とする分割統治で解決してはどうか
  • reducerの分割単位をまたいで参照が必要なだけならcontextで流せなくもないと思う
  • reducerの分割単位をまたいで変更が必要な場合はUIから考え直すと良いのではないか……
  • 分割したうえでロジックが複雑化した場合はモデル内の層を増やすしかないかも
• 実際にはTODOアプリ程度の複雑さだとまだreduxを使う要件ではない
  • ちょうどImmutableなStateができているので、Reactオンリーで十分やっていける
• 上記のTaskといったモデルがサーバ上のモデルと一致するかというと微妙なところ
  • UIの表現をするための状態がでてくる
• サーバから渡す初期状態をつくるには(react_on_rails)
  • UIのための状態が存在するのでas_jsonでは力不足
  • Application, Domain, Infrastructureの3層でモデルをつくりInfrastructureの管理する状態をサーバ側モデルの部分集合にすれば、as_jsonでも良い？
• client side validation
  • validationロジックがstateクラスの管理下にあるのは間違いないが、現状のモデル構造では肥大化の要因となって厳しい気がする
  • サーバとvalidationロジック二重持ち問題発生
• Fluxの非同期処理やコマンドクエリ責務分離って所有権と相性いいのでは？
  • 今回はリクエスト発行後にユーザ入力でnameが書き換えられても問道無用でレスポンスが勝つようになっている
  • 非同期処理が入るとレースコンディションが発生しやすいので、プログラマは何らかの方法で解決しておく必要がある
  • コマンドクエリ責務分離もView系クラスとModel系クラスが状態を変更する権限の管理という話になるはず
  • Rust + WebAssemblyに期待したい

ここまで書いて、この記事で提案したモデル構造ではモデル内の複雑さを克服できない問題が残ることに気づいてしまいました。
モデルの複雑さをサーバに押し付けることで対処が可能ではありますが、本質的には解決しないのでまた別の設計論は必要そうですね。
DDDとかに詳しい方の知見をお待ちしております。

GUIを作るならRPCのほうが向いている説 / 読めるようにコードを書くこと

とりあえず200返してjsonで判断するの、GraphQLとRESTの中間ぽい

— ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年2月23日

RESTを前提とした過去の資産に乗っかれなくなって、ロジック、インフラ層の実装量は増えそう。良い悪いではなくトレードオフとして。

— ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年2月23日

なので、JSON RPCとしてイケてる実装に投資するか、枯れた頃に導入するのが美味しそう。

— ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年2月23日

やっぱりRPC最強だったんや

— ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年2月23日

たしかにドキュメントビューア向けならともかく、フルGUIのアプリケーションに向けてRESTのAPIを返すのはなんか違う。いつかのデザイン系の記事で、ユーザはオブジェクトを見つけて〜の行動をしたいのではなく、〜をしたいからアクションを始める云々というのを読んだことがある。もちろんRESTは前者である。

昔はXML RPCとかもあったそうだが、今はまだREST APIの全盛期。GithubからGraphQLが出てきたり、たしかに動詞単語APIでJSON中身いい感じにしてくれやも増えてきている。

しかし、現代のふつうの人はブラウザのアプリケーションとか使ってくれるわけもなく、スマートフォンネイティブのアプリケーションを使い、その使いやすさにも敏感*1なので、UIリッチなアプリケーションに寄せて設計をすると自然とRPC的なAPIができていくのではなかろうか。

個人的な設計の好みとしては、GraphQLのようなぶっといRPCを謎の責務的まとまりごとにエンドポイントを分けて中身はいい感じにやっていくのが良いような気がする。ここでは何をするかではなく、何に対して操作するかという切り分けが出てくるかもしれない。

ブラウザバックのボタンがこの世から消えたらアプリ作ってもいいよ

QAまともにやってないところのアプリだいたいブラウザバックで壊れる

ブラウザでアプリを作るな甘えるな 

上記の文脈などに呼応した思いです。ここでのアプリとはUIリッチなブラウザで動くアプリケーションのことです。

読めるようにコードを書くこと

その他本日の思いがひとつあって、プログラミングは文章を書くのに近いものがあるような気がしてきたという話です。

たとえば、hoge_enabledというbooleanの変数があったときに、!hoge_enabledと書くよりhoge_disabledという変数あるいはメソッドを定義したほうが読みやすいよねという話です。

!hoge_enabledくらい難なく読める、確かにそうですが、これを読み解くときにhoge_enabledの中身がtrue, falseどちらかを確認してから反転し、そのときの値を意識しながら&&の続きを読むといったスタックを多めに使う認知が働きます。対して、hoge_disabledと書かれていればプログラマ英語がふつうにできる人は、ほぼ無意識レベルの認知で読み下すことができます。なので、あきらかに後者のほうが読みやすいのは間違いないです。ここで、それくらい読めるというのもよいですが、!を使って書き下すかどうかで自転車小屋の議論をするよりhoge_disabledを選んだほうが生産的です。

まとめると、変数名は本当に重要なので手を抜くな。頭を少しでも使う処理は切り出しておけということになりそうです。こんな知見たぶん50年くらい前には発見されているでしょうが、独立に気づいたので主張した次第です。

ここで少し気になったのが、コードを書くうえで英語ネイティブの人は有利なのでは？という点です。データがないので何もいえませんが、もしかしたら有意な差は出ているかもしれません。しかし、我々はいまさら日本語でコードを書ける気がしないし、言語が統一されていると世界レベルで知見を共有できるので我々は英語を書いて読み続けるしかないのです。

*1:というかこのUIわけわからんてなると投げ出して罵倒レビューをしていく

利尿作用困る / gemのjQueryなくなってほしい / サブカルクソにおい棒

ユーザから手数料や課金を取らないwebサービスでは、ユーザ属性の推定は必須なのだろうなぁ。その点ではFacebookは属性がわかりやすく、なるほど儲かるわけだ。

— ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年2月21日

昨日の続きなんですが、webで広告一本でお金稼いでいくなら社会属性推定やらないと競争力維持できないのではというあれ。さらに、webサービス自体のプラットフォームが他のサービスとは違う集団に向けて提供されていると広告市場としてもより差別化ができるのだろう。

この世の飲み物から利尿作用だけ無くなってほしい

大変な頻尿持ちなので会議とかでかなり困っている。水自体にも量飲むと利尿作用があるような？

ハマりを経験すると強くなれるけど、gemでハマるのはしょーもない

— ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年2月21日

nested_formとsimple_formの組み合わせでハマり、よく見たらREADME.mdに有用な情報が書いてあるパターン。

しかし、この手のviewを弄るgemはだいたいjQueryに依存しており、バグの温床になりやすい。実際にnested_formの挙動はだいぶ怪しい。DHHも脱jQueryに舵を切っているみたいなので、gem界もReact(web) Componentとして機能を提供するオプションを用意してくれないだろうか。React Component自体は全然難しくないので。。。

ほっこり系こわい

— ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年2月21日

サブカルクソという呼称を好んで使う程度にはサブカルクソ界隈が好きです。

今までに発言したサブカルクソタームで一番怒られたのは「サブカルクソにおい棒」です。

gyazo.com

正しくはリードディフューザーといいます。京都のサブカルクソほっこりカフェにはだいたい設置してあり、たまに加減を間違って公害になっている。最悪。