Reactにおいて、useEffectのユースケースとして知られているのが、DOMノードに直接アクセスしなければいけない場合です。useRefでDOMノードをrefオブジェクトに取得し、エフェクト内からDOMノードにアクセスするというのがその場合の基本的なやり方です。 このようなuseRef + useEffect の使い方は、問題ない場合もありますが、実は別の手段を使った方がいい場合もあります。その場合に別の手段として適しているのがrefコールバックという機能です。 そこで、この記事ではどのような場合にuseRef + useEffectよりもrefコールバックが適しているのか、そしてrefコールバックを使う場合の注意点について解説します。 復習: refコールバックとは React DOMでは、組み込み要素（divなどHTMLの要素）に対してrefという特殊なpropを与えることができ

今日のXでは、イベントハンドラの関数名についての話題を見ました。元の投稿はこちらです。要するに、次のhandleClickのようなhandleイベント名という命名は良くないということです。 const handleClick = () => { ... }; <button type="button" onClick={handleClick} /> これについて少し考えたので、せっかくなのでアウトプットしておくことにしました。 この記事の目的 考えたことを頭の中に残しておくのがもったいないので、文章の形にしておく。 色々な意見が出る問題であり、ベストな答えは無いので各々好きにすれば良いということを、読者に理解してもらう。 とはいえ、筆者の考えに納得して同じ考えの人が多いと嬉しいので、なるべく納得してもらう。 筆者の考え 自分の考えとしては、むしろhandleClickいいじゃん！　どんど

皆さんこんにちは。昨今の技術選定においては、「シンプルさ」が重視されることが良くあります。 特に「イージー VS シンプル」という対立軸が持ち出されることが多く、規模の大きなアプリケーションを作る際には「シンプル」側の技術を選定するほうが有利だという論調がよく見られます。 本当にそうなのか、あるいはそもそも「シンプル」とはどういう意味なのかについては皆さんそれぞれの考えがあるでしょうから、この記事では深入りしません。 代わりに、実際どのような技術がシンプルなのかが気になるところです。そこで、今回は筆者が比較的得意なWebフロントエンドのUIライブラリの領域において、どのライブラリがシンプルなのか調査してみました。 React 先日プロジェクトでReactを使ってみたら、本当にシンプルな実装でやりたいことが全部できちゃうというか、すぐに画面に反映できて開発効率的にも良いなと感じました。 フロ

皆さんこんにちは。最近React界隈を騒がせているReact Server Components (RSC) には、筆者も興味を寄せています。以下の記事でもRSCについて説明しました。 この記事の中で少し言及しているのが転送量の話です。 というのも、RSCの利点として挙げられているもののうち、パフォーマンスに関係するものとしてバンドルサイズの削減があります。つまり、Server Componentはクライアントに送られる前にただのHTMLになってしまうため、コンポーネントの定義を送る必要がない分だけJavaScriptコードの量が減るということです。 しかし、実は話はそう単純ではありません。よくよく考えると、Server ComponentがただのHTMLになると、逆にサイズが増えるということも考えられます。 // Reactコードがこれなのに <Button>click me!</But

前回のおさらい 前回の記事では、同じアプリケーションを6つのUIライブラリで実装し、Reactに有利な状況設定で作られたベンチマークを走らせると当然Reactが勝つという結果をお伝えしました。 そのベンチマークでは、「レンダリングのために高い負荷がかかっている状況でもユーザーが快適に入力を行えるかどうか」を測りました。 Reactでは、レンダリングのジョブを中断してユーザーの入力を処理するスケジューリングの機構が備わっているため、高負荷の状況でもユーザーの入力に高速に応答することができました。 また、今回書くベンチマークアプリは「最大限自然かつ簡潔」という条件で実装したため、スケジューリングがライブラリ本体に組み込まれているReactのみが有利な結果となりました。実はReact以外のライブラリは1文字入力されるたびに律儀にDOMに反映していましたが、Reactは本体からスケジューリング機構

