React で開発が進められている Concurrent Mode。 まだリリース前の開発中の機能だが、「実験的機能」として提供されており、Experimentalビルドをインストールすることで利用できる。 Experimentalはリリース間の安定性を何も保証しておらず、破壊的変更が行われる可能性がある。Concurrent Mode の動作も、大きく変わる可能性がある。 記事のタイトルに「2020年12月版」と入れたのは、そのため。 公式ドキュメントでは「並列モード」と翻訳されているが、まさに、並列的にレンダリングを行えるようになる。 ネットワークからデータを取得して要素をレンダリングする際に、ユーザーに見えないところで新しいレンダリングの準備をしつつ、データが取得できるまでは古いレンダリングを表示しておく、といったことが可能になる。 この記事では、どういった仕組みでそのようなことが可

JavaScript や TypeScript を使ってウェブアプリを提供する場合、開発時はimportやexportなどの ES Modules を使い、公開時はファイルをバンドルして公開することが多い。 以下の記事に書いたように、現在の主要なブラウザは ES Modules に対応してものの、バンドルせずに公開してしまうとパフォーマンスに悪影響を与える可能性がある。 numb86-tech.hatenablog.com ファイル数が増えれば増えるほど影響は深刻になるため、依存関係が深いライブラリを使っている場合などは、レイテンシが飛躍的に増加してしまう。 そのため、バンドルせずに公開するのは現実的ではない。 バンドルしてひとつのファイルにまとめてしまえば、JavaScript のダウンロードは一度で済む。 しかしそうすると今度は、バンドルファイルの肥大化という問題が発生する。 巨大なフ

ソースコードを AST（抽象構文木）と呼ばれるデータ構造に変換することで、ソースコードの検証や変換をプログラムによって行えるようになる。 例えば ESLint では、ソースコードを AST に変換して、それに対してチェックを行っている。 また、V8 などの JavaScript エンジンも、対象の JavaScript ソースコードを AST に変換してから、後続の処理を行う。 AST を使えるようになると、ソースコードの検証や変換を行うツールを自作できるようになる。 この記事では、JavaScript AST を扱うための方法を見ていく。 この記事で使用しているライブラリのバージョンは以下の通り。 esprima@4.0.1 estraverse@5.2.0 escodegen@2.0.0 動作環境は Node.js のv12.17.0で行っている。 また、この記事に出てくる木構造の画像

現代の主要なブラウザでは、ES Modules（以下、ESM）を利用することができる。 つまり、import文やexport文を使った JavaScript ファイルを、トランスパイルすることなくそのまま使えるということである。 モジュールシステムをそのまま使えるので、複数のファイルをバンドルする必要もない。 この記事ではまず、ブラウザで ESM を使う方法について説明していく。 その後、処理の流れを詳しく確認していく。これを理解していないと、パフォーマンスが非常に悪いページになってしまう恐れがある。 動作確認は Google Chrome の84.0.4147.105で行っている。 ESM 利用の基本 まずは検証用にサーバを立てる。 以下のコードを Deno（バージョンは1.2.2）で実行する。 そうすると、http://localhost:8080/にアクセスしたときにindex.ht

プログラミングの型システムに関する記事を読んでいると、共変や反変といった用語が出てくることがある。 TypeScript や Flow についての記事でも、見かけることがある。 それらは TypeScript を使う上で必須の知識ではないが、把握しておくに越したことはない。 この記事では、TypeScript を題材にして、変性について説明していく。 TypeScript に関する議論を理解できるようになることがこの記事の目的であり、より詳細な、学術的、数学的な内容には踏み込まない。 この記事の内容は、TypeScript のv3.9.5で動作確認している。 変性 変性（variance）とは、任意の型Tに対してどのような性質を持つのか示したものであり、以下の 4 種類がある。 不変性（invariance） Tそのものが必要 共変性（covariance） Tそのものか、そのサブタイプが

〜2020/7/8 追記〜 本記事に対して指摘を頂いた。 qiita.com 「余剰プロパティチェックの存在やそのルールによってorではないかのように見える（ことがある）というだけで、型システム的にはorである」と、私は解釈した。 特に「余剰プロパティチェックは、型システムに対する違反を検出するものではなく言わば追加の親切なチェック」という点が重要であり、確かにそこを無意識のうちに混同していた。 分かりやすく説明して頂いているので上記の記事を読めば十分かもしれないが、勉強も兼ねて、自分でも整理しておく。 共用体型は or である TypeScript では、オブジェクトに余計なプロパティがあっても問題にならない。 以下の例だと、string型のaというプロパティが存在していればAの条件を満たしていることになり、余計なプロパティが存在してもエラーにはならない。 type A = { a: s

npm にはlinkというコマンドが用意されており、これを使うことで npm パッケージの開発効率が上がる。 既存のパッケージに手を加えた際の動作確認にも使えるので、OSS 活動の効率も上がる。 この記事では、npm linkの仕組みと、それをどのように利用できるのかについて説明する。 動作確認に使った npm のバージョンは6.14.5。 Node.js のバージョンは12.17.0。これ以前のバージョンだと以下の動作確認でエラーが出るので注意。 サンプル用のパッケージとアプリを作る まずはパッケージを作成する。 my-package-dirというディレクトリを作り、そこに以下の内容のpackage.jsonを作成する。 { "name": "my-package", "type": "module", "main": "main.js" } そして、以下の内容のmain.jsを作る。