皆さんこんにちは。最近とある事情でTailwind CSSにわりと真剣に向き合わないといけなくなった筆者です。 Tailwind CSSの話題は、Twitterのフロントエンド界隈では定番のトークテーマのひとつです。しかし、筆者の考えを文章にまとめたことは無かったので、このたびブログ記事にすることにしました。 結論筆者が一番みなさんに伝えたいことは、Tailwind CSSは考え無しに採用してよい技術ではなく、採用するには熟慮が必要だということです。とくに、フロントエンドのスターターキット的なプロジェクトの中にTailwind CSSが混ざっていることがありますが、あれはけっこうな罠です。気軽に採用すべきものではありません。 筆者の考えでは、Tailwind CSSの採用を考慮に入れてよいのは次の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営業日）激おこ凍結時期と理由アカウ

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

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

いつもブログをご覧になってくださっている皆さん、こんにちは。そうでない方は初めまして。 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標準ですから、これを利用することでスタイルのローカル