この記事は、筆者が技術選定について思うところをまとめた記事です。Twitterに同じ話を何回か書いているので、文章にまとまっていたほうがよいと思い用意しました。 やや過激な思想で愚痴も含んでいるので、共感いただけると嬉しいものの、みなさんを説得しようというつもりはありません。こいつはこういう考え方なんだなという心持ちでお読みください。 積極的な技術選定と消極的な技術選定ITエンジニアの方々の中には、技術選定をする立場の方も多いでしょう。技術選定にあたってはさまざまな事情を勘案しなければならない難しいもので、それだけに多くの人が技術選定に関する各々の考えを述べています。 筆者は、技術選定における意思決定のプロセスは、積極的な技術選定と消極的な技術選定の2種類があるのではないかと思っています。 積極的な技術選定は、選定される（あるいはされない）技術そのものが原因となる意思決定です。 一方、消極

この記事はuhy.oooでも読むことができます。 ████を退職します皆さんこんにちは。この度、████を退職することになりましたのでご報告します。 筆者は2019年に新卒で████に入社して、今年が4年目でした。今回が初めての転職となります。転職先は███という会社です。 ████はどうだったか一言で言えば、良いところでした。特に、チームメンバーと上司に恵まれ、快適かつとても自由な環境で働くことができました。 快適というのはいくつかの側面があります。自分としては、大きい会社ならではの整った社内制度・社内システムは魅力的でした。これにより、事務的な作業はなるべく事務的かつ簡潔に済ませられるようになっていて業務に集中できます。他には、プロジェクトメンバーとのコミュニケーションにおいてストレスを感じることもあまり無く（██████████████████████）、これだけ良い人ばかり集まって

現在、TypeScriptの重要性は、フロントエンド開発を中心としてますます増すばかりであります。それだけに、TypeScriptをどのように使うべきかという問題については多様な意見が見られます。 これまで筆者はTypeScriptの使い方に、特にコンパイラオプションの使い方について意見を散発的に発信してきましたが、このたび記事にまとめました。この記事では、特に次のような意見に対しての反対意見を述べます。 厳しいコンパイラオプションは型パズル愛好者のためのものであり、普通の人は細かいことを気にせず緩い設定でよい。熟練のJavaScript使いにはTypeScriptは必要ない。例え話最近はTypeScriptを補助輪に例えたりするのが流行っていますので、この記事でも例え話をしてみます。筆者の考えでは、TypeScriptというのは例えるならば料理人が使う包丁のようなものです。コンパイラオプ

こんにちは。先日からTwitterアカウント@uhyo_が🈚️になっており、皆さまにご心配をおかけしています。 「なぜ」「TypeScript界隈が衰退した」など数十件もの心温まる反応に励まされております。また、凍結中に技術記事「TypeScript 4.5でますます便利に！ better-typescript-lib v2」を公開しましたが、皆さまの拡散などのご協力もあり普段と遜色ない反響を得ています。本当にありがとうございます。 この記事はアカウント凍結に関する公式見解をお届けします。 追記: 記事公開翌日の15時に凍結が解除されました。拡散などのご協力並びに異議申し立てへの対応ありがとうございました。凍結解除の理由については「システムによる誤検知」と説明されました。 TL;DR事実無根の理由で凍結された異議申し立てしたが音沙汰無し（記事公開時現在7営業日）激おこ凍結時期と理由アカウ

こんにちは。ここ数日は、以下の記事が話題になりました。 named exportは有害だと考えられます「named exportは有害」という主張はこれまで常識と思われていたこととは異なるため、界隈のエンジニアからは否定的・懐疑的な意見が見られます。実際、筆者もnamed exportが有害であるとは1ミリグラムも思っていません。 しかし、自分と異なる意見は当然に下等・幼稚なものであるというのは筆者が最も嫌う考え方ですから、このような異なる意見を分析・理解する必要があると思い、アンサー記事という形でまとめました。具体的には、異なる意見に達する理由としては前提が異なることと論理が異なることが主に挙げられます。前提が異なることが分かれば、自分と異なる意見に至った理由を理解でき、場合によっては取り入れることもできます。論理が違うのであれば、それは瑕疵であり指摘しなければいけません。 なお、そもそ

