なんでコンポーネントに副作用があんだよ！ 教えはどうなってんだ教えは！
皆さんこんにちは。先日公開した以下の記事は多くの方にご覧いただきありがとうございます。 この記事に対して多く見られた反響のひとつは、コンポーネント内に use(fetchNote(id)) という非同期処理を行うコードが含まれていることに対する違和感です。 function Note({id, shouldIncludeAuthor}) { // ↓↓↓↓↓ const note = use(fetchNote(id)); let byline = null; if (shouldIncludeAuthor) { const author = use(fetchNoteAuthor(note.authorId)); byline = <h2>{author.displayName}</h2>; } return ( <div> <h1>{note.title}</h1> {byline}
データフェッチはuseEffectの出番じゃないなら、結局何を使えばいいんだ
ショートアンサー React 18 からのフックである、useSyncExternalStore を使えばいいようです。 ※ useEffect がまったくだめだというわけではありません。 ※ クライアントサイドレンダリングのみを考えています。サーバーサイドレンダリングを考慮すると違った答えになるかもしれません。 サンプルコード 次のような useData フックを作ってみます。 JSON API の GET レスポンスを返すシンプルなものです。 実験をしやすいように、リクエスト URL を変えるボタンを置いてあります。 import { useEffect, useState } from "react" export function SearchResults() { const [id, setID] = useState(1) const todo = useData(`http
React Queryを使いこなすために試したこと
はじめに タイトルで大きくふろしきを広げてしまいましたが、結論から言うといろいろと試してみた結果、現時点ではまだ着地点を見出せていません。現時点での自分なりの最適解として、useQuery、usePrefetch、useMutationと楽観的更新の実装例についていくつか紹介させていただきます。 モチベーション 現在、Redux Sagaをふんだんに利用したアプリケーションのメンテナンス・機能拡張に携わっているのですが、ページ数やAPIエンドポイントが多数あることからコード量が多く構造も複雑になっており、メンテナンスコストの増大が懸念されるようになってきました。そこで今後のメンテナンス性の向上、また新規に参画するメンバーにも入りやすいようRedux SagaをはがしReact Queryへ少しずつ移行してくための検証を兼ねてReact Queryの使い方を探っています。 React Que
Micro State Management with React Hooks | Web Development | eBook
Savings automatically calculated. No voucher code required
そこのお前！ 余計なuseMemo1個に含まれるオーバーヘッドは余計なdiv 0.57個分だぜ！ - Qiita
※効果には個人差があります。 useMemoのオーバーヘッドについて ReactのuseMemoは、パフォーマンス最適化に使われるAPIです。コンポーネント内で計算やオブジェクトの生成を行う際に、以前の計算結果をキャッシュして使い回すことで再レンダリング時の計算を削減したり、新しいオブジェクトの生成を防ぐことができます。 useMemoに関しては、あくまで最適化のためのものであるから「無駄に使うべきではない」という言説がよく見られます。その理由は、useMemoのコストもゼロではなく、余計な使用はそれだけパフォーマンスの低下に繋がってしまうからです。 しかし、筆者はuseMemoのコストは微々たるものであり、本当に一目見て明らかに無駄でない限りは積極的に使うべきだと思っています。 そこで、筆者はuseMemoのオーバーヘッドがどれくらいかを調べるためのベンチマークを作成しました。この記事で
React の新しい概念「トランジション」で React アプリの応答性を改善する - 30歳からのプログラミング
React v18 には多くの改善や新機能が盛り込まれる予定だが、そのなかでも特に注目を集めると思われるのが、Concurrent Features と呼ばれる一連の機能。 これらの機能を使うことで、コンポーネントのレンダリングについてより柔軟な設定が可能になり、上手く使えばパフォーマンスや UX の向上を実現できる。 この記事では Concurrent Features のひとつであるstartTransitionと、それを使いこなす上で重要な概念である「トランジション」について説明する。 この記事ではコンセプトの説明や具体例の提示のみを行う。詳細を知りたい場合は以下を参照。 一年前の記事であるため古くなっている部分もあるが、根幹は大きく変わっていないと認識している。 なお、上記の記事には「Concurrent Mode」という用語がタイトルに入っているが、これは今後は使われなくなってい
Tailwind CSS v3.0 - Tailwind CSS
Tailwind CSS v3.0 is here — bringing incredible performance gains, huge workflow improvements, and a seriously ridiculous number of new features. Tailwind CSS v3.0 is here — bringing incredible performance gains, huge workflow improvements, and a seriously ridiculous number of new features. For a tour of some of the coolest new features, check out the “What’s new in Tailwind CSS v3.0” video on our
React.VFC を使うべき理由
React.VFC を使った方が良い理由についてまとめてみた。 React.VFC とは Function Componentを定義するための型である React.FC はchildrenが最初から暗黙的に定義されてしまっているため、必要ないのにchildrenを渡してしまってもエラーにならない仕様になっている。これでは暗黙的に許可してしまうため実際に渡っているのか渡っていないのかがわからない。 そこで @types/react v16.9.48 からはReact.VFC が追加されており、こちらではchildrenが含まれない。なので未定義の状態でchildrenを渡した場合、errorを出してくれる。 https://github.com/DefinitelyTyped/DefinitelyTyped/pull/46643 サンプルコード export type Props = { t
ReactのあたらしいRouterライブラリ「React Location」を試してみた | DevelopersIO
React LocationはRouteのルールを記載にオブジェクトの形で記載します。React Routerと同様にライブラリを追加することでJSXスタイルでの記載も可能ですが公式ドキュメントではオブジェクト形式での記載となっているためオブジェクト形式での記載がオススメです。（ちなみにReact Routerもオブジェクト形式での記載をサポートしています） React Location Elements To Routes Router.tsxファイルとしてオブジェクト形式でパスを記載し、App.tsxに組み込んでいきます。elementとして読み込むコンポーネントは別途作成します。 src/Router.tsx import { Route, ReactLocation } from '@tanstack/react-location'; import { Home } from '.
Layout patterns | Patterns | web.dev
Stay organized with collections Save and categorize content based on your preferences. Layout patterns built using modern CSS APIs to help you build common interfaces such as cards, dynamic grid areas, and full-page layouts. `�[U `��[U We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users. This site is our home for content to
CSSでメディアクエリはもう必要ないかも -メディアクエリなしで実装するテクニックのまとめ
Webサイトやアプリをレスポンシブ化するためにメディアクエリに頼っているのであれば、CSSの機能を見直して、昔ながらのブレークポイントを新しい流動的なアプローチで実装ができないか検討する時期かもしれません。 CSSの実装はデバイスベースからコンテンツベースに移行しているのが現状です。grid, flexbox, vh, vw, calc, clamp, min, maxなど、CSSの機能を使用してレスポンシブ対応にするテクニックを紹介します。 You Probably Don't Need Media Queries Anymore by Kathryn Grayson Nanz 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに 大局的なgridとflexbox 活躍するCSSのプロパティ 完全に機能するCSSの数学関数
プログラムによるレイアウト制御のための CSS Grid を考える
この記事は、既存のCSSのレイアウトの文脈ではなく、「プログラムから制御されるレイアウト」をいかに綺麗に制御・生成するか、です。 複雑なSPAや何らかのオーサリング環境で、主に JavaScript の視点からレイアウトを扱うのに Grid をどう活かしていくか、という話。 grid-template-areas の視覚的な対応 IEがない世界では CSS grid のフル機能を使うことができます。 自分が grid を使う際、今まで grid-template-areas を気に入って使っていました。これは CSS の視覚的な情報が最終的な表示と一致する、という理由からです。 例えば、 svelte で書いた grid-template-areas を使ったレイアウト設定のコードはこんな感じになります。。 <div class="grid"> <div style="grid-area:
このCSSなら簡単！フォームのチェックボックス・ラジオボタンとテキストをベースラインに揃えて配置
フォームの実装で面倒なのがフォーム要素とテキストを揃える、特にチェックボックス・ラジオボタンとテキストをベースラインに揃えることです。 flexboxでalign-item: baseline;を使用すると、チェックボックス・ラジオボタンとテキストを揃えるのは簡単に実装できます。複数行のテキストにも対応します。 <div class="flex-demo --start checkbox-input"> <label for="demo"><b>flex-start</b> 複数行の長いテキストでも大丈夫</label> <input type="checkbox" id="demo"> </div> <div class="flex-demo --center checkbox-input"> <label for="demo2"><b>center</b> 複数行の長いテキストでも大丈
空のdiv要素についての哲学的な話 - lacolaco
命令は、無条件に従うべき当為として命令する「定言命法」と、条件付きで「こういうときはこうすべき」と命令する「仮言命法」に分けられる
中身のない空の div 要素や空の span 要素は HTML 仕様として妥当なのか？ - dskd
公開日2021-09-06タグHTMLレイアウトや装飾目的で、中身のない div 要素や span 要素、いわゆる「空 div」「空 span」を作ることはままある。しかしそれは仕様として妥当なのだろうか？ 目次 レイアウト目的の空 div の例 装飾目的の空 span の例 HTML にレイアウト目的や装飾目的のための要素はない div と span の仕様から探る フローコンテンツ フレージングコンテンツ コンテンツモデルにおける text "nothing" コンテンツモデル ol, ul, menu 要素 パルパブルコンテンツ カスタムエレメント トランスペアレント ここまでのあらすじ 僕の結論 レイアウト目的の空 div の例 下記は使う場所に応じて幅や高さを任意に設定できる例だ。.Spacer が空 div になっている。 <div class="Hero">...</div>
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
