会津ラボ

「スムーススクロールのライブラリは使いたくない」この要件に沿ったページトップへ戻るスムーススクロールの最小構成は、どの程度だろうか？ 昨今の縦長基調のデザイン構成において当然のように設置される「ページトップへ戻るボタン」であるが、スムーススクロールが実装されているサイトを多く見かける。ボタンをクリックすればページ上部まで、なめらかにスクロールする機能だ。 これを実現するには、JavaScript ライブラリを使うことが一般的だけれど、その導入ともなると労力を要する。できるならば可能な限りスケーリングしたい。 このエントリーでは、JavaScript ライブラリを使わないスムーススクロールの最小構成を紹介しよう。 これこそスムーススクロールの最小構成だ スムーススクロールの最小構成は、HTMLとCSSだけで機能する。あわせて７行程度の記述で済む。以下コードを見てもらうのが早そうだ。 ご覧のとおりHTMLはページ内リンクを設置していることがわかると思う。これだけでは瞬時にスクロール位置が変わるもので、断じてスムーススクロールとは言えない。 そこで注目したいのが、CSSプロパティの scroll-behavior だ。scroll-behavior は、スクロールの振る舞いをコントロールするプロパティで、対象セレクタでスクロールが発生したときに機能する。ただしマウスホイール操作によるスクロールは影響を受けず、ページ内リンクや JavaScript の scrollTo() メソッドなど、指定位置までスクロールするケースにおいて適用される。 URLの # (ハッシュ) を消す なめらかにスクロールするだけで構わないなら、以上の内容で完成しているけれど、URLにアンカーリンク（#page-top）を含んでしまう。わずらわしいのであれば、つぎの記述でアンカーリンクを消せる。 果たして、URLのアンカーリンクを削除できたことだろう。だがしかし、アンカーリンクを消すことがユーザー体験において、どのような効果をもたらすか怪しいところだから、扱いには気をつけてもらいたい。 フォーカスをコントロールする リンクをクリックしたことで a タグにフォーカスが移る。スクロール位置はページ上部を表示しているにも関わらず、見当違いのところにフォーカスがあるわけだ。Tab キーで画面操作するユーザーに最悪のユーザー体験を与えかねない。 したがって、スムーススクロール実装にはフォーカス管理を加えると良いだろう。要点としては、ページ上部にある主要なコンテンツにフォーカスを移す具合だ。 まとめ JavaScript ライブラリを使わないスムーススクロールの最小構成の紹介だった。 フォーカスをコントロールする項目で、onhashchange イベントハンドラのコールバックとしてフォーカス管理を記述している。これは前項の、URLアンカーリンクを消す対応をしている前提で活用してみた。無論、当該イベントハンドラで構わないけれど、ページトップへ戻るボタンのクリックイベントに反応する形で実装しても良さそうだ。臨機応変に要件に沿う対応を心がけたい。

「React Context API の状態管理が煩雑だ」 状態管理ソリューションの代替策に挙げられる React Context API。コンポーネント間の props のバケツリレーを回避できるソリューションであるが、たびたび引き起こされる煩雑さに悩まされる。 その要因は、コンテクスト( Provider )を展開するコンポーネントでローカルstate を定義するからではないだろうか。 多くのケースで、ルートに位置するコンポーネントに展開する。しかも複数存在することもある。こうなると該当コンポーネントで必要に応じてローカルstate を用意しなければならない。それに加えてコンテクストを外部ファイル化しているような場合、さらにややこしい。 ローカルstate とコンテクストの結びつきを目で追いかけなければならないのは保守性に欠けるうえに見通しが悪くなってしまう。可能ならば、ローカルstate とコンテクストの結びつきが明瞭かつプロジェクトのファイル構成に従いたい。 そのニーズにマッチしたライブラリがある。 このエントリーでは、Context API のラッパーライブラリ「constate」を紹介したい。 Context API とは？ Context APIは、任意階層のコンポーネント間でデータを共有する仕組みを提供するものだ。propsの明示指定を強制することなく、コンポーネントツリー間でデータを参照できる。これは、React v16.3で導入されたもので16.x以前のレガシーContext APIとは相容れない。将来のメジャーバージョンで削除される予定とのことだ。 https://reactjs.org/docs/context.html constate について Write local state using React Hooks and lift it up to React Context only when needed with minimum effort. https://github.com/diegohaz/constate 導入 設置 使用例 かんたんな使用例として、モーダル実装を思い出してほしい。 モーダルを開くトリガー要素はいたる所に散らばっていて、それを梱包するコンポーネントとモーダルコンポーネントが兄弟関係にあたる構造は珍しくない。いかにも相性が良さそうだ。 まとめ…

