サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
内部的にはGoogle Identity Platform +NextAuth による認証、 マルチロール制御、通知、DTO検証などを組み込み、 App Router特有の問題が浮き彫りになるような構成になっています。 📂 リポジトリ: Systemguide: docs/README.md Frontend playbook: frontend/docs/README.md Checklists: docs/checklists.md App Routerの“自由さ”をどう設計で制御するか 実際に運用して分かった課題は、大きく3つです。 1. 境界のあいまいさ server専用コード（handlerやrepositoryなど）がclientコンポーネント側に漏れる。 2. Server Actionのスパゲッティ化 Actionがランダムなpage.tsxに散らばり、 機能とルー
Reactがこれまでどのように開発されてきたかについての詳細な考察と、コミュニティでよく見られる混乱や懸念事項についての説明 はじめに 今日、Reactとそのエコシステムの状況は複雑で分裂しており、成功、懐疑、そして論争が入り混じっています。 ポジティブな面として、Reactは最も広く利用されているUIフレームワークであり、そのコンセプトはJSエコシステムの他の部分にも影響を与えてきました。Reactチームは数年にわたる開発の末、先日React 19をリリースしました。これは、公式に安定版となったReact Server Componentsのサポート、Promiseを扱うための新しいuseフック、複数の新しいフォーム連携、そして長らく非推奨であった多くの時代遅れな機能の削除を含む、大規模なリリースでした。 しかし、私が観察し、また経験してきたところでは、Reactコミュニティでは、Rea
TOPフォーカスZustand、Jotai、Valtioの作者はなぜReact状態管理OSSを3つ開発したのか【フォーカス】React状態管理ライブラリ開発者 加藤 大志（Daishi Kato） OSS開発者。React状態管理ライブラリ「Zustand」（v3以降）「Jotai」「Valtio」の作者。大手電機メーカーでのリサーチャーを経て、フリーランスエンジニアとして国内外の複数の企業でソフトウェア開発に携わる。OSS活動では主にJavaScriptやReactに関連したライブラリ開発に携わり、現在は特にReactフレームワーク「Waku」に注力。GitHub X:@dai_shi Zustand Jotai ValtioReact開発においてSPA（Single Page Application）を効率的に構築するために、アプリケーション全体の状態をどう管理するか――。すなわ
はじめに 長らくReactを雰囲気で書いてきました。コンポーネントを作り、propsを渡し、状態を管理する基本的な概念は理解していたものの、より体系的なアプローチや設計パターンについては深く考えずにコードを書いていました。しかし、より大規模で保守性の高いアプリケーションを構築するにつれ、単なる「動くコード」を超えた、堅牢な設計原則の必要性を痛感するようになりました。 この記事は、私自身の再学習を共有するものです。 ※2025/04/21時点、私が関わっているプロダクトのCrowd AgentのReactのバージョンは"18.3.1"です。 目次Reactデザインパターンとは HOC (高階コンポーネント) パターン[※React18以降では、カスタムフック推奨] Provider パターン Presentational と Container コンポーネントパターンReact Hook
Reactはシンプルなサイトから複雑なアプリケーションまで、非常に幅広く採用されている人気のフレームワークです。OSS化から10年以上の歴史がありながら、昨今もReact Server Componentsなど革新的なアイディアを我々に提案し続けています。 一方で、React Server Componentsへの批判的意見やBoomer Fetching問題などを見ていると、Reactチームと一部Reactユーザーの間には意見の相違が見て取れます。この意見の相違はそれぞれが置かれた状況の違いから生じるもの、つまり「見てる世界が違う」ことに起因してると筆者は感じています。本稿では「Reactチームの見てる世界」を歴史的経緯を踏まえながら考察し、Reactの根本にある思想やコンセプトに対する読者の理解を深めることを目指します。 要約ReactはMetaの大規模開発を支えるべく開発され、シ
Recoil 終了のお知らせ Recoilが2025年始にarchivedされたようです。 冗長的な書き方をせずにglabal stateを扱えるライブラリだったので、度々使用していましたが、何かしらの影響で開発停止となりました。 This repository has beenarchived by the owner on Jan 2, 2025.It is now read-only. 理由を調べてみた 元Metaのメンテナーの方が、以下のようなポストをしていました。 翻訳すると、 これは言われていることですが、まったく予想通りです。Meta が Douglas Armstrong を解雇した後、私は Recoil の唯一のメンテナーになりました。その後、私も解雇されました。社内の多数のプロジェクトでまだ使用されていますが、誰も責任を引き継ぎたくありませんでした (これはパフォー
はじめに みなさんこんにちは、Watanabe Jin(@Sicut_study)です。Reactが大好きな私にとってReactの歴史が大きく変わる瞬間に出くわしました。 ついにReact 19が安定版としてリリースされたのです。React19になってSSRなどサーバーコンポーネントが完全にサポートされます。 そんな中で真っ先に動いたのがRemixです。Reactでサーバーでの処理ができるとなると「React +React Router」と「React + Remix +React Router」で実現できることの差がなくなりました。 そこでReact RouterとRemixが統合されて新たなフレームワークが生まれます。 それが「React Router v7」なのです！！！React Router v7はいままで通りライブラリとして「ReactRouter」を利用することも
最近React Nativeを使ってアプリを作る機会があり、React Nativeの進化に驚いたのでシェアします。 筆者のReact Native歴 元々はAndroidとiOSでそれぞれネイティブアプリを作っていました。 2017~2019年くらいに仕事と趣味の両方でReact Nativeを使っていました。 2019年くらいからFlutterを使ってアプリ開発をするようになり、それ以降はFlutter or ネイティブ開発のみで、React Nativeは使わなくなりました。 当時(~2019)のReact Nativeの印象 5年以上前なので朧げな部分もあります。 一つのソースコードでAndroidとiOSのアプリがどちらも作れて便利 パフォーマンスはネイティブほどではないが、ほとんどの画面で別に気にならない。アニメーションを大量に入れようとすると明らかにカクツク。 当時はパフォー
はじめに 記事を聞くに至った経緯 プログラミングに触れて初めて自分から勉強しにいったのがReact でした。当時はとりあえず動くものをつくるので精一杯だった為 useEffect をなんとなく使うことはできるようにはなりましたが、ちゃんと理解はしておらず、そのままここまで来てしまいました。仕事で痛い目見る前にちゃんとしておこうと思い、改めて勉強しなおすに至りました。 目的 useEffect をいまだになんとなくで使っているので理解を深めたい useEffect を使いこなしてバグのないコードを書けるようになりたい 分からなかったこと そもそも何をしているのか？ 副作用 ライフサイクル useEffect はいつ実行される？ クリーンアップ dependencies(第二引数)に何を入れればいかわからない eslint-plugin-react-hooksに脳死でしたがっていた これらの
React Aria は Adobe により提供されているReact 用のコンポーネントライブラリであり、アクセシビリティを最優先した設計となっています。本記事では、React Aria により提供されているドラッグアンドドロップ機能を紹介します。 ドラッグアンドドロップは、ユーザーがUI の要素をドラッグして別の場所に移動する操作です。Web アプリケーションにおいて、ドラッグアンドドロップはユーザーが直感的に操作できるため、多くの場面で利用されています。例えばタスク管理アプリケーションにおいて、タスクをドラッグして進行状況を変更したり、ファイル管理アプリケーションにおいてファイルをドラッグしてフォルダを移動する機能などがあります。 従来のドラッグアンドドロップ機能はマウス以外での操作が考慮されていない実装が多く、キーボードやスクリーンリーダーを利用するユーザーにとっては機能を利用す
こんにちは、ダイニーの Feature team でソフトウェアエンジニアをしている @ta21cos です。 最近は新規事業である決済関連の機能の開発をメインに行なっています。 ダイニーにおける Feature team は機能にフォーカスした開発・運用を行っているチームです。最近は複数の事業毎に Unit として分かれて開発を進めています。本日は、普段の開発で実際にあった Pull Request のレビューコメントから得た学びについて紹介します。 Dialog を実装しようReact を使ってある Dialog を作成するため、以下のようなコードを書きました（コードは簡略化しています）。 // useSample ファイル // 内部でロジックと Dialog を同時に定義している hook const Dialog = memo<{ progress: number, ...
App Routerの場合 例えば、以下の構成であれば、「/」にアクセスするとapp/page.jsが表示され、「/products」にアクセスするとapp/products/page.jsが表示されるようになります。 app └── (Auth) --> ルートグループ。URLには影響しないが、関連するページをグループ化する ├── layout.js --> 共通化したいレイアウトを定義する └── signin └── page.js --> /signinにアクセスした際に表示する内容を定義する また、App Routerにおけるファイル規約はこのようになっています。 default.js: デフォルトの画面error.js: 404エラー画面 layout.js: 共通のUIを設定する loading.js: ローディング画面 middleware.js: リクエストが完了する
ReactのuseEffectは、フックの中でも使い方が難しいものの一つです。そこで、この記事では筆者が考えるuseEffectの望ましい使い方を皆さんに伝授します。 基本原則技術やその要素の使い方を考えるにあたって、筆者が好んでいるのは基本原則を置いてそれに基づいて判断することです。ということで、この記事ではまず筆者が考えるReactの基本原則を紹介します。 筆者がもっとも重要視する原則は、ReactはUIライブラリであるということです。つまり、ReactにはUIの管理をさせるべきであって、その他のことはReactの役目ではないということです。Reactが難しいと思う人がいる場合、何でもかんでもReactにやらせようとするから余計に難しくなっているのだと思います。 例えばアプリケーションのロジックの管理やそれに付随するステートの管理はReactの役目ではないので、Reactの外部で処理
最近久しぶりにReact Router を使う機会があった。 SSR不要な要件だったのでNext.jsではなく Vite を選んだら、ルーターが必要となりReact Router を選定した。React Router は Remix との統合もある通り、もはやただのルーターではなく、fetch や form action までもサポートされている。 採用にあたって考えるのはどこまでReact Router の機能を使うかだ。 自分は router が欲しくて入れるので fetcher や action は不要だ。 一方でReact Router を FW と考えると FW の標準に乗るのは自然な発想にも思える。 今回、React Router の機能に寄せて開発してみて、この機能使う・この機能使わないという土地勘ができたのでメモをしておく。 routerルーターライブラリなので
背景Next.js に App Router が導入されてから1年近くが経ちました。しかし、未だに App Router を前提として設計のベストプラクティスが定まっておらず、身近なフロントエンドエンジニアはみな「まだプロダクトに取り入れるには考えることが多いよね」という共通認識のまま止まっているような気がしています。 また、App Router が導入されるまでは、技術選定の無難な選択肢としてNext.js が最有力でした。しかし、現在は App Router の設計のプラクティスが未発達なことや、オーバースペックであるという見方が出てきており、検討しなければならないことが多くなったように感じます。 そうした中で、ではその懸念というのはどのようなものがあり、導入しずらい要因に何があるのか、というところが、今回執筆を行う上での背景になります。 App Router導入で考えないといけな
useEffectはReactの中でも扱いの難しいフックとして知られています。Reactで開発を行う中でuseEffectを検討するタイミングや適切な使い方について悩んだ経験のある方も多いのではないでしょうか。本記事では、useEffectの目的を把握し、どのような場合にuseEffectの使用を検討すべきかについて考えていきたいと思います。 コンポーネントの純粋性と副作用 まずuseEffectについて考える前に、コンポーネントの純粋性について理解する必要があります。Reactにおいて純粋性は重要な概念の1つです。 前提として、Reactではすべてのコンポーネントが純関数であることを仮定しています。Reactは、あなたが書くすべてのコンポーネントが純関数であると仮定しています。 参照：https://ja.react.dev/learn/keeping-components-pure
はじめに こんにちは。サーバーサイドエンジニアの mokuo です。 最近、ミニマムなReact アプリを実装する機会がありました。 社内のメンバーにアドバイスをもらいながら、今（2024年前半）React アプリをミニマムに作るならこんな感じかな、という構成になった気がするので、ご紹介したいと思います。 実例の1つとして参考にしていただけますと、幸いです。 はじめに本文 📝 機能要件 ⚒️ 採用したツール (npm モジュール) 📁 ディレクトリ構成 👨💻 プロトタイピングの実施 🍩 おまけ コンポーネント設計についてフロントエンドに DDD のエッセンスを取り入れてみたい おわりに本文 📝 機能要件 社内の限られた CS メンバーのみが利用する、管理画面を開発しました。 バックエンドはGolang で実装されるAPI サーバーで、認証機能以外だと、2つの機能
この記事は株式会社ゆめみ Advent Calendar2023 | Qiita の2023-12-21 投稿分です。React のコンポーネント間の結合度、特に「〇〇的結合」といった段階を使った評価について、私なりにその考え方・用語をReact に翻訳してみました。React のコンポーネント同士の結合のしかたの制約を考慮に入れてみると、結合度の各レベルにはこのような短い説明を付けられます。 レベル１: 内容結合 ―― 高水準言語なので起こらない レベル２: 共通結合 ―― グローバル or Context. 賢く使おう レベル３: 外部結合 ――React では原則として禁止 レベル４: 制御結合 (ここからがマシな結合) ―― 論理的凝集におちいるので注意 レベル５: スタンプ結合 ―― 無駄なデータにだけは注意 レベル６: データ結合 ―― 理想的 番外編: 名前や型付
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
