最近とくに眠気がひどい。
朝、めっきり起きられなくなった。
React 復習メモ（その 4）
RxJS + Redux-Observable を試す
Redux で非同期 Action を捌く実験の続き。 今回は新たなアプローチとして RxJS を試してみる。
動機
「Using socket.io in React-Redux app to handle real-time data.」という記事の最後（結論部分）に、こんな記述を見つけた。
This way of handling real-time data using redux-thunk may be okay for a small app which doesn’t require lot of complexities. But I would encourage you to go through how to use redux-observables and RxJS, if you plan to build a real time app to handle multiple observables and to chain/merge them.
リアルタイムデータを Redux-Thunk で捌く方法は、さして複雑ではない小規模のアプリならばべつだん問題はない。しかし、複数の Observable に対して chain / merge を扱うようなリアルタイムアプリを構築しようとするなら、Redux-Observable と RxJS の使い方を理解することを勧める。──ということらしい。
面白そうなので、ちょっとだけかじる。
React 復習メモ（その 3）
Redux-Thunk を試す
前回は、Redux を使用して同期的なイベント処理の素振りを行なった。 今日はもう一歩がんばって、Redux-Thunk を用いた非同期イベントのハンドリングを試そうと思う。
Redux-Thunk とは
公式の説明によれば、こういうことらしい。
Redux Thunk middleware allows you to write action creators that return a function instead of an action. The thunk can be used to delay the dispatch of an action, or to dispatch only if a certain condition is met.
Redux Thunk ミドルウェアを使用すると、（Action オブジェクトではなく）関数を返す ActionCreator を作成できる。
Thunk は、以下のことができる。
- Action の dispatch を遅延させる
- 特定の条件を満たす場合にのみ Action を dispatch する
上記を組み合わせることで、たとえば非同期処理の完了を待ってから Action を dispatch する・非同期処理の結果に応じて dispatch する Action を変えるといった芸当が可能になるらしい。
React 復習メモ（その 2）
Redux と仲直りする
一昨日、Node.js 再入門の日記で Flux を試した。 今回はこの勢いで React な方向に歩を進めて Redux と仲直りしたいと思う。
Flux ネタはいろいろな技術を組み合わせすぎてサンプルが繁雑になってしまったため、今回は React に焦点を絞る。
本日の題材
本日の題材の元ネタは、「WEB+DB PRESS Vol.92」にあったカウンタ的なプログラムである。
[+] ボタンを押すとカウントアップ、[-] ボタンを押すとカウントダウンするだけのものだ。
面白みはないが、今はきちんとした日本語の説明を書く余裕がないため、後からコードを読み返して思い出しやすいようサンプルはシンプルな方がよいだろう。
Node.js 再入門メモ（その 7）
Flux と仲直りする
こちらの話を先に読んだ方がよいかも。 Node 再入門というタイトルになっているが、かなり React 寄りのネタである。
今回は、以前書いた SocketIO 製の「リアルタイムいいねボタン」的なアプリケーションのコードに Flux を適用してみようと思う。
ちなみに「リアルタイムいいねボタン」とは、アクセスしているすべてのユーザのうち、誰か1人でも「いいね！」ボタンを押すと、他のブラウザでも一斉にデータが書き換わるというものである。
今まで、Flux に関する概念的な説明はさまざまなところで目にしたが、正直いまひとつ掴みきれていない。 手を動かさないとたぶん体得できないのだろう。
なんで今さら Flux
Flux が、ソースコードが整理された状態を保つためのすぐれた方法論の一つと言われているからである。
前回のコードは、子コンポーネントから親に何らかの通知を行う際に、親側に定義したメソッドを子側からコールバックする必要があった。 コンポーネントの入れ子階層が深くなれば、このやり方は破綻する。
Flux を適用すると、複数のコンポーネント間の連携やビジネスロジックとのやり取りなど、アプリケーション全体に亘ってデータの流れが整流化されるらしい。 トレードオフとしてコードは冗長化されるが、短いコードが常に正義とは限らない。
僕にとって Flux が取っつきにくいと感じる理由は、Action や Dispatcher や Store といった登場人物が、それぞれどのような責務を担っているのかいまひとつイメージできないからである。 天下り的ではあるが、一旦 Flux の作法を（半ば盲信的に）全肯定した上で、流儀に従ってコードを書き換えてみようと思う。
React 復習メモ（その 1）
なにこれ
以前、少し囓ったときに、メインの日記の方に多少学習の進捗を 1 つ 2 つ書いた。
tercel-tech.hatenablog.com
しかし記事化コストが高すぎて、学習の足を引っ張りかねなくなったのでやめてしまった。
最近、再び React 熱が再燃したので、自分用の思い出しメモとして、ここに書き捨てておこうと思う。 ──と考えていたのもはるか昔のことである。
本来、この記事はかなり以前に書いたものである。 少なくともこの辺の話をする前に公開しておきたかった。 しかし、書いているうちにだんだん何の役に立つのか分からなくなってしまい、モチベーションが大幅に低下したので放置していた。
今更こんな記事を投稿して何になるのか分からんが、記事数を稼ぐために置いておく。
Node.js 再入門メモ（その 6）
今日のテーマ
複数のブラウザ間で情報をリアルタイムに共有したり、通知を送受信したりするための仕掛けを試して、「リアルタイム「いいね」ボタン」をつくる。
壮大な完成イメージはこんなの。 とってもスタイリッシュ。
http://localhost:3001/ にアクセスしているすべてのブラウザで、表示が連動している。 つまり、片方のボタンを押しただけで他方の情報まで同時に更新される（時間的な遅延なしで）。
昨日までのモジュールに加え、SocketIO を使う。
まだ「初めてやってみた」「書いてみたら動いた」レベルなので、コード中のアンチパターンが多そう。 取り敢えず動く状態にするまでに時間を掛けすぎてしまい、日記としてまとめる気力が失せてしまった。 そんなわけで、ここから先日本語はほとんど登場しない。 まぁいつもの事だが。