主に2つの答えがあります。 A. WCAGの考えではユーザーが適切な支援技術を利用することも含めてアクセシビリティであり、支援技術の入手やアクセシビリティ機能の利用に必要なITリテラシーを持たない人はアクセシビリティの対象ではない。（WCAG偏重派） B. うるせえ！！　なるべく多様な人に情報を届ける、それがおもてなしの心ってヤツだろうが！！（アクセシビリティはみんなの心にあるよ派） 筆者には、Aのようにアクセシビリティの範疇からITリテラシーを外すのはやや極端な考え方であるように思えます。しかし、アクセシビリティに詳しい方でもAのような考え方をしているのを見かけます。 この記事では、WCAGやその関連文書を読みながら、この問いについて考察していきます。 今回WCAGとして参照するのはWeb Content Accessibility Guidelines (WCAG) 2.1です。この記

前回のおさらい 前回の記事では、Reactに有利なベンチマークでUIライブラリに競ってもらいました。 こういうベンチマークに対しては、「実務では〜」みたいな反応が一定数出てくるのが自然の摂理です。 書きやすさランキング そこで、シリーズのまとめとして、より実務に近い指標として「書きやすさ」で競ってもらおうと思います。ただし、今回は筆者の独断と偏見によるランキングとなります。せっかく6つのライブラリで同じアプリケーションを書いたので、感想を記事にして残しておきたいという意図です。筆者と同じくReact脳の方にとっては参考になるかもしれません。 なお、前の記事を読んだ方はお分かりの通り、今回書いたアプリケーションはコンポーネントが何個かのものであり、React以外の知識は公式ドキュメントを一通り読んだ程度です。したがって、今回のランキングはコンポーネントの書きやすさに着目しています。大規模開発

皆さんこんにちは。現在、フロントエンドでは宣言的UIが大流行しており、そのためのライブラリもReactを筆頭に複数存在しています。 ライブラリが複数存在するところには当然のように比較や論争が起こるものですが、UIライブラリの場合はパフォーマンスがよく焦点となります。 筆者はReactの信者ですが、Reactは古株ということもあってか、最近の議論ではReactは他のライブラリと比較されるかませ犬のような役割を担うのがよく見られます。「仮想DOMは必要ない」といった類のものです。 しかし、筆者の考えではReactは今でも、もっとも真剣にパフォーマンスに取り組んでいるUIライブラリです。特に、Reactはパフォーマンスを高いユーザーエクスペリエンスのための手段として捉えており、ドキュメントにもユーザーエクスペリエンスという言葉が多く出てきます。 そこで、今回はReactが最も有利になるようなベン

JavaScriptには、import * as という構文があります。これは、インポート先のモジュールの中身全部をオブジェクト（モジュール名前空間オブジェクト）として取得できる構文です。 import * as mod from "./some-module"; console.log(mod.foo, mod.bar); たまに、「この構文を使うとTree Shakingが効かなくなる」といった説明が見られることがありますが、必ずしもそうではありません。そこで、この記事ではimport * as構文とパフォーマンス最適化に関連する正しい知識と、その背景をご紹介します。 webpackで検証してみよう Tree shakingを行うのはモジュールバンドラであることが知られています。そこで、webpackを使って色々と構文を検証してみましょう。今回は次のような設定を用います。これは最適化を

みなさんこんにちは。今日は、TypeScriptの新しいコンパイラオプション（おそらく4.7で導入）であるmoduleSuffixesについての話題がTwitterで見られました。 moduleSuffixesについて詳しくはこちらをご参照ください。 これについては、「モジュール解決がさらに複雑化する」などいくつかの方向性から否定的な意見が見られました。しかし、筆者が考えてみたところ、正当性のある機能追加だと納得できたので考えをご紹介します。 3行でまとめると これまで通りランタイムの挙動に影響しないから大丈夫だよ pathsが怖くないならmoduleSuffixesも怖くないよ TypeScriptはJavaScript環境に追随するよ moduleSuffixesとは では、moduleSuffixesはどんなコンパイラオプションなのかという解説をまず少しします。これはTypeScri

