会津ラボ

Gatsby + WordPress 構成の場合におけるメールフォームは、どのように実装すればいいだろうか？ このエントリーでは、Gatsby のメールフォームから Contact Form 7（WP プラグイン）にアクセスしてメール送信する方法を共有したい。 はじめに Netlify にホスティングするならば Netlify Forms を選ぶだろうし、それ以外では、ホスティング先に関わらず静的サイトからアクセスできるフォームサービスも、いくつか選択肢がある。その、いずれもリーズナブルで活用できるし、専用の Web API エンドポイントとアクセスキーを設定するだけ、という簡単なものだ。 ただ、メールのフォーマットに不自由さがあったり、利用回数による課金の可能性を考えると不満がないなんてことにはならない。できるならば制約を抱えたくない。そもそも Headless CMS 枠に WordPress を用いているなら、そこでどうにかしたい。 まず候補に上がるのが、Contact Form 7 だ。WordPress のメールフォーム実装で普遍的な知名度を誇る WP プラグインである。WordPress を Headless 化していることで、各種機能やデータに REST API を介してアクセスできるようになっているわけだから、Contact Form 7 も使えるに違いないというわけだ。 動作環境について WordPress 側の準備 まず WordPress 側の準備をしよう。 以下が、メールフォームの実装に関わる WordPress プラグイン一覧だ。適宜インストールして有効化しておいてほしい。 必要なプラグイン Step 1 wp-config.php に定数を定義する。これは…

VSCode のテーマを Monokai Pro から GitHub Theme に変更したことを報告する。 「VSCode のテーマなにがいいだろ…」だったり「ソースコードが見ずらいような気がする…」など配色テーマに満足していないなら、このエントリーが一助となるかもしれない。 はじめに そもそも VSCode のテーマである Monokai Pro に不満はない。むしろ使い続けたいほどだ。なのに、なぜ長らく採用していた Monokai Pro を変更しようと思い至ったのかについて、まずは話しておこう。 Monokai Pro とは Monokai Pro は、従来からの Monokai 配色を VSCode 用に再設計したカラースキームで、ソースコードの配色はもちろんのこと外観テーマやアイコンセットまで及ぶ妥協のない配色テーマになっている。 また Monokai 配色の生みの親（Wimer Hazenberg 氏）によるオリジナル製で “Monokai” を冠したカラースキームにおける本家本元として人気を博している。さまざまなコードエディタで Monokai の配色テーマを含まないものはないほどだ。 そもそも、Monokai の火付け役となったのが、Sublime Text （コードエディタ）にデフォルトテーマとして実装されたことから始まる。それまでのエディタと比べても、明らかなモダンぶりに魅了されたエンジニアは少なくないと思う。 わたし自身、Sublime Text 以降のエディタ遍歴のいずれにおいても Monokai 配色を頑なに採用してきた。 配色テーマを変更した動機 さて、そんな長い付き合いの Monokai を変更しようとした事由としては、OS側の外観モードとミスマッチではないかと感じたことに端を発する。 Mac、Windows に関わらずライトモードを採用していて、モニターの中の景色は白を基調として総じて明るい。そんななかコードエディタだけダーク風味であることに「あれっ？」となったわけだ。いまさら感の強い話ではあるけれど、気になってしまったらどうしようもない。 最近、目が霞むのも、こういった影響が有るのだろうか？…

React Hook Form を使えばフォーム周りの state を一元管理したり、バリデーションを加えたり拡張できるけれど、Draft.js の値も組み込めるのか、というのが気になるところだと思う。 「React Hook Form で、Draft.js の state を管理したい」「React Hook Form と Draft.js を組み合わせたい」など、お困りなら力になれるかもしれない。 はじめに リッチテキストエディタを単一に配置する程度ならば、個別に state を設けるのみで済まされる。これは Draft.js 公式のドキュメントに掲載されているように、ひとつの <Editor> に対して、ひとつの editorState を設定するというものだ。 だけど実際には、リッチテキストエディタもフォームの一部であることが自然で、そこには入力フィールドがあったり、選択フィールドがあったり、チェックボックスがあったりすることだろう。 そうするとフォームヘルパー系のライブラリ（react-hook-form）によるフォーム管理が見込めるわけで、そんななか Draft.js の <Editor> だけ別途 state を定義しているのは残念に思えてくる。 どうかこれも一緒に管理できないものか、というのがこのエントリーの根幹になっている。興味を引く内容であったならば引き続きお付き合いいただきたい。 React Hook Form と Draft.js を組み合わせよう React Hook Form と Draft.js の組み合わせにおける最小構成を用意させてもらった。 実装環境 各種関連パッケージのバージョンは、以下コードを確認してほしい。 コンポーネント React コンポーネントは、以下コードを確認してほしい。…

コンテナクエリのプロトタイプが利用できるようになって、マークアップエンジニア界隈は大きな注目を集める一方で、 Chrome Canary でフラグを有効にしなければ機能しない対応状況が、いまひとつ現場に熱をもたらさない要因となっている。 CSS に関心がある、あなたにおかれても「いつコンテナクエリを使えるのだろう」と首を長くして待たれていたことだろう。そんななか GitHub の GoogleChromeLabs アカウントからコンテナクエリの polyfill が公開された。 このエントリーでは、Container Query Polyfill について紹介したい。 CSS コンテナクエリとは CSS コンテナクエリは、対象の親コンテナのサイズに応じてスタイルを適用するためのものだ。 サイズに応じてスタイルを定義する現行の手段といえば、CSS メディアクエリ（@media）が用いられ、ビューポートを基に切り替えている。しかし、このアプローチでは制限があるとして、CSS コンテナクエリ（@container）が登場したと思われる。 たとえばサイドカラム内のコンテンツなどは、ビューポートを基にするより、親コンテナであるサイドカラムのサイズに基づいてスタイル定義したほうがスマートになる好例じゃないだろうか。 モジュラーな設計が求められる昨今のフロント開発にマッチするとして期待されている。 Container Query Polyfill を適用しよう それでは、CSS コンテナクエリ用 polyfill の container-query-polyfill を適用してみよう。 使い方 ES modules に準拠したセットアップならば、以下のコードで Polyfill を適用できる。 import に際して、パッケージがインストールされている必要があるから、事前に yarn add container-query-polyfill などで用意しておこう。 従来の読み込みが求められるセットアップならば、以下のコードで Polyfill を適用できる。 要件的に、CDNサービスから読み込めないならば、container-query-polyfill リポジトリを git clone するなりダウンロードするなどしてから…

