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

皆さんこんにちは。筆者の以前の記事では、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

この記事は、昨日公開された以下の記事に対するアンサー記事です。TypeScriptで型定義に凝る派筆頭（自称）として、このお題に対して別の視点から光を当ててあげるためにこの記事を用意しました。 TypeScript の型定義に凝りすぎじゃね？ まず最初に、この記事（以下では元記事と呼びます）の著者を攻撃したり、元記事の内容を否定する意図はないことをご理解ください。結局のところ、考え方が異なり、前提が異なるから異なる結論になっているだけなのです。TypeScriptを使う皆さんがいろいろな観点から見た情報を取得し、自分の状況に応じた適切な考え方・判断をできるようにすることがこの記事の目的です。 要約 大きなコードを小さく分解しても本質的な難しさが消えるわけではないよ？ 型はドキュメントなんだから正確に書こうぜ！ 外界との接続も妥協せずに型システムで解決しようぜ！ 機械にできる仕事を人間がする

こんにちは。この記事は筆者が開発した「better-typescript-lib」を宣伝する記事です。これは、導入するだけでTypeScriptプログラムがより型安全になるという素晴らしいライブラリです。あくまで型定義なので、導入してもランタイムの挙動は何も変わらず、バンドルサイズなどへの影響もありません。 better-typescript-libの導入法 ここに記載されているのはv1 (TypeScript 4.0 〜 4.4向け）のインストール方法です。v2 （TypeScript 4.5〜）ではインストール方法が変わり、最初のnpm installのみで良くなります。詳しくは次の記事をご覧ください。

ユニオン型は、string | numberのような記法で「stringまたはnumber」のような意味の型を作る方法です。TypeScriptプログラミングではユニオン型は非常に便利で、様々なインターフェースを的確に型で表現するためには欠かせない道具です。 ユニオン型を得るためには上の例のように|記法を使いますが、この記事では|と書かずに型推論を用いてユニオン型を得る方法を集めてみました。 構文系 JavaScriptの構文の意味から型推論でユニオン型が推論される系です。 条件分岐 条件分岐の構文では、ランタイムの条件によって結果が変わるため、コンパイル時には結果がどちらに分岐するか分かりません。そのため、TypeScriptコンパイラはどちらでも対処できるようにユニオン型を推論します。 条件演算子

みなさんこんにちは。この記事は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

ReactのConcurrent Modeが最初に発表されたのはもう1年近くも前のことです（記事執筆時点1）。Concurrent Modeはたいへん奥深い機能で正式版がたいへん待ち遠しいですが、Concurrent Modeの代名詞として多くのReactユーザーに知られているのはPromiseをthrowするというAPIデザインです。Concurrent Modeでは、コンポーネントがレンダリング時にPromiseをthrowすることで、レンダリングをサスペンドした（Promiseが解決されるまでレンダリングできない）ことを表します。 Concurrent Modeに関しては筆者の既存記事Concurrent Mode時代のReact設計論 (1) Concurrent Modeにおける非同期処理などをご参照いただきたいのですが、ここではPromiseをthrowするということ自体に焦点

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

Q. なぜJavaScriptのDateコンストラクタは例外を投げないのか？ A. NaNがあるから DateはJavaScriptで日時を扱うためのAPIで、JavaScriptの当初から存在します。 Dateオブジェクトは主にDateコンストラクタを用いて作られます。Dateコンストラクタにはいろいろな機能があり、new Date()のように引数なしで呼び出すと現在時刻を取得できるほか、new Date("2020-04-24T00:00+09:00")のように文字列から日時に変換したり、new Date(1587654000000)のように数値（UNIX時間）を日時に変換したりすることができます。 一般に、データの変換作業には失敗が付き物です。しかし、new Dateは決して失敗しません1。例えば、new Date("foobar")のように明らかに日時を表していない文字列からDat

今時のJavaScript開発において、JavaScriptが持つモジュールの機能は欠かすことができません。我々はプログラムをいくつものファイル（モジュール）に分割し、import文とexport文を使ってそれらを繋げています。各モジュールはexport文を用いてそのモジュール内で定義した変数・関数などをエクスポートすることができ、別のモジュールがimport文でそれらの値を取得することができるのです。 皆さんは、このimport・export文がどのように働いているのか正確に説明できるでしょうか。実は、import文やexport文というのは値をインポート・エクスポートしているのではなく、言わば変数そのものをインポート・エクスポートしているのです。これを理解するのがこの記事のゴールです。 ※ 本当は変数ではなく「バインディング」といったほうが用語としてより正確なのですが、この記事では分か

先日、TypeScript 3.8 RCが公開されました。TypeScript 3.8はクラスのprivateフィールド（#nameみたいなやつ）を始めとして、ECMAScriptの新機能のサポートがいくつか追加されています。この記事で取り扱うtop-level awaitもその一つです。 この記事ではtop-level awaitに焦点を当てて、その意味や使い方について余すところなく解説します。top-level awaitは一見単純な機能に見えますが、実はモジュール (ES Modules) と深い関係があり、そこがtop-level awaitの特に難しい点です。そこで、この記事ではECMAScriptのモジュールについても詳しく解説します。この記事を読んでtop-level awaitを完全に理解して備えましょう。 ※ この記事は3分の1くらい読むと「まとめ」があり、残りはおまけで

TypeScriptでは、オブジェクト型のプロパティをreadonlyにできる機能があります。型でreadonlyと宣言されているプロパティを書き換えようとするとコンパイルエラーとなります。 type MyObj = { readonly foo: string; }; const obj: MyObj = { foo: "Do not change me!" }; // これは MyObjのfooプロパティがreadonlyなのでコンパイルエラー obj.foo = "hi";

継承は、クラスベースのオブジェクト指向における基本的な概念のひとつであると信じられています。JavaScriptにもES2015以降はclass構文があり、extendsを用いてクラスの継承を記述することができます。また、それより以前もprototypeを通じてオブジェクト指向的なプログラムが書かれてきました。 この記事では、JavaScriptにおける「継承」がどのようなものであり、どのように定義されるのかを解説します。タイトルにある通り、今回はECMAScript仕様書に対する解説を中心とします。 仕様書はJavaScriptというプログラミング言語がどのようなものかを定義する文書であり、あなたが書いたJavaScriptプログラムは仕様書に書かれた通りの動きをすることになります1。したがって、たとえあなたが自分自身で書いたものだったとしても、JavaScriptプログラムの意味を完全

JavaScriptの ~. 構文って知ってる？　Promise Pipeliningが拓く非同期処理の未来JavaScriptECMAScript PromiseはES2015からJavaScriptに導入された機能で、非同期処理をいい感じに記述できるたいへんありがたいオブジェクトです。実は、Promiseの強化版ともいえる新機能、その名もHandledPromiseが提案されています。また、このHandledPromiseのための新構文~.も同時に提案されています。 例えば、~.を用いて次のようなプログラムを書くことができます。 この記事では、HandledPromiseと~.について概説します。例によって、これらはStage 1プロポーザルです。つまり、「こういうのがあってもいいんじゃない？」と思われている段階であり、具体的な方向性とかは何一つ決まっていないということです。この記事で

この表を上から読みつつ多少言葉で説明すると以下のようになります。 const foo = bar + 3;はStatementListItemである。なぜなら、DeclarationはStatementListItemの一種であると定義されているから。 const foo = bar + 3;はDeclarationである。なぜなら、LexicalDeclarationはDeclarationの一種であると定義されているから。 const foo = bar + 3;はLexicalDeclarationである。なぜなら、LetOrConst, BindingList, ;が並んだものはLexicalDeclarationであると定義されているから。 constはLetOrConstであると定義されている。 foo = bar + 3 はBindingListである。LexicalBind

みなさん、Optional Chaining使ってますか？　私は先日出たTypeScript 3.7 Betaを小さいプロジェクトに導入して使ってみました。これはとても快適ですね。 例によって、Optional ChainingはECMAScriptに対するプロポーザルの一つです。つまり、もうすぐ入りそうなJavaScriptの新機能です。プロポーザルはたくさんの種類がありますが、その中でもOptional Chainingはその高い有用性からこれまで多くの注目を集めてきました。Optional Chainingは2019年6月のTC39ミーティングでStage 3に上昇し、いよいよ正式採用が近く期待も高まってきたところです。TypeScript 3.7にも導入されたため、TypeScriptユーザーの方々は11月上旬に正式リリースが予定されているTypeScript 3.7を今か今かと待

数値というのはプログラミングにおいて極めて基本的な対象です。ほとんどのプログラミング言語は何らかの形で数値の操作を行うことができ、もちろんJavaScriptにおいても例外ではありません。 プログラミングにおける数値の特徴的な点は、往々にしてその性質に応じた複数の型1が与えられている点です。まず、数値は整数か小数かによって分類されます。さらに、値を表すのに使われるビット数、また整数に関しては符号ありか符号なしかという分類ができます。例えば、Rustという言語ではこれらの分類が分かりやすく表れています2。Rustにおける数値の型はi32, i64, u32, u64, f32, f64などがあり、見ただけでどのような特徴を持つ数値なのかが分かりやすくなっています。iというのは符号あり整数、uというのは符号なし整数、fは小数で、その後の数字がビット数ですね。 では、JavaScriptにおいて

JavaScriptに限った話ではありませんが、関数というのは名前を持っていたり持っていなかったりします。関数名は普通はプログラムの読みやすさくらいにしか影響しませんが、JavaScriptでは必ずしもそうではありません。 例えばReactで関数コンポーネントを使う場合は関数名がコンポーネント名となり、React用開発者ツールなどで見ることができデバッグに役立ちます。また、Gulp v4もエクスポートした関数名がタスク名となります。 関数名は、関数オブジェクトのnameプロパティで取得できます。 function foo() { console.log('foo!'); } console.log(foo.name); // "foo"

この記事は、「TypeScriptの型演習」の解答および解説を収録した記事です。問題に挑戦したい方は先に下記の記事をご覧ください。 TypeScriptの型演習 1-1. 関数に型をつけよう 関数の引数に: numberを追加しました。これが引数に対する型アノテーションです。TypeScriptでは、関数の引数の型を指定するにはこのように明示するのが基本です。型が指定されていない場合はエラーとなります（--noImplicitAnyオプションの効果）。ただし、問題1-3のように文脈から推論できる場合は引数の型アノテーションを省略できます。 また、関数にはこのように返り値の型アノテーション（: boolean）も可能ですが、返り値については関数の定義から推論してくれます。今回の場合、返り値がnum >= 0であり、これの型がbooleanであることを推論してくれます。 型アノテーションが何だ