A. ユースケース次第でどう実装すべきかは変わる。Intl.Segmenter が万能というわけでもない。 (クソ最悪な小バズをかましてしまったので、贖罪も兼ねて記事を書きました) 「文字数を数える」のは難しい 「文字数を数える」実装は意外と難しいです。というのも、アルファベットや数字だけなら str.length でも正しく数えられますが、絵文字や異体字などが入った文字列は見た目どおりに数えられません。

答え(結論): レンダリングとエフェクトを分離するため クリーンアップを設定するため useEffect でラップする意味ってなくない? 以下の2つのコードはどちらもレンダリングすると Hello world と表示され、ページタイトルが Hello world になります。 const App1 = () => { useEffect(() => { document.title = 'Hello world'; }); return <h1>Hello world</h1> }; 同じ動作をするのであれば、なぜ useEffect でラップする必要があるのでしょうか? 理由1: レンダリング時に react の内部動作を考慮しなくて済む useEffect を使っていない App2 は、react が DOM 更新している最中に document.title = 'Hello worl

useEffectEvent という react フックをご存知ですか? まだ experimental なので、知らない方も多いと思います。しかし、このフックは 「なんで今までなかったんだろう?」と思ってしまうほど革新的 です。今回はその使い方の紹介などをします。 概要: useEffectEvent は useEffect とともに使うフック まず概要ですが、useEffectEvent は イベントリスナーを設定する useEffect とセットで使うフック です。 useEffectEvent を使うと、エフェクトとイベントリスナーを分離できます。そして、イベントリスナーの deps の変化時にエフェクトを再実行せずに済みます。 …とまあ、抽象的な説明だけでは分かりづらい と思うので、以降では useEffectEvent がどういう課題を解決するのか、また具体的にどういうケースで

最近、package by feature というディレクトリ構成が様々なところで出てきています[1]。例をあげると、これらで見れます。 next.js の app router bulletproof-react 他人がはやく読めるコードを書くために しかし、package by feature について簡潔にまとまった資料がまだないため、人に紹介するときに不便です。そこで今回は package by feature とは何なのか、何が良いのかについてまとめます。 package by feature とは? package by feature とは、ディレクトリを feature 単位でまとめる手法のことです。 # package by feature src/ └ feature/ └ recordList/ (記録を表示するための機能群) ┝ DailyAverage.tsx ┝

この記事の目標 「最終的に JavaScript になるのに、なんでわざわざ TypeScript を使うべきなのか? JavaScript で良くない?」 という質問に答えられるようになる なぜ TypeScript を使うべきなのか? いきなり結論を書きます。 A. 実行時エラーの少ない JavaScript を使いたいから TypeScript で書かれたコードはコンパイルが通らないと JavaScript に変換できません。そのため、生成される JavaScript コードは必ずコンパイルに成功したものです。コレが TypeScript を使っていて一番嬉しいポイントです。 まあ、いきなり結論を書いてもよく分からないと思います。順に話していきます。 型エラーとはなにか TypeScript でコンパイルを通すには、コード上の型エラーを無くす必要があります。 型エラーとは、型システム

最初に: clean architecture は誤解されている 『Clean Architecture 達人に学ぶソフトウェアの構造と設計』(以下『Clean Architecture』)を読んだことがありますか?例の同心円の図しか知らないという人も多いでしょう。 画像出典: Robert C. Martin 「The Clean Architecture」 さて、ここでクイズです。「Clean architecture とは、 controllers や use cases、entities というクラスを作って繋げるアーキテクチャのことだ、○か×か」。どっちでしょうか? → → → 正解は×です。 あの同心円は、あくまで clean architecture の一例として『Clean Acrhitecture』で紹介されたものです。 そう、clean architecture とはア

React Advent Calendar 2022 2日目の記事です。 本記事はごく簡単なコンポーネントから始めて、react のレンダリングについて学び直す記事です。学び直し(!=入門記事)なので JSX、TS の説明などはしません。 本記事の対象読者 ある程度 react を触っていて、もっとレンダリングについて理解したい人 より良いコンポーネントを書きたい人 本記事のコードについて 特に断らないかぎり、本記事に出てくるコードは以下のコードを省略したものです。実際に動かせる codesandbox も用意したので、そちらも参照ください。 import { createRoot } from 'react-dom/client'; const App = /* 実装 */; createRoot(document.querySelector('#main')).render(<App

はじめに(訳者): 僕は英語が大得意なわけではありません。温かい気持ちで読んでください。また、原文もぜひ併せて読んでください。 これは Kent C. Dodds による記事 Testing Implementation Details の翻訳です (当時の皆と同じように)私が enzyme を使っていた頃、私は enzyme の特定の API を慎重に扱っていました。shallow rendering は完全に避け、 instance() や state()、find('ComponentName') は 使ったことさえ ありません。 また、他の人の pull request のコードレビューの時には、なぜこれらの API を避けるべきか何度も何度も説明してきました。それは、これらの API がコンポーネントの実装の詳細をテストできてしまうからです。よく 「実装の詳細」とは何を意味するの