Reactは関数型の思想で UI = f(状態) を実現している一方で、useEffect のように副作用を扱う仕組みも提供しています。 純関数を前提とした設計なのに、副作用を持ち込んでなぜ成り立つのかが気になったため、整理してみました。 useEffectって何？ 分解するとuse + Effect = エフェクトを扱うという意味になると思います。 じゃあ、エフェクトって何かというと エフェクトは、特定のイベントによってではなく、レンダー自体によって引き起こされる副作用を指定するためのものです。 と記載があります。 例えば、チャットでのメッセージ送信は、ユーザが特定のボタンをクリックすることによって直接引き起こされるため、クリックという特定のイベントです。 しかし、サーバ接続のセットアップは、コンポーネントが表示される原因となるインタラクションに関係なくレンダー自体によって行われるべきで
はじめに Reactで複雑なUIコンポーネント（Select、Tabs、Accordion、Modalなど）を作成する際、大量のpropsを渡す「Props地獄」に陥ることがあります。 <Select options={options} value={value} onChange={setValue} placeholder="選択してください" renderOption={(option) => <CustomOption {...option} />} renderHeader={(selected) => <Header selected={selected} />} onOpen={() => {}} onClose={() => {}} // ...さらに多くのprops /> このようなAPIは認知負荷が高く、想定外のカスタマイズが困難です。 Compound Compone
株式会社 Sally エンジニアの @piesukeです。 弊社では、マーダーミステリーをプレイできるアプリ「ウズ」と、マーダーミステリーを制作しウズ上で利用できるアプリ「ウズスタジオ」を開発しています。 最近良かったマーダーミステリーは「青いクジラは沈まない」です。 複数のWebサービスを展開する弊社では、開発効率の向上と車輪の再発明防止のため、頻繁に使用されるコンポーネントを共通コンポーネントとして管理しています。 しかし、共通コンポーネントは多岐にわたる箇所での利用を想定する必要があり、設計上の考慮が不足すると、結果として使いづらいコンポーネントとなることがあります。 本稿では、共通コンポーネントの作成・運用経験から得られたアンチパターンを紹介します。 前提：弊社のコンポーネントの共通化の運用 turborepoを使ったモノレポで運用している デザイン時に何度も使われるコンポーネント
1. はじめに：何が起きたのか 2025年12月3日、Next.js および React Server Components (RSC) の通信プロトコルにおいて、認証不要でリモートコード実行 (RCE) が可能となる重大な脆弱性が公表されました。 今回、特に事態を重くしている要因は以下の2点です。 土台である React 起因の欠陥 Next.js 固有の実装ミスではなく、その基盤である React (RSC) の処理機構そのものに脆弱性が存在しました。そのため、フレームワーク側での表面的な対処ではなく、根本的な修正が必要となりました。 標準構成での影響 何か特殊な設定をした場合に限らず、Next.js (App Router) の「デフォルトの状態」で RSC が動作しているため、普通に利用しているプロジェクトのほぼ全てが影響対象となってしまいました。 開発者のミスではなく、私たちが信
Reactにおいてプロダクトの品質を高く保つには、Reactのやり方に合ったコードを書くことが重要です。公式ドキュメントの名物ページ「そのエフェクトは不要かも」には、useEffectの望ましくない使い方と、それに代わるテクニックが紹介されています。 この記事で取り上げるのは、その中でも「props が変更されたときに一部の state を調整する」のセクションで紹介されている、レンダリング中にステートを更新するテクニックです。 このテクニックは一見すると奇妙で、知ってはいるけど使っていいのかよく分からないという方も多そうです。しかし、一見突飛に見える記述でも、深く理解すれば実はReactのデザインに完璧に則っているというのがReactの公式ドキュメントの特徴です。技術に対する向き合い方として、公式の説明であっても妄信せず批判的に見ることはとても重要です。しかし、Reactの場合は最終的に
この記事は、AIが生成した記事を無修正で公開しています。投稿者（人間）の普段の作風・意見と異なる点や内容の粗もありますが、技術記事として公開するに足るクオリティであるという投稿者の判断と責任により投稿するものです。 ただし、記事に含まれる、経験に基づくエピソードは全てAIによる創造である点はご了承ください。 ちなみに、記事の生成は事前に用意したスタイルガイドに基づき、人間が記事のアイデアと結論を与えてAI (Claude Code) が出力したものであり、出力結果に対する追加の修正依頼などは行わない一発撮りです。 皆さんこんにちは。最近、データ再取得の実装パターンについて考えていて、面白い気づきがあったので共有します。 Reactでデータを再取得したいとき、普通はrefetch()みたいな関数を呼ぶ実装になります。ボタンを押したらサーバーからデータを取り直す、みたいなやつです。でも、これっ
なぜ useImperativeHandle が必要になったのか？ 実体験：フォームビルダー開発での課題 先日、ドラッグ&ドロップでコンポーネントを配置するフォームビルダーを Next.js で開発していました。その際に直面した課題が、複雑な状態管理でした。 最初の実装：state のバケツリレー地獄 最初は従来通り、state のバケツリレーでの実装を考えていました： // 親コンポーネントで全ての状態を管理 const [formLayout, setFormLayout] = useState({}); const [saveStatus, setSaveStatus] = useState("idle"); const [tempSaveData, setTempSaveData] = useState({}); // 深い階層の子コンポーネントまでpropsでバケツリレー <Fo
Hyper is a standards first markup language for building user interfaces. It enables developers (and AI models) to generate complex UIs with amazingly clean syntax. Project goals Standards first: User interfaces should be assembled with HTML, styled with CSS, and enhanced with JavaScript. Simplicity: UI composition should be easy and require as few idioms and abstractions as possible, both on clien
useEffectの中でfetch （取得系のリクエスト）しないでください。以上です。ご清聴ありがとうございました。いいねと高評価、チャンネル登録よろしくお願いします。 おまけ とはいえ、useEffectの中でデータ取得することを考えなければいけない場合もあります。例えば、React 16をまだ使っている場合とか。React 18以降ならSuspenseがあるので考えなくていいです。 ということで、筆者は最近React 16の世界でどうしてもuseEffectの中でfetchしなければならない場合を最近経験しました。その場合にもできる限りベストプラクティスに従いたいということで、考えたことを紹介します。 まだReact 16系に囚われている方は参考にしてください。また、新しいReactを使っている方はこの記事で紹介することをそのまま実践する必要はありませんが、useEffectのベストプ
はじめに Vitest はデフォルトの設定では、テストファイルごとに分離された環境を使用してテストを並列実行します。 この設定はグローバルな状態や副作用に依存した実装やライブラリなどを含むテストを並列実行するために有効です。 しかし、この設定は各テストファイルごとにテスト環境の起動や破棄を行うためテスト実行時間が長くなります。 この記事では React アプリケーションのテストコードを、環境の分離設定をやめて同一環境で実行することにより、実行速度を向上させた方法とそれに伴って発生した問題の修正方法についてご紹介いたします。 背景 弊社は microCMS というヘッドレス CMS を開発しており、その管理画面は React で開発されています。 大まかな構成としては、Vite を使用した SPA で、テストコードは testing-library/react を使用したコンポーネントテスト
First and foremost, thank you to everyone who has contributed to styled-components over the years. Open Source is hard work, and many of the larger feature and/or refactoring drives probably would never have shipped without your support! As I write this in 2025, styled-components as a project is in "maintenance mode". There are a number of reasons for this: The React core team has decided to defac
カミナシで、Webフロントエンドエンジニアをしている osuzu です。 これまでフロントエンド専門外のエンジニアからReactを学ぶ良い方法やお勧めドキュメントを聞かれる度に、 公式ドキュメント のリンクを貼る日々を過ごしてきましたが、何かすごい上達方法がないものかと普段意識していることをこの記事で書き起こしてみました。 文字にした結果、中身になにか特別なことや魔法のテクニックは一つもなく、むしろプログラミング一般に通ずる話ばかりになりましたが、（自戒も込めて）凡事徹底することの難しさもあると感じておりその一助になれば幸いです。 ※ 凡事徹底：平凡なことを非凡なほどに実行すること。一つ一つの理解や実行は平易でも、それを実践し続けるのは難しい。 React Server Component（以下RSC）を採用するかで変わる部分もありますが、記事の例はClient Componentの話が中
Reactはシンプルなサイトから複雑なアプリケーションまで、非常に幅広く採用されている人気のフレームワークです。OSS化から10年以上の歴史がありながら、昨今もReact Server Componentsなど革新的なアイディアを我々に提案し続けています。 一方で、React Server Componentsへの批判的意見やBoomer Fetching問題などを見ていると、Reactチームと一部Reactユーザーの間には意見の相違が見て取れます。この意見の相違はそれぞれが置かれた状況の違いから生じるもの、つまり「見てる世界が違う」ことに起因してると筆者は感じています。 本稿では「Reactチームの見てる世界」を歴史的経緯を踏まえながら考察し、Reactの根本にある思想やコンセプトに対する読者の理解を深めることを目指します。 要約 ReactはMetaの大規模開発を支えるべく開発され、シ
始め Reactのmapを使う時、keyエラーをなくすためindexを使ったことがあります。しかし最近それがanti-patternだということを知りましたので、その理由をまとめました。 1. keyの存在意義 1-1. keyってなんだっけ そういえばそもそもkeyって何で必要だったけ…？と、ふいと思ってしまいました。何となくは知ってますが、明確にしたいのでこの部分から始めましょう。 まずはこのサンプルコードをご覧ください。 export default function App() { let fruits = [{ name: "apple" }, { name: "banana" }, { name: "pear" }]; return ( <div className="App"> {fruits.map((fruit) => ( <p>{fruit.name}</p> ))}
はじめに 今回はSWRとTanStack Queryの比較によってそれぞれの特徴と違いを整理したいと思います。背景としてネット上にある両者の比較記事は2022年以前のものが多く、当時に比べSWR2.0がリリースされたことなどで比較の観点が変化したように感じました。改めて整理することで技術選定の参考になればと思います。 前提 今回は以下のバージョンを前提にします。（2023/08/26時点でLatest） SWR v2.2.0 TanStack Query v4.34.0 また、私自身はTanStack Queryを業務で1年ほど扱ったことがありSWRは全く経験がない状態です。この記事はどちらが優れているかを示すためのものではなく、あくまで客観的に比較することを目的にしています。 目次 ここでは以下の3つの観点から比較を行い考察をします。 interfaceでの比較 機能面での比較 キャッシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く