#React やってて、props のバケツリレーを何か嫌がる人たまにいるんだけど、自分は props のバケツリレーそのものをそんなに悪いと思ったことがない。 「バケツリレーがつらい」ように見えるコンポーネントの大半はそもそも props の設計がおかしい場合が多く、本当の問題はそっちにあると思っている。 たとえば、次のようなバケツリレーはつらいかもしれない。ここでいう Body はサイドバーとしてフォロワーの一覧を表示し、メインコンテンツとしてフィード一覧を表示するみたいなものを想像して欲しい。フォロワー一覧の中で使う props とフィード一覧で使う props を混ぜて1つの親に渡している状況だ。
There are many articles written about React performance optimizations. In general, if some state update is slow, you need to: Verify you’re running a production build. (Development builds are intentionally slower, in extreme cases even by an order of magnitude.) Verify that you didn’t put the state higher in the tree than necessary. (For example, putting input state in a centralized store might no
Reactには、パフォーマンス最適化のためのAPIがいくつかあります。具体的にはReact.memo、useMemo、そしてuseCallbackです。 React.memoで囲まれた関数コンポーネントは、propsが以前と変わっていない場合に再レンダリングが抑制されます。 また、useMemoやuseCallbackは、関数コンポーネント内での値の再計算を抑制する効果を持ちます。 これらは最適化のためのツールなので、「過度な最適化」を避けるように啓蒙する言説がよく見られます。 すなわち、ちゃんと本当に最適化のために必要なところにだけこれらを使おうということです。 特に、React.memoはpropsが以前と変わっているかどうかを判定するためのオーバーヘッドがあるし、useMemoやuseCallbackもフック呼び出しのオーバーヘッドがあります。 意味がないところでReact.memo
(❤️ ブログ記事を翻訳してくれた日本のチーム、Kotaro、Keiya、Marinaに感謝します。) React Hook Formもそろそろ2年目を迎えようとしています。プロジェクト自体は、初日と同じように今でも活発に活動しています。この数年の間に、バージョン7の作成やデザインに繋がる多くの学びや経験がありました。私はここで、次のメジャーバージョンでの改善点とその理由をいくつか紹介します。フォームを構築するという点で、React開発者がより楽に開発できるようにする私たちの使命に変わりはありません。 V7 visions:  📖 (DX)厳密に型付けされたフォーム 🏋🏻♀️ シンプルさと一貫性 🏎 パフォーマンス 💁♂️ パッケージサイズの削減 このビジョンを説明するために、APIの変更点を見ていきましょう。 </> register 主な変更点の一つは register
近年のフロントエンド開発にはコンポーネントという概念が付いて回ります。React・Vue・AngularといったViewライブラリでは、コンポーネントを定義してそれを組み合わせてアプリを作ります。また、いわゆるWeb Componentsとして知られる仕様群により、ライブラリに依存せずに“コンポーネント”を作ることもできるようになってきています。 コンポーネントは、何らかの機能（あるいは責務）を持った部品です。また、コンポーネントによっては再利用される（アプリ内の複数の箇所から利用される）ことを意図しているものや、そもそもライブラリとして配布されているようなものもあります。アプリの機能の一部分を抜き出したものという見方をすれば、コンポーネントというのは関数にとても類似した概念であることが分かります。 コンポーネント設計によって、言い換えればアプリがどのような機能を持ったコンポーネントたちに
こんにちは。フィナンシャル開発センターの鈴木です。LINE証券のフロントエンドを担当しています。この記事は【LINE証券 FrontEnd】シリーズの4番目の記事です。 最近のWeb Vitalsの隆盛を受けて、LINE証券のフロントエンドでもパフォーマンスの改善に取り組み始めました。およそ2週間ほど改善に取り組んだ結果として、開発環境での計測ではLighthouseのperformanceスコアが従来より30点ほど上昇しました。 パフォーマンス改善のためにさまざまな施策を行いましたが、この記事ではその中でも興味深かったものとして、requestIdleCallbackを活用してLazy Loadingされるコンポーネントの読み込みを遅延し、その結果初期レンダリングにかかる時間を約14%削減できた事例をご紹介します。 環境 以前の記事でご紹介したとおり、LINE証券のフロントエンドはTyp
qrcode.reactは、その名の通りQRコードを生成してくれるReactコンポーネントだ。 github.com ファイル構成はsrc/index.jsでゴリゴリ計算というか文字列を算出し、コンポーネントを返す構成だった。 テストがなかったので、テストを追加したかったのだが、何に対してテストを追加すればよいのかわからず、しばらく放置していた。 convertStr関数やgeneratePath関数の入力と出力に対する単体テストを追加しようと思ったけれど、あまり恩恵はないように思えた。 qrcode.react/index.js at 6aeb42abc26ffecc868b630b6ad8f507d2125813 · zpao/qrcode.react · GitHub qrcode.react/index.js at 6aeb42abc26ffecc868b630b6ad8f507d
こんにちは。最近は仕事で React を書き始めました。数年前に React を触った時は class component をせっせと書いた覚えがあるのですが、最近は functional component と react hooks を組み合わせて書くこともできるようです。react hooks の概要は公式ドキュメント等を読んでもらうことにして、本記事では、自作のカスタムフックで stateful なコンポーネントを整理する一例を紹介し、それによって享受できるメリットを少し深掘りしたいと思います。 整理する前のコード まずは僕が最初にお試しで書いた TypeScript のコードをお見せします。インターネットに転がっている例をつぎはぎして、見よう見まねで書いた投稿フォームです。コード中の useQuery は、apollo client のフックで、与えられた GraphQL クエリ
先日、React Server Componentsについてまとめる機会がありました。 この記事では、React Server Componentsの概要と、デモを触る中で感じたことについてご紹介します。 React Server Componentsとは React Server Componentsは、Reactコンポーネントをサーバーサイドでレンダーする新しい技術です。 一部のコンポーネントをサーバーサイドでレンダーしてしまうことで、アプリケーションのパフォーマンスを上げることを目的とします。 図は、デモの画面のうち、サーバーでレンダーされる部分を青で、クライアントでレンダーされる部分を赤で示したものです。 ページ全体をサーバーでレンダーするのではなく、一部のコンポーネントはクライアントにレンダーさせていることがわかります。 また、React Server ComponentsはCo
This domain is registered at NameSilo. If you are the owner, start administering it at NameSilo.com. If this is not your domain, find similar names that work for you. This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it
This domain is registered at NameSilo. If you are the owner, start administering it at NameSilo.com. If this is not your domain, find similar names that work for you. This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it
使用している React のバージョンは16.8.4。 レンダー後の処理を指定するための仕組み React Hooks の一つであるuseEffectは、レンダー後に実行したい処理を React に伝えるための仕組み。 useEffect(fn)と記述すると、DOMの更新が終わったあとにfnを実行する。 useEffectはレンダー後に必ず実行される。最初にレンダーした際もそうだし、propsやstateに変更があってレンダーし直した際もそう。そこに区別はない。 以下の例では、このコンポーネントが表示された際にeffect!というログが流れる。 そしてボタンを押下した際にも、その都度effect!というログが流れる。 import React, {useState, useEffect} from 'react'; const App = () => { const [state, set
This blog site has been archived. Go to react.dev/blog to see the recent posts. 2020 has been a long year. As it comes to an end we wanted to share a special Holiday Update on our research into zero-bundle-size React Server Components. To introduce React Server Components, we have prepared a talk and a demo. If you want, you can check them out during the holidays, or later when work picks back up
[RFC] React 18 and types-only breaking changes · Issue #46691 · DefinitelyTyped/DefinitelyTyped [@types/react] add VoidFunctionComponent type which does not accept "children" by awmottaz · Pull Request #46643 · DefinitelyTyped/DefinitelyTyped https://react-typescript-cheatsheet.netlify.app/docs/basic/getting-started/function_components/ 簡単に言うと React.FCのpropsの型定義には暗黙的にchildrenが含まれてしまう childrenが必要ない
ng-japan で発表した Server Side Rendering の資料です。
React.Suspenseの力を最大化する、GraphQLの次世代ディレクティブ @ defer と @ stream ReactのSuspense、素敵ですよね。 この記事ではGraphQLのワーキンググループで仕様の策定が進んでいる@deferと@streamについて解説します。@deferと@streamはReactのSuspenseの力を引き出す、注目すべきディレクティブです。 なお、これらのディレクティブの仕様はワーキンググループでほぼ合意できていますが確定した仕様ではないことに注意してください。 Suspenseは最高だ！ あるブログの記事の一覧ページを例に見てみます。 記事一覧ページを表示するためのGraphQLのクエリは次のようになります。1 query { articles(page: 1) { # 記事一覧（1ページ目） title # タイトル body # 文章（
Next.js の初期の特徴的な API である getInitialProps() だが、これを非 Next.js 環境のコンポーネントに自作して生やすと SPA の設計として治安が良くなるのでおすすめという話をする。 以下の話は、もちろん新規開発で Next が選択できるシチュエーションでは採用する必要はない（というか、自前でやる分普通にコストが高いのでやめたほうが良いと思う）。 が、react-router や universal-router でできたアプリケーションを改善したい、あるいは年季の入ったコードベースを SPA 化したいという状況では比較的役に立つと思う（あとこの形にしておくと Next.js に移行しやすくなりそう）。
next.js の SSG は糞 ぼくは next.js 結構好きでこのブログとかも next.js で作ってるんですが、最近の next.js の方向性にはちょっと危うさを感じています。 next.js は最近は静的サイトジェネレータ+αみたいな感じになっていて、サーバーサイドジェネレーションなる機能のサポートが入っています。 でもこれどう考えてもゴミでしょ。いや記事が 500 件とかならいいけど、 50 万件あったらデプロイのたびにどんだけ時間かかる？という話で。それからサイトが生きているかぎり結局のところ記事はどんどん増えていく以上トップページは動的生成にならざるを得ないわけで。あまりはっきりと言われているわけではありませんが、 next.js を開発している人たちは WordPress のテーマを PHP で書きたくない人というペルソナをもとに開発していて、その人たちは CDN を
I started this decade as a first-year college student fresh out of high school. I was 17, didn’t have a job, didn’t have any industry connections, and really didn’t know shit. And now you’re reading my blog! I would have been proud. I’ve told bits and pieces of my story on different podcasts. Now feels like an appropriate time to write down the parts that were most memorable to me. Every person’s
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
