前回のおさらい 前回の記事では、同じアプリケーションを6つのUIライブラリで実装し、Reactに有利な状況設定で作られたベンチマークを走らせると当然Reactが勝つという結果をお伝えしました。 そのベンチマークでは、「レンダリングのために高い負荷がかかっている状況でもユーザーが快適に入力を行えるかどうか」を測りました。 Reactでは、レンダリングのジョブを中断してユーザーの入力を処理するスケジューリングの機構が備わっているため、高負荷の状況でもユーザーの入力に高速に応答することができました。 また、今回書くベンチマークアプリは「最大限自然かつ簡潔」という条件で実装したため、スケジューリングがライブラリ本体に組み込まれているReactのみが有利な結果となりました。実はReact以外のライブラリは1文字入力されるたびに律儀にDOMに反映していましたが、Reactは本体からスケジューリング機構
皆さんこんにちは。現在、フロントエンドでは宣言的UIが大流行しており、そのためのライブラリもReactを筆頭に複数存在しています。 ライブラリが複数存在するところには当然のように比較や論争が起こるものですが、UIライブラリの場合はパフォーマンスがよく焦点となります。 筆者はReactの信者ですが、Reactは古株ということもあってか、最近の議論ではReactは他のライブラリと比較されるかませ犬のような役割を担うのがよく見られます。「仮想DOMは必要ない」といった類のものです。 しかし、筆者の考えではReactは今でも、もっとも真剣にパフォーマンスに取り組んでいるUIライブラリです。特に、Reactはパフォーマンスを高いユーザーエクスペリエンスのための手段として捉えており、ドキュメントにもユーザーエクスペリエンスという言葉が多く出てきます。 そこで、今回はReactが最も有利になるようなベン
みなさんこんにちは。今日は、TypeScriptの新しいコンパイラオプション（おそらく4.7で導入）であるmoduleSuffixesについての話題がTwitterで見られました。 moduleSuffixesについて詳しくはこちらをご参照ください。 これについては、「モジュール解決がさらに複雑化する」などいくつかの方向性から否定的な意見が見られました。しかし、筆者が考えてみたところ、正当性のある機能追加だと納得できたので考えをご紹介します。 3行でまとめると これまで通りランタイムの挙動に影響しないから大丈夫だよ pathsが怖くないならmoduleSuffixesも怖くないよ TypeScriptはJavaScript環境に追随するよ moduleSuffixesとは では、moduleSuffixesはどんなコンパイラオプションなのかという解説をまず少しします。これはTypeScri
皆さんこんにちは。筆者の以前の記事では、ReactのuseMemoを無駄に使うことによるレンダリング速度のオーバーヘッドがどれくらいかをベンチマークによって示しました。 それによれば、スマートフォンを想定したとしても、useMemoだけで描画に目に見える影響を与える（16msくらいの遅延を発生させる）には万のオーダーのuseMemoが必要なことが分かります。 速度ではなくuseMemoを使うことによるメモリ消費量の増加を気にする声も聞かれましたが、すみませんが筆者はそこまでメモリクリティカルなアプリをReactで書いたことがなく知見に乏しいため、今回はこの記事の対象外となります。 この結果が出たことでuseMemoをいつ使うのかなどという議論には終止符が打たれたかと思いきや、上記の記事の感想などを見ているとまだ喧々囂々です。 そこで、この記事では筆者の考えを皆さんに共有し、いよいよもってこ
※効果には個人差があります。 useMemoのオーバーヘッドについて ReactのuseMemoは、パフォーマンス最適化に使われるAPIです。コンポーネント内で計算やオブジェクトの生成を行う際に、以前の計算結果をキャッシュして使い回すことで再レンダリング時の計算を削減したり、新しいオブジェクトの生成を防ぐことができます。 useMemoに関しては、あくまで最適化のためのものであるから「無駄に使うべきではない」という言説がよく見られます。その理由は、useMemoのコストもゼロではなく、余計な使用はそれだけパフォーマンスの低下に繋がってしまうからです。 しかし、筆者はuseMemoのコストは微々たるものであり、本当に一目見て明らかに無駄でない限りは積極的に使うべきだと思っています。 そこで、筆者はuseMemoのオーバーヘッドがどれくらいかを調べるためのベンチマークを作成しました。この記事で
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、昨日公開された以下の記事に対するアンサー記事です。TypeScriptで型定義に凝る派筆頭（自称）として、このお題に対して別の視点から光を当ててあげるためにこの記事を用意しました。 TypeScript の型定義に凝りすぎじゃね？ まず最初に、この記事（以下では元記事と呼びます）の著者を攻撃したり、元記事の内容を否定する意図はないことをご理解ください。結局のところ、考え方が異なり、前提が異なるから異なる結論になっているだけなのです。TypeScriptを使う皆さんがいろいろな観点から見た情報を取得し、自分の状況に応じた適切な
TypeScriptは、型の合わないプログラムに対して型エラーを出すことを主な役目としています。 もちろんプログラムを正しく修正すれば型エラーは消えるのですが、TypeScriptを書いている方ならばそれ以外の方法で型エラーを消したことがある人がほとんどでしょう。すなわち、as、any、// @ts-ignoreその他諸々です。このような手段を使うことで、本来の問題を解決せずに型エラーを消すことができます。 もちろんこれらを濫用するのは勧められたことではありません。それは筆者の過去の記事『敗北者のTypeScript』で解説した通りです。プログラムの修正でasなどを使わずに型エラーが消せるのならばそうすべきで、そうしないのは敗北者です。 しかしながら、asなどをどうしても使わなければいけない場面はあります。それは、TypeScriptの型推論能力や型の表現力が足りないために型エラーが出てい
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するということ自体に焦点
今日、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-
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Concurrent Modeは、現在（2020年3月）実験的機能として公開されているReactの新しいバージョンです。Reactの次のメジャーバージョン（17.x）で正式リリースされるのではないかと思っていますが、確証はありません。なお、React公式からもすでに結構詳細なドキュメントが出ています。 並列モードの導入（実験的機能） Concurrent Modeに適応したアプリケーションを作るためには、従来とは異なる新しい設計が必要となります。筆者はConcurrent Modeを使ったアプリケーションをひとつ試作してみました。この記
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 今時のJavaScript開発において、JavaScriptが持つモジュールの機能は欠かすことができません。我々はプログラムをいくつものファイル（モジュール）に分割し、import文とexport文を使ってそれらを繋げています。各モジュールはexport文を用いてそのモジュール内で定義した変数・関数などをエクスポートすることができ、別のモジュールがimport文でそれらの値を取得することができるのです。 皆さんは、このimport・export文がどのように働いているのか正確に説明できるでしょうか。実は、import文やexport文と
React Hooksの正式リリース（2019年2月）からそろそろ一年が経とうとしています。Hooksの登場によってReactのコンポーネントは関数コンポーネントが一気に主流になり、クラスコンポーネントが新規に作られる機会は激減しました。 また、React 17.x系ではConcurrent Modeの導入とともにさらに2種類の新フックが追加される見込みであり、いよいよ関数コンポーネントの能力がクラスコンポーネントを真に上回る時代が来ることになります。 この記事では、フックの一種であるuseReducerに焦点を当てて、どのようなときにuseReducerが適しているのかを説明します。究極的には、useReducerによって達成できるパフォーマンス改善があり、ときにはそれがコンポーネント設計にまで影響を与えることを指摘します。 useStateの影に隠れたり、なぜかReduxと比較されたり
JavaScriptの ~. 構文って知ってる？ Promise Pipeliningが拓く非同期処理の未来JavaScriptECMAScript PromiseはES2015からJavaScriptに導入された機能で、非同期処理をいい感じに記述できるたいへんありがたいオブジェクトです。実は、Promiseの強化版ともいえる新機能、その名もHandledPromiseが提案されています。また、このHandledPromiseのための新構文~.も同時に提案されています。 例えば、~.を用いて次のようなプログラムを書くことができます。 この記事では、HandledPromiseと~.について概説します。例によって、これらはStage 1プロポーザルです。つまり、「こういうのがあってもいいんじゃない？」と思われている段階であり、具体的な方向性とかは何一つ決まっていないということです。この記事で
TypeScirptの動向を少し熱心に追っている方ならば、8月頭にAnders HejlsbergさんがTypeScriptリポジトリに次のプルリクエストを出したことは記憶に新しいでしょう。 Assertions in control flow analysis これはTypeScript 3.7で導入される予定の機能で、関数の返り値の型宣言においてasserts x is T （xは引数名でTは型）という構文を書くことが可能になるというものです。 この機能はたいへん面白いのですが、誤った使い方をするととても危険です。そこで、この記事では、assertsという新しい型述語1を正しく使いこなせるように皆さんをガイドします。 3行でまとめると assertsによる宣言はTypeScriptにより正しさがチェックされるわけではありません。 よって、assertsを使う場合安全性を保証する責任はコ
イテレータは今となっては多くのプログラミング言語に存在する概念で、繰り返し処理やループ、ストリームといった対象を抽象化してくれるものです。JavaScriptにはES2015でイテレータが追加されており、JavaScriptを触っている方にとっては既に馴染み深いものとなっています。 とはいえ、JavaScriptのイテレータにはひとつ問題点がありました。それは「イテレータを直接変換・操作できるメソッドが存在しない」という点です。従来イテレータが持つメソッドはイテレータから一つ値を取り出すnextメソッドのみであり1、それ以上の機能は何も提供されていませんでした。これにより、Rustなどのイテレータが強い言語に比べてJavaScriptのイテレータは有用性が大幅に低いものとなっていました。 この記事では、この問題を多少解消するプロポーザル「Iterator Helpers」を紹介します。これ
const arr1 = [1, 2, 3]; const arr2 = [...arr1, 4, 5]; func(...arr1, ...arr2); また、ES2018からはオブジェクトの中でも...が使えます。 当初この...を「スプレッド演算子」（spread operator）と呼ぶ向きがありましたが、よく見るとこれは全然演算子ではありませんね。 演算子の定義は人によって異なるかもしれませんが、「いくつかの式から式を作る働きをする構文」というのが一般に受け入れられている定義だと思います。例えばx + 1という式は、xという式と1という式を+で繋げる事でx + 1という式を得ています。この働きをする+が演算子です。 こうしてみると、...は式を作るのではありません。つまり、const arr2 = ...arr1;のようなものは受け付けられないということです。...が使えるのは配
TypeScriptはJavaScriptに静的型を追加した言語で、コンパイルエラーを検出することでJavaScript開発をさらに快適・効率的にしてくれるものです。 型システムを備えている言語は、多かれ少なかれ何らかの形で型推論を備えています。大ざっぱに言えば、これは型を明示的に書かなくてもコンパイラがいい感じに型を推測して理解してくれる機能です。型推論は静的型付き言語における花型機能のひとつと言ってもよく、色々な言語がそれぞれの特色を持っています。 この記事ではTypeScriptにおける型推論について詳説します。この記事に書いてあることは、TypeScriptを普段から書いている方ならなんとなく理解している内容が多いと思います。しかし、これらの内容がちゃんと言語化されている記事がいまいち見当たらなかったので今回記事を書くことにしました。 ※ この記事の内容は執筆時点の最新版のType
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TypeScriptはJavaScriptに静的型を導入したプログラミング言語で、登場から現在までその人気を増し続けています。 動的型付き言語であるJavaScriptに静的型の安全性（コンパイル時にバグ・間違いを発見することができる能力）を与えることで、TypeScriptはJavaScriptによる開発の効率を上げてくれます。 裏にJavaScriptがあるという特性もあり、TypeScriptは「部分的に静的型チェックをする」というような挙動をサポートしています1。詳しくは後述しますが、これによりJavaScriptからTypeS
日時の処理は様々なアプリケーションにおいて避けては通れないタスクです。JavaScriptにおいてもそれは例外ではありません。 JavaScriptでは最初期からDateオブジェクトが日時を表すオブジェクトとして存在していましたが、これは非常に使いにくいAPIで知られています。その結果、momentに代表されるような日時処理ライブラリを使うのが事実上スタンダードとなっています。 この記事では、将来的に日時処理の有力な選択肢になると期待されるモジュールであるTemporalについて解説します。Temporalでは、既存のDateによる日時処理のつらい部分が解消されることが期待されています。 なお、例によってTemporalはまだ策定中の仕様です。現在Stage 2というフェーズにあり、APIを鋭意策定中という状況です。よって、この記事にかかれている内容は確定までにまだ変化するかもしれません。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く