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での比較 機能面での比較 キャッシ
Riveってなに？ Riveはリアルタイムでインタラクティブなアニメーションを作成できるツール ReactやFlutterといったフレームワーク向けライブラリを提供 作成したアニメーションを簡単にアプリへ統合できる！ Riveが使われているプロダクト ◆ Duolingo キャラクターの動きやリップシンク（音声に連動した口の動き）をリアルタイムで制御し、学習体験を豊かにしています！ ◆ Notion AIアシスタントの細かな表情や動きをリアルタイムで制御し、対話をより親しみやすく、楽しい体験にしています！ Rive 3つの魅力！ Riveが多くのプロダクトで活用されている理由は、その使いやすさと可能性の広がりにあります。 1. 🤝 デザイナーとエンジニアの連携がスムーズ 従来、デザイナーが作ったアニメーションをエンジニアが再現するには手間がかかりましたが、 Riveではコードでアニメーシ
こちらは「medicalforce New Year's Blog 2025」8日目の記事です。 今回はUI構造が変わっても状態を保持したいときに便利なReact-Reverse-Portalというライブラリを紹介しようと思います。 解決する課題 例えば、タブレット向けの画面実装で横向きのときは2-column型のレイアウトで表示して縦向きのときはタブを使ったレイアウトで表示したいということがあったとします。 Reactのコードで表現するとおおよそ以下のような実装になるかと思います。 export default Page = () => { // 中略 return isLandscape ? ( <Grid cols={2}> <GridItem> <Content1 /> </GridItem> <GridItem> <Content2 /> </GridItem> </Grid>
はじめに フロントエンド開発 においてレンダリングという言葉はさまざまな場面で登場します。さらに、Server-Side Rendering(SSR)のように「レンダリング」という言葉が名前に含まれているものを含め、Single-Page Application(SPA)など、レンダリングに関連した議論でよく使われる用語も数多く存在します。 そして、これらの用語の意味はフロントエンドの技術の進化に伴い、徐々にニュアンスが変化してきているように感じています。 他のエンジニアとこれらの用語について話す中で、「自分はそれをSSRとは呼ばない」「SPAにはいくつかの意味があるよね」といった意見を耳にし、人によって解釈が異なることを実感しました。 では SSR や SPAなどといった用語は今日どういった意味で使われているのでしょう。そもそも、「レンダリング」とはどういう意味なのでしょうか。SSR に
この記事は株式会社カオナビ Advent Calendar 2024の23日目の記事です。 Jotai は、Reactで使えるステート管理ライブラリとしては、現状筆者が最も好んでいるものです。その理由は単純で、ステート管理アーキテクチャとして優れていると思うからです。Recoilが現役のころは同じ理由でRecoilを好んでいました。 Jotaiは2023年1月にv2がリリースされました。非同期処理の扱いがv2はそれより前と異なっており、簡単に言うとJotaiのコアから非同期処理（Promise）に対する特別扱いが排除されました。これにより、コアのAPIをReactから切り離すことができたとされています。JotaiはReactから使われることが多いとはいえ、以下のスライドでもJotaiが「Reactに依存しないライブラリ」として評価されていることからも分かるように、このような特徴は技術の普及
すべての状態をできるだけ減らしたいypresto (プレスト) です。 12月頭に予約してたアドベントカレンダーですが12/23になってしまいました。 LayerXのバクラク事業部では、Webフロントエンド領域もがんばっています！！ ということで一筆。 バクラク事業部のエンジニアは、バックエンド・フロントエンドの垣根なくプロダクト開発を手掛けています。各々に得意領域があり、わたしはフロントエンドの改善やコードレビューなども行っています。 そのコードレビューで、「Vueの watch() を使用せずに computed() でリアクティブに書きたいです」 (Reactで言えば useEffect() を避けたい) と指摘させていただいたときに、理解を深めたいとコメントを頂いたこともあり、フロントエンド開発のコアとも言える、リアクティブ (Reactive) な状態管理の話をまとめようと思いま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
