結局useMemoはいつ使えばいいの？ 僕の決定版 - Qiita
皆さんこんにちは。筆者の以前の記事では、ReactのuseMemoを無駄に使うことによるレンダリング速度のオーバーヘッドがどれくらいかをベンチマークによって示しました。 それによれば、スマートフォンを想定したとしても、useMemoだけで描画に目に見える影響を与える（16msくらいの遅延を発生させる）には万のオーダーのuseMemoが必要なことが分かります。 速度ではなくuseMemoを使うことによるメモリ消費量の増加を気にする声も聞かれましたが、すみませんが筆者はそこまでメモリクリティカルなアプリをReactで書いたことがなく知見に乏しいため、今回はこの記事の対象外となります。 この結果が出たことでuseMemoをいつ使うのかなどという議論には終止符が打たれたかと思いきや、上記の記事の感想などを見ているとまだ喧々囂々です。 そこで、この記事では筆者の考えを皆さんに共有し、いよいよもってこ
React大好き侍が、「もうSolidJSでいいじゃん...//」ってなったワケ。 - Qiita
Reactが好きです。 Reactが好きです。コンポーネントを関数として扱うのが好きです。 SolidJSはReactそっくりの書き心地(DX)を保ちつつ、Reactに足りない要素を兼ね備えた期待の新人です。 コードの比較 React const Counter = () => { const [count, setCount] = useState(0) useEffect(() => { console.log(`Count: ${count}`) }, [count]) return ( <div> <div>{count}</div> <button onClick={() => setCount(prev => prev + 1)}>Add</button> </div> ) } const Counter = () => { const [count, setCount] =
React Query のレンダリング最適化を目指した話 - Techtouch Developers Blog
エンジニアの macchii です。この記事はテックタッチアドベントカレンダー 14 日目の記事です。 テックタッチでは React を利用して WEB フロントエンドを開発しています。あわせて、リモートデータの取得、更新、キャッシングには React Query を導入しています。本記事では、簡単なタスク管理アプリを題材に、「React Query の再レンダリングを最適化するテクニック」紹介します。 ja.reactjs.org react-query.tanstack.com TL;DR はじめに React Query は取得データを厳密に比較（deep compare）する 参照していないプロパティの変更でも再レンダリングが発生する notifyOnChangeProps オプション select オプション まとめ TL;DR React Query は取得データを厳密に比較（
React Hook Form はどのように再レンダリングを最適化しているのか？
【READYFOR×コミューン】業務に活かせるReact LT & 座談会 https://readyfor.connpass.com/event/224586/
Next.jsでSSRを限界まで簡単に実現する
１．getInitialPropsの終焉 1.1. Next.jsではgetInitialPropsのSSRが終わったことにされている Next.jsの9.3以降、getStaticPropsやgetServerSidePropsが登場し、現在ではgetInitialPropsを使ったSSRが終焉を迎えたかのような風潮となっています。しかしgetStaticPropsとgetServerSidePropsは、実際の所で大きな欠点を抱えています。 getStaticPropsはSSG前提で使うなら全く問題ありません。しかし、ある程度の更新頻度をもつシステムやリアルタイムな編集機能と相性が悪いです。ISRで使う場合も有効期限後の一回目で古いデータが表示される仕様があるので、タイミングが悪いと、せっかっく訪れた人に古いデータを渡してしまうことがあります。使いどころによっては強力ですが、用途は限定
stand.fmアプリのパフォーマンス改善話「推測するな、計測せよ」｜Takahiko Wada
(このnoteはstand.fm engineeringマガジンの記事です) stand.fm エンジニアの和田(@takahi5)です。 今回はReact Nativeアプリののパフォーマンス改善について書きたいと思います。主にレンダリング周りの改善です。 アプリを開発していてユーザーや社内のメンバーから「アプリが重い！」と言われたことはないでしょうか？僕はよくあります笑 今回はstand.fmのライブ配信機能で実施したパフォーマンス改善について、ボトルネックの特定からその改善まで、実例に触れながらご紹介したいと思います。 アプリが重い！？ただこの「アプリが重い！」にもいろいろパターンがあります。 - ボタンをタップしたときの反応が遅い - アニメーションがカクカクする - ローディングがなかなか終わらない - 起動に時間がかかるなどなど、一言で「重い」と言っても、詳しく聞いてみると色々
useMemoのコストを心配する前に余計なdivを減らせ！
React では、useMemoやReact.memoなどが最適化の手段として知られています。 これらは最適化であるため、必要が無いのにuseMemoを使うことは無駄な最適化であるとして避けられる傾向にあります。 筆者が簡単なベンチマークを取ってみたところ、あるコンポーネントが一つ余計なuseMemoを持っているよりも、一つ余計な<div>をレンダリングする方が、パフォーマンス（レンダリングにかかる時間）をより悪化させることが分かりました。 したがって、useMemoなどを減らすことに執心する場合は、それと同等以上の熱量で余計な要素を減らすことに執心する必要があります。 ベンチマークはこちらです。 結果には当然ばらつきがありますが、筆者の環境では次のような結果が典型的なものとして現れました（Mac 上の Google Chrome・Firefox・Safari で同じような傾向）。 bas
useCallbackはとにかく使え！ 特にカスタムフックでは - uhyo/blog
Reactには、パフォーマンス最適化のためのAPIがいくつかあります。具体的にはReact.memo、useMemo、そしてuseCallbackです。 React.memoで囲まれた関数コンポーネントは、propsが以前と変わっていない場合に再レンダリングが抑制されます。 また、useMemoやuseCallbackは、関数コンポーネント内での値の再計算を抑制する効果を持ちます。 これらは最適化のためのツールなので、「過度な最適化」を避けるように啓蒙する言説がよく見られます。 すなわち、ちゃんと本当に最適化のために必要なところにだけこれらを使おうということです。 特に、React.memoはpropsが以前と変わっているかどうかを判定するためのオーバーヘッドがあるし、useMemoやuseCallbackもフック呼び出しのオーバーヘッドがあります。 意味がないところでReact.memo
ヌルヌル動くReactコンポーネントの作り方【入門】 - カミナシ エンジニアブログ
こんにちは、カミナシの浦岡です。 最近、弊社のメンバーとしてUIデザイナーが新たに加わり、プロダクトのUI改善を進めています。 以前は、AntDesignなどUIライブラリーのコンポーネントをそのままプロダクトで使用する機会が多かったのですが、UI改善を行う上で、UIライブラリーそのままでは要件を満たすことが困難なケースも出てきました。 その結果、独自のReactコンポーネントを実装する機会が増えているのですが、 この記事では、その独自コンポーネントを「ヌルヌル動く」仕上がりにするために気をつけている点を架空の題材を使って書きます。 題材 今回、「空を舞うカレンダー」（ペルソナ５風!?）のUIがデザイナーから提示されたと仮定して進めます。 極端な題材ですが、UIライブラリのカレンダーをベースには実現できそうにないので、独自コンポーネントとして作りましょう！ 先に、ヌルヌル動かす上で気をつけ
Reactのフォームをコントロールしたときのデメリットを考える
公式では制御されたコンポーネントを推奨し、<input type="text" value={this.state.value} onChange={this.handleChange} /> のように onChange を使って更新、value に state を入れて制御するようにしているのですが、推奨は言いすぎではと思っていることについて書きます。 「公式のここがおかしいのではないか」という問いかけはだいたい自分が間違っているだけという場合がほとんであることは自覚していますので、もし間違っていたら """優しく""" 指摘してくれると嬉しいです。 React は制御されたコンポーネントを推奨している まず制御されたコンポーネントについて、公式の定義をみましょう。 HTML では <input>、<textarea>、そして <select> のようなフォーム要素は通常、自身で状態を保
Reactのレンダリングに関する完全ガイド - Qiita
この記事はComplete Guide to React Rendering Behaviorの翻訳記事になっています。 ご本人(Markさん)にも許可を頂いて翻訳しております。 こちらの記事がReactのレンダリングを理解する上で今までで一番体系的で一番分かりやすかったので、ぜひ紹介したく翻訳させて頂きました。 翻訳ツールにもたくさん助けてもらいながら行い、意訳が出来ていない部分が多々あるかと思いますので修正依頼を出して頂けると幸いです！ Twitterでも、フロントエンドに関する事や、アメリカでのエンジニア経験に関してツイートしているので、よかったらフォローお願いします。 Twitter: @hellokenta_ja 下記から本文です。 Complete Guide to React Rendering Behavior この記事は、Reactレンダリングがどのように振る舞うか、Co
業務で使える簡単なSSR + SPA のテンプレートを公開した - hiroppy's site
久しぶりのブログです。 よく Node.js の人と思われがちですが、普段は Node.js でのバックエンド開発はもちろんですが React や Vue を書いていますので、たまにはフロントエンドネタを投稿しようと思います。 GitHub - hiroppy/ssr-sample: A minimum sample of Server-Side-Rendering, Single-Page-Application and Progressive Web App A minimum sample of Server-Side-Rendering, Single-Page-Application and Progressive Web App - GitHub ... リポジトリにあるコード見たほうが早いと思いますので、ここでは注意点等を列挙していこうかなと思います。 主な技術スタック de
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
React における XSS｜React と Vue に関する XSS アンチパターン
<btn open />