React のルール – React
様々な概念を表現する方法がプログラミング言語によってそれぞれ異なるように、React にも、理解しやすい方法でパターンを表現し高品質なアプリケーションを産み出すための慣用的な記法、ないしルールが存在します。 このセクションでは、自然な React コードを書くために従うべきルールを説明します。自然な React コードを書くことで、安全で整理されており、組み合わせ可能なアプリケーションを作成することができます。以下に挙げる特性により、アプリは変更に対して頑健になり、他の開発者やライブラリやツールと連携しやすくなります。 以下のルールは React のルールとして知られています。これらを守っていないならアプリにバグがある可能性が高い、という意味で、これらは単なるガイドラインではなくルールです。またこれらを守らない場合、あなたのコードは不自然で、理解や推測が難しいものになるでしょう。 Reac
React Server Components と GraphQL のアナロジー
Next.js の App Router が安定版となり、React Server Components (以下 RSC) を実際に試す環境が整ってきた。 実際、今年はやれどこそこのプロダクトが Next.js を採用しただのやっぱり捨てだのといった話題が尽きなかったように思う。 かくいう自分自身も、今年は App Router の案件に取り組んで RSC と格闘する日々を送っていた。 その過程で、こんなようなことを考えるようになったので、今回はこの辺りの話を書き残しておこうと思う（何回か X に同じ旨の POST は上げていたけど、一回もちゃんとまとめてなかったので）。 RSC がない頃の、別の言い方をすると getServerSideProps を使っていた頃の、Next.js におけるアプリケーションの設計は、トラディショナルな MVC にかなり近しい。 ここでいう MVC は、Sp
GraphQL実践ノウハウv2
GraphQL実践ノウハウ https://speakerdeck.com/sonatard/graphql-knowhow 宣言的UIの状態管理とアーキテクチャSwiftUIとGraphQLによる実践 https://speakerdeck.com/sonatard/swiftui-graphql GraphQLの誤解 https://speakerdeck.com/sonatard/rethinking-graphql
Remix の SPA モード
Remix の SPA モード 2024.01.14 Remix は React のフルスタックフレームワークで、Web 標準に基づいた API で構築されていることが特徴です。Node.js のようなサーバーサイドの JavaScript 環境で動作することを前提としています。しかし、現実の世界ではサーバーを用意せずに、静的なファイルをホスティングするだけの環境で Web アプリケーションを構築することが有効な場合も多くあります。このような需要を満たすために、Remix v2.5.0 から実験的に SPA モードが導入されました。 Remix は React のフルスタックフレームワークで、Web 標準に基づいて構築されていることが特徴です。例えばデータのミューテーションはクライアントからサーバーの API をコールするのではなく、HTML のフォームを使って行うといます。また Resp
いまNext.jsで新規サービスを立ち上げるときの観点（Router・CSS・認証・監視など/2023年末）
免責事項 社内向けに展開するように雑にまとめました Next.jsの知見が深くない人がリードしてPoCを立ち上げなきゃいけなくなったが、社内的にはNext.jsを推奨しているみたいな場面を想定しています なので自信ないところも多いですが割と断言するように心がけて書いています PoCの立ち上げ想定なので、jest/Storybookなど内部品質面についてあまり深く書くことを避けています ほぼ自分の知識だけで書いており私見も多いですし、そもそも自分自身がトップクラスの知識や視座を有しているわけでもないので、まずは以下の話を理解はした上で、踏襲するかどうかは別途他記事やGitHub、公式ドキュメントなどを漁って判断することを推奨 App RouterかPages Routerか 2023年末現在まだApp Routerは技術記事が足りてきている印象ではないため、社内でノウハウを積極的に貯めていく
一言で理解するReact Server Components
この記事はReact公式の内容を翻訳・紹介するものではありません。筆者の解釈や理解を伝えるものであり、Reactの公式見解と一致しているとは限りません。あらかじめご了承ください。 皆さんこんにちは。最近Next.js 13.4がリリースされ、App Routerがstable扱いになりました。App RouterはReact Server Component (RSC) をふんだんに用いて構築されています。 React本体でServer Componentがずっとalpha版なのにNext.jsでbetaとかstableとか言ってるのは何で？ という問題も、React Canaryのアナウンスにより無事に解消されました。 React Canaryってなに？ 先日React公式ブログでアナウンスされた、新しいリリースチャネルです。 筆者の理解による概要をお伝えすると、Canary版のReac
How React 18 Improves Application Performance – Vercel
How React 18 Improves Application PerformanceLearn how concurrent features like Transitions, Suspense, and React Server Components improve application performance. React 18 has introduced concurrent features that fundamentally change the way React applications can be rendered. We'll explore how these latest features impact and improve your application's performance. First, let's take a small step
なぜReactは標準でComponentをmemo化しないのか？
はじめに 普段はスタートアップでBtoB SaaSの開発をしているtaroと申します。 今回は、Reactのmemo化について考えている中で抱いた 「なんでReactは標準でComponentをmemo化していないんだろう？」 という疑問を解消するために、色々と調べたり考えたりした内容をまとめました！ 途中でrenderのタイミングや、memo化で再renderが抑えられる理由などの前提知識の復習も含めていて、memo化について詳しくない方もmemo化の勉強にもなると思うので、ぜひぜひ読んでみてくださいー！ なぜこんな疑問を抱いたのか？ まずはそもそも僕がタイトルにあるような疑問を抱いた背景です。 疑問を抱くまでの思考プロセスはこんな感じです。 「再renderが余分に走ってて画面が重いから最適化したいなー」 →「React.memo()を使ってComponentをmemo化しよう！」 →
React Application Architecture for Production〜これ一冊で全てが網羅〜
はじめに この記事は、Alan Alickovicさんの著書「React Application Architecture for Production」をまとめたものになります。Alanさんと言えばZennで最も人気のある記事「bulletproof-react」の作者であり、彼のprojectから学ぶことはとても多い印象です。 今回紹介する本は2023年1月に公開されたため、bulletproof-react以後のReactアプリケーションにおけるベストプラクティスの宝庫となっています。また、本で扱われているアプリケーションのProjectがGitHubで公開されていることから、Projectを眺めるだけでも勉強になる点があるかと思います。 想定読者 Reactのアーキテクチャを模索している方 テスト手法やCI/CDなどのアプリケーション設計に関心がある方 使用される技術と本の構成 言
The interactive way to master modern React – react.gg
Chapters: Why?, Thinking in React, Imperative vs. Declarative, Pure Functions What you’ll learn Optimized for aha! We’re obsessed with helping you reach your aha! moments. Our text sections help you master the “why” behind React concepts and include fun, interactive visuals you can play with. Give it a try.
図で分かるReact18のしくみ
これは何? この記事はReact18がどのように動いているのかをまとめた記事です。なるべくコードの記載はせず、図を使用して読みやすさを重視しています。また、これからReactの内部のコードを読む予定の方のために、各セクションの終わりにアコーディオン形式でGitHubのリンクを貼っています。 ※ この記事はnote株式会社 Advent Calendar 2022 の17日目の記事です。 対象読者 Reactの内部コードを読む気は無いが、裏で何をしているのか把握しておきたい方 これからReactの内部コードを読もうと思っている方 暇な方 Fiberについて まず最初に、Reactのドキュメントを漁っていると度々出現する「Fiber」についてお伝えします。 そもそもFiberとは何か 一部例外はありますが、1個のFiberは1個のコンポーネント（<MyComponent>や<div>など）管理
React脳によるUIライブラリ書きやすさランキング - Qiita
前回のおさらい 前回の記事では、Reactに有利なベンチマークでUIライブラリに競ってもらいました。 こういうベンチマークに対しては、「実務では〜」みたいな反応が一定数出てくるのが自然の摂理です。 書きやすさランキング そこで、シリーズのまとめとして、より実務に近い指標として「書きやすさ」で競ってもらおうと思います。ただし、今回は筆者の独断と偏見によるランキングとなります。せっかく6つのライブラリで同じアプリケーションを書いたので、感想を記事にして残しておきたいという意図です。筆者と同じくReact脳の方にとっては参考になるかもしれません。 なお、前の記事を読んだ方はお分かりの通り、今回書いたアプリケーションはコンポーネントが何個かのものであり、React以外の知識は公式ドキュメントを一通り読んだ程度です。したがって、今回のランキングはコンポーネントの書きやすさに着目しています。大規模開発
React、過剰に複雑な代物。 - Qiita
はいさい！ちゅらデータぬオースティンやいびーん！ 今回の記事は筆者に珍しく、技術紹介ではなく、僕の個人的な意見を書きます。あくまでも、自説です。 React自体は画期的で、プログラミング界に貢献したプロジェクトだと思っていますし、完全に否定したいわけではありません。 Reactに対する違和感＝芽生えては大きく育った種 筆者はReactがとても好きでした。JavaScriptが好きになったきっかけもReactでした。何から何までもReactで書き直して、Custom Hooksを作って、refを子部品に渡したり、バリバリ満喫していました。 Vueも仕事の関係で習得せざるを得なくなったのですが、Vueは最高に大嫌いでした。これならReactで書き直してやるぅ！と思ったりも。 Reactについて社内でも導入を推進したり、React入門の勉強会を開いたりもしています。 しかし、そんな筆者は、最近に
Reactを使うのかVueを使うのかについて個人的なモチベーションを整理したかった
本記事はあくまで執筆時点(2022/3/27)での一意見でありますので、今後時間や技術的な変化により参考にならない部分も出てくるかもしれません。 Reactはいいぞ、Vueはいいぞと様々な情報が世の中には溢れているものの、「こういう場合には」という前提条件にあまり言及されていない情報が多いような気がしたので自分なりの視点で考えてみたいと思いました。 また、SvelteやAngular等他のフレームワークもありますが、そちらは個人的にはよくわからないので、あくまでReactとVueについてだけ言及していきます。 私のフロントエンド経験と気持ちの変化 2018年くらいにReactを勉強し始める。 → Reactって難しい…。 2019年くらいにVueを学び始める。 → Vueって簡単！Reactよりわかりやすくてええやん！ 2020年くらいにNuxtの案件に参画する。 → Webフロントエンド
React SPA の技術選定で考えたこと（atama plus のケーススタディ）
atama plus の osuzu です。 atama plus では、これから段階的に Web ベースプロダクトのフロントエンド開発で React を用いて SPA(Single Page Application) へリプレイスしていきます。 参考: 技術課題のないプロダクトなんてものはない！Django→React リプレイスの意思決定に至る atama plus 流の軌跡 この記事では SPA の技術選定にあたって考えたことを共有します。 プロダクトについて 技術選定はプロダクトの置かれた状況によって意思決定が変わると考えているので、リプレイスするプロダクトについて補足します。 atama plus は塾などで利用可能な学習アプリ「atama＋」を提供していますが、一連のプロダクトの中に塾本部の方が管理のために用いる業務アプリがあります。 今回リプレイスするのはこちらの業務アプリで
React ステート管理 比較考察 - uhyo/blog
こんにちは。Reactの話題の中でもかなりの部分を占めるのがステート管理、さらに言えば各種のステート管理ライブラリです。今さらながら、Reactにおけるステート管理の手法やいくつかのステート管理ライブラリを比較考察して記事にまとめました。 useState + バケツリレーReactにおける基本的なステート管理はuseStateです。ひとつのコンポーネント内で完結するようなステートならばuseStateは非常に適しており、他の選択肢はほぼ無いと言っても構わないでしょう。 ステートをアプリケーションの広範囲で使いたい場合が問題です。次の画像に例示されるように、分岐したコンポーネントツリーの末端のコンポーネント（使用者）で同じステートを参照したい場合を考えます。 useStateと組み合わせる場合、もっとも原始的な方法はpropsのバケツリレーによるものです。propsは親コンポーネントから子
Hooks時代のReactライフサイクル完全理解への道
はじめに これはクラスコンポーネントのライフサイクルを理解した上で、それに対応するように関数コンポーネントのライフサイクルを理解しようという試みです。 厳密にはReactのライフサイクルはクラスコンポーネントと関数コンポーネントそれぞれで違う概念を持っているようで、それぞれのライフサイクルに紐付けて考えるという行為自体がナンセンスな可能性がありますが、理解の手助けになれば幸いです。 そのため、なるべくわかりやすくするために、厳密でない言い方をすることがあります。ご了承ください。 もし明らかにまずい言い回し、もしくは間違って認識しているものがある場合はコメントにて教えていただけると嬉しいです。 モチベーション 僕はReactの経験がクラスコンポーネントはちょっとだけ書いたことがあるくらいで、ほぼ関数コンポーネント×hooksから入ったようなもなのでいまいちライフサイクルが理解できていない。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
我々向けの Algebraic Effects 入門
Horizon UI: Free React Admin Template for Trendy Dashboards
GitHub - rakkasjs/rakkasjs: Bleeding-edge React framework powered by Vite
