Year after year, React bucks the trend of the ever-changing web development landscape by subbornly refusing to become obsolete, and evolving with the times–or sometimes even ahead of them. And with generative AI's reliance on existing codebases in order to spew out new code, could React become even more entrenched and effectively become the first “forever framework”? We won't know the answer to th
Today we're excited to release React Native 0.84! This release makes Hermes V1 the default JavaScript engine, bringing significant performance improvements to all React Native apps. We've also continued removing the Legacy Architecture on both iOS and Android, and are shipping precompiled iOS binaries by default. Highlights Hermes V1 as Default Precompiled Binaries on iOS by Default Legacy Archit
We've encapsulated 10+ years of React and Next.js optimization knowledge into react-best-practices, a structured repository optimized for AI agents and LLMs. React performance work is usually, well, reactive. A release goes out, the app feels slower, and the team starts chasing symptoms. That’s expensive, and it’s easy to optimize the wrong thing. We’ve seen the same root causes across production
はじめに Reactでコンポーネントを開発していると、同じような状態管理ロジック（ホバー検知、フォーム入力、API呼び出しなど）を複数の場所で書いていることに気づきます。 以前のReactでは、このような状態ロジックを共有するためにHOCやRender Propsパターンが使われていました。しかし、これらのパターンはネストが深くなったり、propsの出所が分かりにくくなるという問題がありました。 Hooksパターンは、状態を持つロジックを関数として抽出し、複数のコンポーネントで再利用可能にする手法です。 本記事では、Hooksパターンの構造と適用判断基準を解説し、現代のReactにおけるデータ取得や状態管理のベストプラクティスについても考察します。 第1章：このパターンが解決する問題 状態ロジックの重複 コンポーネント間で同じような状態管理ロジックが重複する場面があります： 複数のコンポー
All Articles As developers, what we are optimizing for is basically how fast we can show meaningful content to the end user, at an optimal infra cost. When the final UI depends on some data from an external source, how we fetch that data has a direct impact on how soon we are showing the final UI to the user. For the last decade, we have treated data fetching as a specific "moment in time." Part 1
はじめに この記事のゴール Reactを使っていると、useStateやuseEffectを「こう書けば動く」という形で覚えていることが多いのではないでしょうか。 const [count, setCount] = useState(0); useEffect(() => { console.log(count); }, [count]); このコードは動きます。しかし、なぜ動くのかを説明できるでしょうか。 なぜuseStateは配列を返すのか なぜsetCountを呼ぶと再レンダリングされるのか なぜuseEffectの依存配列に値を入れると、その値が変わったときだけ実行されるのか なぜHooksを条件分岐の中で呼んではいけないのか この記事では、これらの疑問に答えるために、Hooksの仕組みを実際に実装しながら学んでいきます。最終的には、Hooksが「魔法」ではなく、JavaScrip
この記事は React Advent Calender 2025 11 日目の投稿です。 可読性の高いカスタムフックを考える React 開発において、「ロジックはカスタムフックに切り出す」というプラクティスは、私たちの思考に深く根付いています。しかし、筆者の経験上、「なんとなく」でカスタムフックに切り出されたロジックは、かえってコードの可読性を下げることが多いと感じています。コンポーネントの挙動を理解するために別ファイルを行き来し、分断されたロジックを頭の中でつなぎ合わせなければならないコードは可読性が低く、改修や不具合の調査を難しくします。 本記事では、React のカスタムフックが、かえってコードの可読性を損なってしまうアンチパターンと、その回避策について考察します。「ロジックはカスタムフックに切り出す」という一般的なプラクティスの落とし穴を明らかにし、コンポーネントの凝集度と透明性
はじめに Radix UI の普及とともに asChild プロパティが広く採用され、コンポーネントの柔軟な合成が可能になりました。しかし、その利便性の裏で型安全性の欠如という課題が指摘されています。 TypeScript による型チェックが十分に機能しないこと、React.cloneElement への依存による予期しない挙動、そして React Server Components との互換性の問題——これらが主な課題です。 本記事では、asChild の技術的な課題を掘り下げます。React.cloneElement がどのように機能し、なぜ型安全性が損なわれるのかを探りつつ、render prop、as prop、hooks といった代替の合成パターンを比較検討します。Radix UI、Ark UI、Ariakit、Headless UI、Base UI、React Aria がそれ
Denial of Service and Source Code Exposure in React Server Components Security researchers have found and disclosed two additional vulnerabilities in React Server Components while attempting to exploit the patches in last week’s critical vulnerability. These new vulnerabilities do not allow for Remote Code Execution. The patch for React2Shell remains effective at mitigating the Remote Code Executi
There is an unauthenticated remote code execution vulnerability in React Server Components. We recommend upgrading immediately. On November 29th, Lachlan Davidson reported a security vulnerability in React that allows unauthenticated remote code execution by exploiting a flaw in how React decodes payloads sent to React Server Function endpoints. Even if your app does not implement any React Server
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く