昨日はこちらの記事に端を発する形で、空のdiv要素やspan要素は妥当なのかといった話題が見られました。 中身のない空の div 要素や空の span 要素は HTML 仕様として妥当なのか？ - dskdこの記事は空のdiv要素やspan要素が妥当かどうかという疑問にHTML仕様の観点から考察を加える大変面白い記事です。記事の結論としては、“僕の結論としては「否」である。”としています。 しかし、いくらHTML仕様を読んだといっても、こういった議論には解釈が入りがちです（こちらの記事でも結論の前に“ここからは完全に僕の解釈として書く。”と明記されています）。 仕様なのに解釈を入れる必要があるのはどうなのと思いつつ、実はこの記事でこれから紹介するように、HTML仕様もなかなか曖昧に書かれており解釈が必要なのは仕方のないことです。 筆者はどちらかというと空のdivを肯定する考えを持っていたの

こんにちは。Reactの話題の中でもかなりの部分を占めるのがステート管理、さらに言えば各種のステート管理ライブラリです。今さらながら、Reactにおけるステート管理の手法やいくつかのステート管理ライブラリを比較考察して記事にまとめました。 useState + バケツリレーReactにおける基本的なステート管理はuseStateです。ひとつのコンポーネント内で完結するようなステートならばuseStateは非常に適しており、他の選択肢はほぼ無いと言っても構わないでしょう。 ステートをアプリケーションの広範囲で使いたい場合が問題です。次の画像に例示されるように、分岐したコンポーネントツリーの末端のコンポーネント（使用者）で同じステートを参照したい場合を考えます。 useStateと組み合わせる場合、もっとも原始的な方法はpropsのバケツリレーによるものです。propsは親コンポーネントから子

TypeScriptでユーザー定義型ガードを定義する場合、引数をany型にして中を自由に書く方法と引数をunknown型にして中でasを駆使して書く方法があります。この記事では両者を比較考察します。結論としては、unknownとasを使うのが型安全性の面からおすすめです。また、うまく関数を分割することでasを消すことも可能で、これも有効です。 ユーザー定義型ガードとはTypeScriptのユーザー定義型ガードとは、型の絞り込み (type narrowing) に使うことができる関数です。ユーザー定義型ガードは返り値が引数名 is 型のような形の型述語 (type predicate) になっています1。このような関数は真偽値を返り値として返し、trueを返すならば引数名が型であることを表します。 例えば、与えられた値がstring | number型かどうか調べるユーザー定義型ガードは次

Reactには、パフォーマンス最適化のためのAPIがいくつかあります。具体的にはReact.memo、useMemo、そしてuseCallbackです。 React.memoで囲まれた関数コンポーネントは、propsが以前と変わっていない場合に再レンダリングが抑制されます。 また、useMemoやuseCallbackは、関数コンポーネント内での値の再計算を抑制する効果を持ちます。 これらは最適化のためのツールなので、「過度な最適化」を避けるように啓蒙する言説がよく見られます。 すなわち、ちゃんと本当に最適化のために必要なところにだけこれらを使おうということです。 特に、React.memoはpropsが以前と変わっているかどうかを判定するためのオーバーヘッドがあるし、useMemoやuseCallbackもフック呼び出しのオーバーヘッドがあります。 意味がないところでReact.memo

近年のフロントエンド開発にはコンポーネントという概念が付いて回ります。React・Vue・AngularといったViewライブラリでは、コンポーネントを定義してそれを組み合わせてアプリを作ります。また、いわゆるWeb Componentsとして知られる仕様群により、ライブラリに依存せずに“コンポーネント”を作ることもできるようになってきています。 コンポーネントは、何らかの機能（あるいは責務）を持った部品です。また、コンポーネントによっては再利用される（アプリ内の複数の箇所から利用される）ことを意図しているものや、そもそもライブラリとして配布されているようなものもあります。アプリの機能の一部分を抜き出したものという見方をすれば、コンポーネントというのは関数にとても類似した概念であることが分かります。 コンポーネント設計によって、言い換えればアプリがどのような機能を持ったコンポーネントたちに