こんにちは。最近、Reactでのステート管理において「useStateの中にステートを置くのではなく、useRefで得たrefオブジェクトの中にステートを置いてuseState（またはuseReducer）をコンポーネントの再レンダリングを発生させるためだけに使う」というやり方を複数の記事で見かけました。このパターンは、今（React 17以前）は動くけどReact 18でアンチパターンに変貌するやり方なので、啓蒙するためにこの記事を用意しました。 ステート（コンポーネントのレンダリングに使用される値）は、useRefではなくuseState（またはuseReducer）をちゃんと使って管理するようにすれば、React 18以降も安泰です。 useRefをステート管理に使うパターンとは こういうやつです。 // 普通のやり方 const Counter1: React.VFC = () =

※効果には個人差があります。 useMemoのオーバーヘッドについて ReactのuseMemoは、パフォーマンス最適化に使われるAPIです。コンポーネント内で計算やオブジェクトの生成を行う際に、以前の計算結果をキャッシュして使い回すことで再レンダリング時の計算を削減したり、新しいオブジェクトの生成を防ぐことができます。 useMemoに関しては、あくまで最適化のためのものであるから「無駄に使うべきではない」という言説がよく見られます。その理由は、useMemoのコストもゼロではなく、余計な使用はそれだけパフォーマンスの低下に繋がってしまうからです。 しかし、筆者はuseMemoのコストは微々たるものであり、本当に一目見て明らかに無駄でない限りは積極的に使うべきだと思っています。 そこで、筆者はuseMemoのオーバーヘッドがどれくらいかを調べるためのベンチマークを作成しました。この記事で

皆さんこんにちは。筆者の以前の記事では、ReactのuseMemoを無駄に使うことによるレンダリング速度のオーバーヘッドがどれくらいかをベンチマークによって示しました。 それによれば、スマートフォンを想定したとしても、useMemoだけで描画に目に見える影響を与える（16msくらいの遅延を発生させる）には万のオーダーのuseMemoが必要なことが分かります。 速度ではなくuseMemoを使うことによるメモリ消費量の増加を気にする声も聞かれましたが、すみませんが筆者はそこまでメモリクリティカルなアプリをReactで書いたことがなく知見に乏しいため、今回はこの記事の対象外となります。 この結果が出たことでuseMemoをいつ使うのかなどという議論には終止符が打たれたかと思いきや、上記の記事の感想などを見ているとまだ喧々囂々です。 そこで、この記事では筆者の考えを皆さんに共有し、いよいよもってこ

React 18はReactの次期メジャーバージョンで、2021年の6月にalpha版が、11月にbeta版が出ました。また、Next.js 12でもReact 18のサポートが実験的機能として追加されました。React 18の足音がだんだんと我々に近づき、アーリーアダプターではない皆さんの視界にもいよいよReact 18が入ってきたところです。 特に、React 18ではServer-Side Rendering (SSR) のストリーミングサポートが追加されます。現在ReactでSSRを行いたい人の強い味方としてNext.jsが存在しているわけですが、Next.js 12でもReact 18を通してストリーミングの恩恵を受けることができます（Next.jsではSSR Streamingと呼んでいるようです）。また、厳密にはReact 18とは別ですが、React Server Comp

こんにちは。筆者はHTMLでプログラムを書けるプログラミング言語、その名も「The HTML Programming Language (THPL)」を作りました。なので、明らかにHTMLはプログラミング言語です。以下では、THPLについて説明します。 最初のプログラム HTMLプログラミング言語では、Hello, world!プログラムは次のように書くことができます。HTMLプログラムを実行するには、HTMLファイルをブラウザで開きます。そうするだけでHTMLプログラムが実行され、出力が表示されます。 <!DOCTYPE html> <html> <head> <meta charset="UTF-8" /> <title>My First HTML Program</title> <script src="https://unpkg.com/the-html-programming-l