「 Mildom（以下、ミルダム）は、コメント欄を非表示にできないの？」ライブ動画配信サービス「ミルダム」の視聴に際して、不便を覚えることがある。 ディスプレイサイズを贅沢に専有できる環境ならば思いつくこともないだろうが、ブラウザサイズをタイトにすることで動画が小さくなって視聴しにくい。 そもそもミルダムのサイトは、リキッドレイアウトよろしくメインカラムが可変してレイアウトを維持する。ところが固定幅のコメント欄に押しやられた動画はアスペクト比を保ってリサイズするから小さくなってしまうわけだ。 このような観にくい状態は、レスポンシブデザインの弱点のひとつで、ちょうど調整しにくい時空の狭間のようなもので、ミルダムにおいてもビューポート900px以下でコメント欄を非表示するように施している。 一方で、ヘッダー画像が配されているイベントページのようなレイアウトの場合に限り、コメント欄非表示タブが用意されている。これを通常レイアウトにも設置してもらいたいところだが、いまのところ実装の様子がみられない。 なんとしてもコメント欄が煩わしい場合は、Chrome デベロッパーツールでコメント欄カラムを非表示にしている次第だ。 それもいい加減めんどうくさい。そんなわけで Chrome 拡張機能をつくってみたい。 Chrome 拡張機能とは？ Googleが開発したウェブブラウザ「Google Chrome」に追加するソフトウェアプログラムで、標準では備わっていない便利な機能を体験できる。 Chrome 拡張機能の入手は、Chrome ウェブストアに公開されているものをインストールする手段と、Chrome 拡張機能ポリシーに従って配布されたものをインストールする２パターンが考えられる。なお規約違反した外部拡張機能に関しては望ましくないソフトウェアとしてフラグが立てられるとのことだから留意しておきたい。 インストールしたものは、Chrome 拡張機能の管理画面（chrome://extensions/）から確認できる。アンインストールしたり機能効力を切り替えたり、開発時におけるデベロッパーモードやパッケージ化されていない拡張機能を読み込む機能も備わっている。 開発環境を準備しよう Chrome 拡張機能の開発にあたり「chrome-extension-webpack-boilerplate」を活用して効率化を図りたい。 当該パッケージは、Chrome 拡張機能を作るのに必要なソースコードを備えた雛形環境で、開発の着手が容易になっている。 Node.js のバージョンが6以上であることを確認する 以下コマンドで Node.js のバージョンを確認のうえ、6以上ではない場合は適宜アップデートする。 GitHub リポジトリからクローンする 作業するディレクトリで以下コマンドを実行する。なお git がインストールされていなければ 圧縮ファイルをダウンロードすればよい。 https://github.com/lxieyang/chrome-extension-boilerplate-react パッケージをインストールする パッケージマネージャのインストールコマンドを実行する。 開発サーバーを起動する フロントエンド開発で馴染みの webpack-dev-server を起動する。 http://localhost:3000 にアクセスできれば無事 webpack サーバーが立ち上がっているものと考えられる。 それと同時に「build」フォルダが生成されていることを確認できる。 Chrome に読み込ませる 前節で触れた「build」フォルダを Chrome に読み込ませることで、開発中の拡張機能を適用できる。その手順を確認していきたい。 開発環境の準備は以上で完了だ。…

Reactアプリの多重クリック防止について考えてみたから、共有かたがた備忘のために記しておきたい。 多重クリックとは、ボタン等のユーザーアクションから発せられたイベントが重複処理されることを指す。お問い合わせフォームの送信が想像しやすいだろうか。入力した内容が重複して送信される問題で、まったくもって無駄なリクエストである。 そんなことからアプリケーション全般に多重クリックや二重送信を防止する施策が求められ、それぞれの要件にあった手法で実装されている。無論、Reactアプリも、その例に漏れない。 多重クリックを防止する方法 Webアプリの多重クリック防止のデザインパターンに、非活性化させる手段を思い出す。フラグ判定で処理中は非活性化させるというものだ。これを以下に再現してみた。 コンポーネント冒頭の const [processing, setProcessing] = useState(false); で、state定義している。これをフラグに見立て if (processing) return; で判定するといった具合のものだ。 多重クリック防止のアプローチについては納得いくものだけれど、state を活用したフラグ判定は不適当じゃないか、というのが肝心なところ。 問題 state を更新することで、コンポーネントの再レンダリングが強制される。つまり上記ソースコードならば、コンポーネントをマウントしたときと非同期処理が走ったときレンダリングをスケジュールしている。画面上の更新を求めていないにも関わらず、不要にレンダリングをすることはパフォーマンスに影響を与えかねない。 代替案 state によるフラグ判定の代替案として、以下に改修してみた。 useState は useRef に変わり state の更新を排除したことに気づくと思う。refオブジェクトは一般にDOM参照に活用されている印象があるが、公式で次のように述べている。 はい！ useRef() フックは DOM への参照を保持するためだけにあるのではありません。“ref” オブジェクトは汎用のコンテナであり、その current プロパティの値は書き換え可能かつどのような値でも保持することができますので、クラスのインスタンス変数と同様に利用できます。 https://ja.reactjs.org/docs/hooks-faq.html#is-there-something-like-instance-variables またコンポーネントが存在しているあいだ書き換え可能なオブジェクトとして保ち続けて、その値を変更しても再レンダリングが発生しない。 したがって Refs の活用は、簡易な多重クリック防止のデザインパターンに相性がよい。再レンダリングによるパフォーマンス悪化や思いも寄らない副作用の回避に一助することだろう。 とはいえ Refs 活用一辺倒でよいというものでもない。たとえばボタンクリックと同時にdisabled属性を付与したりボタンテキストを変えたりする場合、再レンダリングが必要で、適宜コンテンツに最適な対応が求められそうだ。 まとめ Reactアプリの多重クリックを防止する最適解についての共有だった。 わたし自身、Refs の真価に気づかず、Stateを活用しているケースが見受けられた。一方でフォームヘルパーを使うケースもあるしフェッチライブラリならば処理状態を返却してくれる。一概に当該ソリューションが最適解というわけではないけれど、ユースケースとして覚えていて損はないと思う。 このエントリーが、あなたのクリエイティビティを刺激するものであると期待したい。 React Hooksに対応した複数のonChangeハンドラを処理する書き方