いつもブログをご覧になってくださっている皆さん、こんにちは。そうでない方は初めまして。 2020年もあと1ヶ月となりましたので、この記事では筆者が今年扱った技術について振り返ってみます。 なお、筆者は2019年に新卒で████社に入社し、██████のフロントエンドを担当しています。新卒2年目のフロントエンドエンジニアのみなさんはぜひ参考にしてみてください。 プログラミング言語業務・趣味ともにほぼ全てTypeScriptを使っています。一応、たまに書き捨てのものをJavaScriptで書くことがありますが、一定以上の規模のものを作りたい場合や一定期間以上メンテナンスしたい場合はTypeScriptを使います。また、ASTを扱うときや新しいライブラリを触るときなど、型情報による補完の恩恵が大きい場合もTypeScriptを積極的に使用します。どれにも当てはまらないのでJavaScriptを使

この記事は、ReactでCSSを書くときに関連したCSSを別々のコンポーネントに分けるのをやめようという記事です。主な理由は、スタイリングという機能が複数コンポーネントに分散するのを防ぐためです。これには修正時に複数コンポーネントにまたがって修正が必要になるのを防ぐという意味もあります。 Flexboxの例関連したCSSが複数の要素に分かれることはよくあります。その代表例がdisplay: flexです。例えばこんなレイアウトを考えてみましょう。左側のボックスの幅が決まっていて右側の幅が可変の2カラムレイアウトです。 左のカラム (100px)右のカラムこのレイアウトはおおよそ次のように実現できます。 /* 親要素 */ display: flex; /* 子要素（左） */ flex: 100px 0 0; /* 子要素（右） */ flex: auto 1 0;では、Reactではどの

CSS in JSはJavaScriptのコードの中にCSSを書く手法の総称で、CSS Modulesやstyled-componentsなどがよく利用されています。 この記事では、筆者がCSS in JSについて考えてたどり着いた一つの解を紹介します。 また、そのために作ったライブラリreact-wcを紹介します。 Shadow DOMを活用する筆者がたどり着いた考えは、Web Componentsをそのまま使えばいいじゃんというものです。Web ComponentsはいくつかのWeb標準の総称で、特にここで重要なのはShadow DOMです。 CSS in JSが達成すべき目標の一つはスタイルのローカル化（書いたCSSを特定のコンポーネントに対してのみ適用し、他に影響を与えないこと）ですが、Shadow DOMはこの機能を備えたWeb標準ですから、これを利用することでスタイルのローカル