みなさんこんにちは。この記事はTypeScript Advent Calendar 2020の5日目の記事です。 TypeScriptにはintersection typeという機能があります。これはT & Uのような構文をもつ型であり、意味としては「TでもありUでもある型」です。 構造的部分型とIntersection Type 「TでもありUでもある」という説明の仕方をされるとIntersection Typeが何の役に立つのかピンと来ないという方がいるかもしれません。実際のところ、Intersection Typeはオブジェクト型を合体するという役割によく使われます。 例えば、Tが{ foo: string }型でUが{ bar: number }型だった場合、T & Uは実質上{ foo: string; bar: number }型となります。 type T = { foo: s

TypeScriptは、型の合わないプログラムに対して型エラーを出すことを主な役目としています。 もちろんプログラムを正しく修正すれば型エラーは消えるのですが、TypeScriptを書いている方ならばそれ以外の方法で型エラーを消したことがある人がほとんどでしょう。すなわち、as、any、// @ts-ignoreその他諸々です。このような手段を使うことで、本来の問題を解決せずに型エラーを消すことができます。 もちろんこれらを濫用するのは勧められたことではありません。それは筆者の過去の記事『敗北者のTypeScript』で解説した通りです。プログラムの修正でasなどを使わずに型エラーが消せるのならばそうすべきで、そうしないのは敗北者です。 しかしながら、asなどをどうしても使わなければいけない場面はあります。それは、TypeScriptの型推論能力や型の表現力が足りないために型エラーが出てい

TypeScriptのunion型はorです　〜union型、構造的部分型、余剰プロパティチェックの話〜TypeScript 先日、「TypeScriptのunion型はorではない」とする以下の記事が公開されました。 TypeScript の共用体型（Union Types）は or ではない 残念ながら筆者はこの主張に同意できないので、この記事では上記の記事に含まれる問題点を指摘しつつ、正しい結論を導きます。 この記事の目的はあくまで正しい情報を皆さまに届けることであり、上記の記事（以下では「元記事」と呼びます）の筆者を攻撃する意図は無いことをご理解ください。 では、元記事からコードを引用しながら何がまずいのかを見ていきましょう。 元記事の主張 元記事の最初のコードを引用します。

今日、Anders HejlsbergさんによってTypeScript 4.0に導入予定の新機能のプルリクエストが出されました。この記事では、この新機能Variadic Tuple Typesを解説します。 ちなみに、現在（この記事の執筆時）のTypeScriptのバージョンは3.9であり、4.0はその次のバージョンです。一見メジャーバージョンアップに見えますが、TypeScriptはsemantic versioningを採用していないため、3.9 → 4.0は特別なリリースというわけではなく、3.8 → 3.9とかと規模は同程度です。 Variadic Tuple Typesの基本 さて、Variadic Tuple Typesは、一言でいえばタプル型の中に...Tと書ける機能です。この構文はよく知られたスプレッド構文のいわば型バージョンであり、あるタプル型の要素たちを別のタプル型に埋

タイトルにあるように、文字列が半角英小文字・大文字と半角数字を全て含むかどうかを判定するという機会は少なくありません。特に、文字種の多さがパスワードの強さであるという教義の持ち主である場合に顕著です。もちろん長さは16文字以内です。 さて、この判定は一見単純に見えて一筋縄ではいきません。文字列の条件判定といえば正規表現ですが、「全て含む」という条件をきれいに書くのは少し難しいでしょう。そこで、この記事ではこの条件を判定する諸方法について雑に考察します。 愚直に正規表現を使う方法 正規表現では、「ある文字種をひとつ含む」という条件を書くのは簡単です。例えば半角小文字を含むという文字列は/[a-z]/という正規表現で判定可能です。これを用いれば、正規表現を3回使うことで上述の条件を判定できます。 const ratz = /[a-z]/, rAtZ = /[A-Z]/, r0t9 = /[0-