TypeScript 4.1では、Mapped typesにおけるkey remappingやtemplate literal typesに付随する新機能として、標準ライブラリにUppercaseなどの型が追加されました。 上の例から分かるように、Uppercase型は一つの文字列を受け取る型関数で、文字列のリテラル型を渡すとその文字列中の小文字を全て大文字にした文字列のリテラル型が返ります。他にも、Lowercase、Capitalize, Uncapitalizeがあります。 これらの型は標準ライブラリ（lib/es5.d.ts）にその定義があります。そこで使われているのがintrinsicキーワードなのです。以下はTypeScript 4.1時点の標準ライブラリからの引用です。 /** * Convert string literal type to uppercase */ typ

Server ComponentはReact単体の機能ではなく、バンドラーなどを巻き込んだシステムを作ろうとしている。 In our bundler plugins we'll enforce that a .server.js file cannot be imported in that environment. First, they make code splitting automatic: Server Components treat all imports of Client Components as potential code-split points.

JavaScriptは様々な用途で使われるプログラミング言語で、色々な用途に対応するための一通りの機能が揃っています。その中には、数値計算の機能も含まれています。 数値計算、特に小数の計算においては、計算結果の正確性が度々問題になります。プログラムにおいては、色々な要因で計算結果には誤差が発生します。一例として、浮動小数点数の場合は数を表現するために使えるビット数が有限であることから、計算結果は真の値（数学的な意味での正しい計算結果）と異なる値になることがあります（いわゆる丸め誤差）。例えば、JavaScriptの数値はIEEE 754 倍精度浮動小数点数（いわゆるdouble）ですが、doubleでは1 / 10の結果（0.1）を正確に表すことができず、結果の浮動小数点数は（10進数で書き下すと）0.10000000000000000555111512312578270211815834

observedBitsとは、ReactのContextに隠された機能です。 まずReactのContextについて復習しておくと、これはコンポーネントツリーの上のほうに配置したProviderに与えられた値をそれより下の任意のコンポーネントで取り出すことができる機能です。Reactにおける最も単純なデータの受け渡しはpropsによるものですが、propsは親子間のデータの受け渡ししかできません。すごく上のほうにあるコンポーネントが持っているデータをすごく下のほうにあるコンポーネントで使いたい場合、propsでデータを受け渡すと上から下までの間に経由するコンポーネントの全てでpropsによるデータの受け渡しが必要になってしまいます（いわゆるpropsのバケツリレー）。Contextを使えば、途中のコンポーネントで何もしなくても、上のほうのコンポーネントが持っているデータを下の方のコンポーネ

最近リリースされたNode.js 15ではデフォルトの設定が変更され、Unhandled Rejectionが発生した際にプロセスが強制終了されるようになりました。 では、Unhandled Rejectionがいつ発生するのか正確に説明できますか？　この記事では、Unhandled Rejectionに対する正確な理解を目指します。 ECMAScript仕様書で確かめる こういう場合に頼りになる唯一の情報源はECMAScript仕様書、つまりJavaScriptの言語仕様を定める文書です。この記事ではES2020の仕様書を参照します。 仕様書を"unhandled"で全文検索すれば、目的の記述を見つけるのはそう難しいことではありません。それは25.6.1.9 HostPromiseRejectionTrackerです。 これは抽象操作 (abstract operation) です。抽象

CSS in JSはJavaScriptのコード中にCSSを書くプログラミング手法で、styled-componentsなどがメジャーどころです。現代的な開発では、ReactやVueといったフロントエンド用のViewライブラリを使う際にCSS in JSのお世話になることがよくあります。 この記事では、次の時代のCSS in JSはWeb Componentsベースのものになるのではないかという話をします。 Web Componentsの復習 Web ComponentsはいくつかのWeb標準の総称であり、特に重要なのはCustom ElementsやShadow DOMです。いずれも、V1と呼ばれる仕様は全てのモダンブラウザでサポートされています（Safariが一歩遅れていて少し心配ですが）。 https://caniuse.com/custom-elementsv1 https://c

[...Array(n).keys()]は、JavaScriptで0からn-1までの整数が順番に並んだ配列を得る記法です。 const arr = [...Array(5).keys()] console.log(arr); // [0, 1, 2, 3, 4] この記事では、これはやめた方がいいのではということを主張します。 理由 読み手にかかる負荷が高い（≒理解しにくい）からです。特に、Array(n).keys()の挙動を正確に把握する難易度が高くなっています。かといって、[...Array(n).keys()]という長いコードを中身を気にせずイディオムとして覚えるのは脳の記憶領域の無駄遣いです。 以下では、Array(n)とkeys()に関して見ていき、難易度の高さを実感します。 Array(n)とempty Array(n)はnew Array(n)でと同じ意味で、一言で言えば長

くもゐにてなほさる花ぞうるはしき人のたゆらに色を思はく 現代語訳 天上で正しく直された花は整っていて美しい。（それに比べて、）人が思い望む（花の）色は揺れ動いて定まらないものだなあ。 解説 Prettierによってフォーマッターとしての役割を奪われたeslintの風情を詠んだ歌。くもゐ（雲居）とは空の上・雲のある所を表すと同時に宮中・皇居を指す言葉であり、ここでは権威あるopinionatedなフォーマッターであるPrettierを指していると解釈される。天上で正しく直された「花」とはPrettierによって画一的にフォーマットされたコードを指している。 「人」はここでは宮中に対比された一般人を指しており、揺れ動いて定まらない花の色は個人個人のフォーマッティングに対する嗜好を表している。歴史的背景から、この「人」の裏には様々な嗜好に柔軟に対応してきたeslintの姿が見て取れる。 出典:

今日発表された公式ブログの記事によれば、React17では新しいJSXの変換がサポートされます。これはどういうことなのか、我々にどういう影響があるのかをまとめました。 JSXの変換とは ほとんどの人は、Reactを使う際に以下のようなJSX記法を使っているはずです。具体的には次のようなもので、<div>のようなHTMLに近い記法がJSXです。 const Foo = () => { return <div> <p id="a">I am foo</p> <p key="b">I am foo2</p>> </div>; } これらは純粋なJavaScriptではないため、そのままでは実行できません。そのため、何らかの方法でただのJavaScriptに変換する必要があります。現代では、それを担うのはBabelやTypeScriptです。これらによって、上記のJSXを含むコードは次のように変換

しばらく前、React 17 RCが発表されました。現行のReact 16に比べて、いくつかの破壊的変更がある一方、新機能が何もないというのが特徴です。Reactチームとしては、新機能が無いとはいえ、破壊的変更も少なくなっておりなるべく16から17へのアップデートを行なってほしいという考えのようです。 この記事では、React 17における破壊的変更のうち、useEffectのクリーンアップのタイミングに関する変更を取り上げます（以下は公式サイトから引用）。 In React 17, the effect cleanup function also runs asynchronously — for example, if the component is unmounting, the cleanup will run after the screen has been updated.