things2018-11-08ブロック要素の縦横ど真ん中に要素を置くためのCSSCSSに慣れてないころ、こういう感じで縦方向と横方向同時に中央揃えしたいだけなのに意外と出来なくて困った記憶があります。css"みたいなキーワードで検索しても、「7つ方法があります!」って言って、順に説明してるページがトップに来るので、えっ、どれ...ってなると思う。center;これを追加するだけでOK(IE9なんてもうサポートする必要無いし、サポートが求められるようなプロジェクトからは逃げ出そう)こちらJSbinのサンプルコード。jsbin.comだけど結局これも、なんで3行も要るの?justifyってなに?ってなると思うし、正直そう思います...。なんでこんなネーミングになったんだろうflex。通常、切り替え時に何らかの非同期処理を呼ぶことになると思います。それがサーバ側での更新処理を伴う場合、通常はレスポンスを待ってからユーザーへのフィードバックをするかと思いますが、その間ユーザーを待たせてしまうことになり、またレスポンスタイムはユーザーの環境に左右されるため、特に頻繁に押されるボタンの場合にはUXを損ねてしまう可能性があります。実際の動きを見てみます。Conditionerを使います。Networkに設定し、通信状態が非常に悪い状況を作ります。秒単位のラグが生まれてしまいます。Web)また、こちらはメルカリの設定画面ですが、二重送信や完了前の画面遷移を防ぐため、このように画面全体をブロックしてしまうのもよく見る実装です。App)ユーザーの操作をブロックせず、かつ、直ちにフィードバックする実装が望ましいと言えます。Updates一方、Twitter、Facebook、InstagramのLikeボタンは、ボタンを押した瞬間に処理が成功したものと見なされて即座にフィードバックがあり、その後バックグラウンドでAPIコールをする実装になっていると思われます。これがもしLikeの更新処理に失敗すると、その場では成功したように見えていても、のちに画面を更新すると元に戻ってしまいます。App)これは、そもそも端末がオフラインの状態でボタンを押した場合でも同様の動きになっており、特にアラートなどは出ません。その後リクエストがタイムアウトするまでにオンラインへ復帰すれば、pendingとなっていたリクエストが実行されるようです。Updatesと呼ぶようです。サーバからのレスポンスをハンドリングするかどうかについては、toggleのUIが持つ意味によって対応が分かれているようです。iOSアプリの場合、前述の通り、お気に入りは失敗しても無視、つまりサーバ上の状態とアプリ上の状態が異なったままで、他のアクションや画面遷移が許されていました。画面をリフレッシュしてサーバ上のデータと同期したタイミングで、暗黙的にズレが解消されることになりますが、これが問題になるケースは稀であるという判断で許容しているものと思われます。Updatesであるものの、リクエストが失敗したタイミングでUISwitchの状態を元に戻していました。画面上のLikeボタンが勝手に動くため、ユーザーにとって多少の違和感はありますが、設定の状態にズレが生じないことの方を重視した結果と思われます。Updatesにおいて、非同期処理の結果を画面に反映させるべきかどうかは、1セッションにおける実行頻度が高いかどうかコンバージョンに直接影響するかどうか、またはユーザにとっての重要性が高いかどうかサーバ側と状態が乖離していても、その後アプリ上で問題が起きないかどうかといった点を考慮した上で決めるのが良さそうです。Updatesの場合にはそうすることが出来ません。これをReactで実装する上では、いくつかの方法が考えられます。Like状態の参照先をもとに、2つに分けます。Like状態はcomponentの内部stateを使うLike状態をcomponentの内部stateとして持ち、ボタンイベントに合わせてtoggleする方法です。Debuggingサーバから返されるレスポンスについては一切責任を持たない、最もシンプルなやり方です。この方法の場合、Like状態の参照がstoreから切り離されてしまうので、componentがmountされたあとに別のトリガーによってstoreのLike状態が変わってしまうと、リアクティブに追随できなくなります。他の場所でも同じLike状態を表示しないといけないケースでは、何らかの方法で状態を共有しなければならなくなります。Like状態はstoreを直接参照するLike状態は、storeにあるstateを参照します。その上で、ボタンイベントがトリガーされた時点で、非同期処理の手前で、レスポンスを待たずにstoreのstateを更新してしまいます。レスポンスを受けてその後stateを再度更新するかどうかは、前述の通り、状況次第です。レスポンスが失敗のケースでundoする場合、予めstateの履歴を保持しておく必要があるかもしれません。以下のようなライブラリを使うと、stateにhistoryを持たせることができます。リクエストの成功/失敗時に、stateがcommit/revert可能になるようです。stateに更にstateを持たせている状態になってしまうのがちょっと複雑に思えて、個人的には気になるところです。reverted.その他この記事では「toggle型UI」という風に呼んでいますが、画面遷移を伴わずに更新処理が走るUI(例えばレーティングなど)であれば、状態が3種類以上あったとしても同じ議論になると思います。なにか気づいたら、追記しようと思います。オフラインでも使えて早いので、かなり使える子です。(ということにさっき気づきました。この同じ辞書を呼び出すことが出来ますよね。いつのまにか便利になったもんですなあ。