HTML 入門直後だと「どんな HTML 要素あるの？」だったり「どんなツールが必要なの？」だったりは、当然のように湧き上がる疑問だと思う。 わたし自身も、HTML 入門に踏み込んだころに同様のことでモヤついたのを覚えている。 数ある HTML 要素のなかから、どれを優先して覚えればいいのか、ポピュラーな HTML 要素を知りたいと望んだり、HTML を書くにあたって必要とされるツールはどれなのか、プロの立場から入門者の目線に立ってもなお役立つツールを教えてほしいと願ったりしたものだ。 このエントリーでは、そんな悩みに回答させてもらいたい。 HTML 要素を知る HTML コーディングにおいて HTML 要素の理解は、なによりも要求されるわけだが、WHATWG 勧告の HTML (Living Standard) で 100 個を超える HTML 要素が存在する。それらをあまさず習得すれば最善だろうけれど、実際に HTML コーディングしてみると、そのほんの一部しか使っていないものである。 いずれは全部覚えてもらうとして、これから HTML を覚えようという場合においては、頻出する HTML 要素から始めてみてはどうだろうか。 ここでは、ポピュラーな HTML 要素をピックアップして、お届けしよう。 基本構成 基本的な構成は、DOCTYPE宣言から始まる一連の HTML 要素で作られる。 先頭行の <!DOCTYPE> は、html 文書のバージョンを定義するためのもので必須で配置しなければならない。 <html> は html ファイルの基幹となる要素で、ほかすべての要素を包含している。 <head> は html ファイルに関するメタ情報を含める。つまりタイトルや文字エンコーディング、スタイルなどのことで、目に映らないものを対象とした梱包要素だ。 <body>…

ISO形式の日付データをミリ秒にしなければならないケースといえば、UNIX時間の参照や処理経過時間の計測などだろうか。UNIX時間においては、秒単位であるが、まず日付データをミリ秒に変換する工程が必要だ。それから処理経過時間の計測では、差分を算出するためミリ秒に変換することもあるだろう。 このエントリーでは、ISO 形式の日付をミリ秒に変換するソリューションについて共有したい。 ミリ秒に変換する Date.parse() Date.parse に渡した文字列（ISO形式）に対する、1970 年 1 月 1 日 00:00:00 UTC からの経過ミリ秒で変換している。 Date.prototype.getTime() getTime による 1970 年 1 月 1 日 00:00:00 UTC からの経過ミリ秒で変換している。 数値型に変換するショートハンド + 記号（ショートハンド）によって Date オブジェクトを数値型に変換している。 UNIX時間に変換する UNIX時間は、UTC時刻における1970年1月1日 00:00:00 からの経過秒数で表される。つまりミリ秒を秒に変換できれば目的が果たされる。 では、その方法を見ていこう。 上述の手段によってミリ秒を参照できているから、それを 1000 で割ればよい。

Create React App の webpack 環境を eject することで隠蔽された構成ファイルが、プロジェクトフォルダに顕現する。それらファイルを直接参照できることによって webpack や babel、ESLint など、カスタマイズを可能にしている。 ところが、複雑な構成ファイルを扱うにも抵抗があったり、eject すると元に戻せなかったりとネガティブな感情を覚えてしまう。 そこで、このエントリーでは、eject せずに Create React App をカスタマイズする方法を紹介したい。 カスタマイズの準備 eject せずに Create React App をカスタマイズするにも、多少の準備が必要だ。決して難しいことではないから引き続き付き合ってほしい。 パッケージをインストールする webpack 環境をオーバーライドするのに必要なパッケージをインストールしたい。必要なパッケージは次の、 react-app-rewired customize-cra をインストールする。ついては、以下コマンドを実行してほしい。 開発環境をカスタマイズするためのパッケージであるわけだから、いずれのコマンドも –dev や –save-dev オプションを付与することで、devDependencies 所属のパッケージとしてインストールしている。 package.json を修正する package.json の scripts 項を修正する。 ここでは、eject コマンド以外の react-scripts を react-app-rewired にしているだけだ。 もともと react-scripts が隠蔽された構成ファイルを参照していたところに、react-app-rewired にすることでカスタム用構成ファイルを介入させる作りだと考えられる。…

「スムーススクロールのライブラリは使いたくない」この要件に沿ったページトップへ戻るスムーススクロールの最小構成は、どの程度だろうか？ 昨今の縦長基調のデザイン構成において当然のように設置される「ページトップへ戻るボタン」であるが、スムーススクロールが実装されているサイトを多く見かける。ボタンをクリックすればページ上部まで、なめらかにスクロールする機能だ。 これを実現するには、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 導入 設置 使用例 かんたんな使用例として、モーダル実装を思い出してほしい。 モーダルを開くトリガー要素はいたる所に散らばっていて、それを梱包するコンポーネントとモーダルコンポーネントが兄弟関係にあたる構造は珍しくない。いかにも相性が良さそうだ。 まとめ…