JavaScriptではsetTimeoutという関数を使うことができます。 しかし、実はこの関数は言語仕様（ECMAScript）に組み込まれているものではありません。 ブラウザ上で動くJavaScriptの場合、setTimeoutはHTMLの仕様によって定義されています。 このHTMLの仕様はHTMLとは名ばかりの巨大な仕様で、今時のブラウザの挙動をほぼ全て規定しているといっても過言ではありません。 さて、setTimeoutにとても大きな数値を渡したときの挙動に関するツイートをTwitterで見かけました。 曰く、setTimeoutに渡す数値は32ビット整数しかサポートされていないというのです。 試してみると、次のようなものは確かに一瞬でタイマーが呼ばれてしまい、想定した挙動とは違うように思えます。 setTimeout(() => { console.log(`${2 ** 5

TypeScriptの型システムは、ユニオン型を始めとする様々な機能を持っているのが特徴的です。 その中でも、mapped typesとconditional typesは高度な機能として知られています。 ところが、その機能の膨大さゆえ、全てを使いこなす必要はない、TypeScriptの複雑な機能を無闇に使うべきではないという言説はたびたび現れます。 そのときに槍玉に上がりやすいのがmapped typesとconditional typesなのです。 筆者は、これらの機能は使えるだけ使い倒すべきであるという考えを持っています。 主張の根幹には、高度な型を使えばより正確にインターフェースを記述することができること、そして正確なインターフェースは使いやすさや正確な型推論結果に貢献することがあります。 正確なインターフェースや型推論結果は、コードの理解速度や開発効率を促進します。 これらは型シ

TypeScriptのユニオン型はとても強力な機能で、TypeScriptのコードベースでは広く利用されています。 例えば、次のようにすると「fooプロパティを持つオブジェクトまたはbarプロパティを持つオブジェクト」という型を表現できます。 type FooObj = { foo: string }; type BarObj = { bar: number }; type FooOrBar = FooObj | BarObj; const fooObj: FooOrBar = { foo: "uhyohyo" }; const barObj: FooOrBar = { bar: 1234 };無いかもしれないプロパティ上のFooOrBar型を持つオブジェクトは、fooプロパティを持つ（FooObj）かもしれないし持たない（BarObj）かもしれません。 これはbarも同じで、つまり「ある

こんにちは。前回の記事でご説明したReact向けのルーターライブラリ「Rocon」をこの度正式リリース（1.0.0リリース）したのでご報告します。 Roconに関する詳しいことは前回の記事をご覧いただきたいのですが、簡単に説明するとRoconの特徴は非常に型安全であることです。 API面での特徴は、/:id/profileのように文字列を用いてルートを定義するのをやめて、代わりにルートを全てオブジェクトとして定義することです。 例えば、/:id/profileに相当するルート（:idの部分は任意の文字列を入れてアクセス可能という意味になります）はRoconでは次のように定義します。 const topLevel = Rocon.Path() .any("id"); const secondLevel = topLevel.anyRoute .attach(Rocon.Path()) .ro

こんにちは。先月くらいからReact向けのルーターライブラリ「Rocon」を作っていて、この度alphaリリースという形で公開まで漕ぎ着けたので宣伝します。 現在のところ、以下のURLでチュートリアルを読むことができます。 このチュートリアルサイトはRoconを用いて作られています。 Roconチュートリアル: https://rocon.uhyohyo.net/Roconの特徴は非常に型安全であることです。 何よりも型安全性・型周りの快適性を優先してAPIが設計されています。 当然、TypeScriptと一緒に使うことが前提です。 また、Roconはreact-router-domの代替となることを意図しています。 そのため、Roconを使うべきとき・使うべきでないときをまとめると以下のようになります。 Roconを使うべきとき: 今react-router-dom等を使ってSPAを作っ

こんにちは。先月くらいからReact向けのルーターライブラリ「Rocon」を作っていて、この度alphaリリースという形で公開まで漕ぎ着けたので宣伝します。 現在のところ、以下のURLでチュートリアルを読むことができます。 このチュートリアルサイトはRoconを用いて作られています。 Roconチュートリアル: https://rocon.uhyohyo.net/Roconの特徴は非常に型安全であることです。 何よりも型安全性・型周りの快適性を優先してAPIが設計されています。 当然、TypeScriptと一緒に使うことが前提です。 また、Roconはreact-router-domの代替となることを意図しています。 そのため、Roconを使うべきとき・使うべきでないときをまとめると以下のようになります。 Roconを使うべきとき: 今react-router-dom等を使ってSPAを作っ

SPAを作る際は、URLを変化させたり、URLの変化に反応して画面を変えたりする必要があります。このために使われるのがルーティングライブラリです。Reactにおいては、react-routerが代表格として知られています。 react-routerでルーティングが制御されている場合、その中のコンポーネントが現在のURLを表すオブジェクトであるlocationを得るための方法は大別して2つあります。一つはuseLocation、もう一つはuseHistoryです。なお、これらのフックはreact-routerのv5.1で追加されました。この記事ではこれ以前の方法は取り扱いません。 この2つの方法のどちらを使ってもlocationを得ることは可能ですが、どちらを使うべきかは場合によって明確に異なります。間違った方を使うと、パフォーマンスが低下したり期待通りに動かなかったりという問題が発生するこ