Hono × Inertia.js が作る新しい型貫通体験に触れてみた
// サーバー側（Hono） app.get('/posts/:id', (c) => { const post = findPost(c.req.param('id')) return c.render('Posts/Show', { post }) }) // クライアント側（React） export default function Show({ post }: PageProps<'Posts/Show'>) { return <h1>{post.title}</h1> } post の型は Post として完全に推論される。間に API 定義も DTO も tRPC もスキーマ生成もない。サーバーで c.render() の第2引数に渡したオブジェクトが、そのまま React の props として、しかも完全に型付きで届く。 「API なし SPA」を謳う Inertia.j
Introduction - React Three Fiber
Three-fiber is a React renderer, it must pair with a major version of React, just like react-dom, react-native, etc. @react-three/fiber@8 pairs with react@18, @react-three/fiber@9 pairs with react@19. Does it have limitations? None. Everything that works in Threejs will work here without exception. Is it slower than plain Threejs? No. There is no overhead. Components render outside of React. It ou
Async React の設計思想と Signal の違いを Transition を中心に考える - KAKEHASHI Tech Blog
ランキング参加中プログラミング こんにちは。フロントエンドエンジニアをしているNokogiri（@nkgrnkgr）です。 はじめに 私たちのReactをつかったプロダクトでは Suspense をデータフェッチに利用しています。useTransition や useOptimistic も触ったことはありましたが、プロダクションでどう活かすかという解像度がまだ上がっていませんでした。 そんなとき、uhyo さんの「React 19時代のコンポーネント設計ベストプラクティス」や「Async Reactとは何か」を読んで、Async React の全体像をちゃんと理解したくなりました。実際にコードを書きながら手を動かし、自分なりに解釈した内容を社内勉強会で共有する機会があったので、本記事ではその内容を整理してお伝えします。 Async React の全体像のうち、特に Transition
React Compiler導入で得られた効果と気をつけたいポイント - KAKEHASHI Tech Blog
はじめに こんにちは。フロントエンドエンジニアの大村です。 みなさん、React Compilerはもう試しましたか？ React 19とともに登場したReact Compilerは、これまで手動で書いていたuseMemoやuseCallback、React.memoを自動的に適用してくれるコンパイラです。手動メモ化から解放されるという期待感がある一方で、現段階で導入してよいものなのか迷っている方も多いのではないでしょうか。 今回は、私たちのチームで実際にReact Compilerを導入した経験をお伝えします。導入してみた結果としては、大半のコンポーネントでは期待通りにメモ化されて効果を確認できました。ただし、一部のライブラリとの組み合わせでは注意が必要だったので、そのあたりも詳しく紹介します。 導入の背景 現在私たちのチームで開発しているプロダクトはVite + React 19（v1
Claude CodeのReact習熟度を測る
皆さんこんにちは。コーディングエージェントの発展により、プログラムの多くの部分をAiが書いてくれるようになりました。 しかし、筆者が得意とするReactに関しては、動くものを作ることはできるにせよ、人間が十分に指図しなければ質のいいコードが書けないことも多いと感じています。 そこで、今回は、Claude CodeのReact習熟度を測るための簡単なベンチマークを作ってみたので、その結果を共有します。 注意と予防線 ベンチマークと名乗ると、粗探しをしたい方々が寄ってくる傾向があります。その前に、今回の設定が以下のとおりであることをご理解ください。 あくまで筆者が考える「習熟度」を測っています。特に、Reactのベストプラクティスを適切に運用すること、新しいAPIも使いこなして適切な場面で適切なAPIを利用できることを重視しています。 ベンチマーク対象はClaude Codeの3つのモデル（H
Async React時代の宣言的UI: デバウンスの例
宣言的UIとは何か、皆さんは答えられるでしょうか。 「あーあの、DOM更新を直接プログラムに書くんじゃなくて、JSXとかであるべき状態を宣言したらライブラリが自動的に差分適用とかでDOMを更新してくれるやつでしょ？」 もちろん、このような答えは間違いではありません。しかし、特にAsync Reactの時代においては、Reactの考えはさらに先を行っているようです。 究極的には、宣言的UIは、やりたいことをロジックとして記述するだけで、具体的なことや細かい最適化はよしなにやってくれるものだという考えが伝わってきます。上述のようなDOMの更新の話はその一例にすぎません。 やりたいこと: 特定の形のDOMを画面に表示したい。 具体的なこと: Reactランタイムがコンポーネントツリーを実行してDOMを更新する。 最適化: DOMをいい感じに差分更新する。 また、useStateなどといったステー
React 19時代のコンポーネント設計ベストプラクティス
2026-02-18 React 19、コンポーネント設計どう変わった？〜うひょさんに聞く最新 実務Tips〜
ポップコーンUIとReact
ページアクセス時に複数のローディングスピナーがランダムに表示され、徐々にコンテンツに置き換わっていくような体験に遭遇したこと、もしくは実装した経験はあるでしょうか？ReactチームはこのようなUIを、ポップコーンが弾ける様子に例えてポップコーンUIと揶揄しています。 このようなUIはユーザー体験として好ましくありませんが、よくみられるUIでもあります。Reactにおいて、コンポーネント内でデータフェッチを扱う方法は様々ありますが、複数のコンポーネントでローディング状態をハンドリングしてしまうとポップコーンUIになりがちです。 開発者が意図してより良い体験を実装すべきとも考えられますが、単独のコンポーネントで見ると自然な実装になってしまうことは構造的な問題とも捉えられます。特に、AI Agent時代においてはコンポーネント単体を考慮する機会が多いと考えられるので、AI Agentがシンプルに
design-loop: Claude Codeを使ったブラウザベースのビジュアル編集ツール
Claude Codeを使ったブラウザベースのビジュアル編集ツールとして、design-loopを作りました。 GitHub: https://github.com/azu/design-loop 左パネルに開発中のサイトのプレビュー、右パネルにClaude Codeのターミナルが表示されます。プレビュー上の要素をクリックすると、その要素のコンポーネント情報やスタイルがClaude Codeに渡されます。 インストール curl -fsSL https://raw.githubusercontent.com/azu/design-loop/main/install.sh | sh 使い方 ソースコードがあるディレクトリで、開発サーバーがすでに起動している場合は、--urlでURLを指定するだけで起動できます。 design-loop --url http://localhost:3000
【React 19】useImperativeHandleが格段に使いやすくなった！子コンポーネントの機能を「公開」する方法
なぜ useImperativeHandle が必要になったのか？ 実体験：フォームビルダー開発での課題 先日、ドラッグ&ドロップでコンポーネントを配置するフォームビルダーを Next.js で開発していました。その際に直面した課題が、複雑な状態管理でした。 最初の実装：state のバケツリレー地獄 最初は従来通り、state のバケツリレーでの実装を考えていました： // 親コンポーネントで全ての状態を管理 const [formLayout, setFormLayout] = useState({}); const [saveStatus, setSaveStatus] = useState("idle"); const [tempSaveData, setTempSaveData] = useState({}); // 深い階層の子コンポーネントまでpropsでバケツリレー <Fo
Metaに学ぶ、大規模開発のデータフェッチ設計と最適化
本稿で扱うデータフェッチは高速なサーバー間通信を前提にしているため、バックエンドは細粒度なREST APIで設計することが最適だと考えます。 データフェッチの設計パターン 筆者の考えでは、データフェッチの設計は大きく2パターンに分けられます。データフェッチ層を設けるなどするような中央集権型の設計と、データフェッチコロケーションに代表される自律分散型の設計です。 中央集権型: 責務を集約し、一元管理を重視する 自律分散型: 責務を末端に分散し、自律性を重視する MetaやReactにおける自律分散型の設計の歴史については、筆者の前回の記事で詳細に解説しています。興味のある方はご参照ください。 解説 冒頭で触れたように、Metaでは自律分散型の設計が重視されており、特に大規模開発の保守性において重要だと考えられています。データフェッチ層を設けるような中央集権型の設計はなぜ好まれないのでしょう？
State of React 2025
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
GyazoのReactのバージョンをv17からv19にアップグレードし、React Compilerを有効にしました - Helpfeel Developers' Blog
Gyazo開発チームでアプリケーションエンジニアをしているid:Pasta-Kです。先日Gyazoで使っているReactのバージョンが19.2.4になり、そしてReact Compilerも導入されました。現代ですね。この記事では、Gyazoで利用しているReactをv17からv18、さらにv19へとアップグレードした際の取り組みについて紹介しようと思います。 （この記事はGithub Copilotが過去のgit logやPull Requestなどをもとに書いてくれた文章を加筆修正したものです） facebook/fluxからの脱却 移行先のアーキテクチャについて FluxのStoreをSWRを同期させて漸進的な移行を 漸進的移行の効果 HOCによるClass ComponentとHooksの橋渡し HOCでHooksをPropsとして注入する Flux完全削除 react-boots
Reactで実装したフォームのパフォーマンスが問題になるのはなぜか
RelayHub合同会社の久保田光則です。 Reactでフォームを効率よく実装するためのライブラリとして、React Hook FormやReact Final Form、TanStack Formなどがあります。これらのライブラリは、フォームを効率よく実装できる枠組みを提供してくれるだけではなく、高速なフォームを実装するための方法も提供してくれます。 で、この記事ではReact Hook Formとかそういうライブラリの使い方というよりかは、そもそもなぜReactで実装したフォームのパフォーマンスが問題になりやすいのか、その辺りの事情について解説します。 Reactのレンダリングの仕組み Reactでは皆さんご存知のとおり、仮想DOMと呼ばれるDOMに似た構造のオブジェクトを生成してレンダリングを行います。Reactのコンポーネントはレンダリングするたびにそのコンポーネントに対応する仮想
祝v1リリース🎉新たなヘッドレスUIライブラリBase UIが良さそう
この記事は React Advent Calender 2025 18 日目の投稿です。 （追記履歴） 2026/01/17 初版の投稿 2026/01/25 shadcn/ui で従来使用されてきた shadcn@latest add コマンドでも対応したことを追記 はじめに alpha 版時代から個人的に注目していた React 専用のヘッドレス UI ライブラリ Base UI が v1 リリースされました 🎉！ これがかなり良さそうなので今回紹介しようと思います！ 元々は MUI 発のライブラリ GitHub リポジトリ名で察する方も多いかもしれませんが、元々 MUI（Material UI）の姉妹ライブラリとして開発されていた MUI Base というライブラリが始まりです。Unstyled な MUI として開発が進められていましたが、Material Design の適用な
なぜshadcn/uiは支持されたのか ― Providerモデル以後のUI設計
shadcn/uiとは shadcn/uiはRadix UIが提供するスタイルを持たないHeadless UIコンポーネント群(Radix Primitives)をベースに、Tailwind CSSを用いてデザインされた「コンポーネントのテンプレート集」である。 公式サイトには次のように記されている。 This is not a component library. It is how you build your component library. (これはコンポーネントライブラリではない。あなた自身がコンポーネントライブラリを構築するための方法である) shadcn/ui は、npm パッケージとして完成された UI コンポーネントを提供するのではなく、コードそのものをプロジェクトに取り込み、所有するという前提に立っている点が特徴的だ。 このアプローチが具体的にどのような意味を持つの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Inertia.js - The Modern Monolith
Remotion | Make videos programmatically
GitHub - recruit-tech/location-state: State management library for React that synchronizes with history entries supporting Next.js App Router.
GitHub - millionco/react-doctor: Let coding agents diagnose and fix your React code
