Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Reactハンズオンラーニングを読んだので感想を語る
Search
あけの
September 08, 2022
Programming
1
630
Reactハンズオンラーニングを読んだので感想を語る
あけの
September 08, 2022
Tweet
Share
More Decks by あけの
See All by あけの
TypeScriptのエラー処理(ES2022の新機能を添えて)
akeno
3
2.8k
oapi-codegenを使ってみた
akeno
0
2.6k
こんな案件は嫌だ(※個人の感想です)
akeno
1
200
SQLアンチパターンから学ぶテーブル設計
akeno
0
580
VSCode Remote Containers のすすめ
akeno
0
280
設計とテストの必要性について考える
akeno
1
280
Other Decks in Programming
See All in Programming
Constant integer division faster than compiler-generated code
herumi
2
670
一人でAIプロダクトを作るための工夫 〜技術選定・開発プロセス編〜 / I want AI to work harder
rkaga
12
2.7k
Dart 参戦!!静的型付き言語界の隠れた実力者
kno3a87
0
200
兎に角、コードレビュー
mitohato14
0
140
0から始めるモジュラーモノリス-クリーンなモノリスを目指して
sushi0120
1
310
サイトを作ったらNFCタグキーホルダーを爆速で作れ!
yuukis
0
390
【第4回】関東Kaggler会「Kaggleは執筆に役立つ」
mipypf
0
630
Microsoft Orleans, Daprのアクターモデルを使い効率的に開発、デプロイを行うためのSekibanの試行錯誤 / Sekiban: Exploring Efficient Development and Deployment with Microsoft Orleans and Dapr Actor Models
tomohisa
0
150
Nuances on Kubernetes - RubyConf Taiwan 2025
envek
0
180
「リーダーは意思決定する人」って本当?~ 学びを現場で活かす、リーダー4ヶ月目の試行錯誤 ~
marina1017
0
230
Amazon Q CLI開発で学んだAIコーディングツールの使い方
licux
3
190
#QiitaBash TDDで(自分の)開発がどう変わったか
ryosukedtomita
1
370
Featured
See All Featured
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Producing Creativity
orderedlist
PRO
347
40k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.6k
Agile that works and the tools we love
rasmusluckow
329
21k
Embracing the Ebb and Flow
colly
86
4.8k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
890
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
470
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
Transcript
@akeno_0810 2022.09.08 Reactハンズオンラーニング を読んだので感想を語る フロントエンドLT会 - vol.8 #frontendlt
自己紹介 About me あけの (@akeno_0810) Webエンジニア歴2年くらい API/コード設計, チーム開発の効率化, 要件定義 Amplify使ったことないので気になる…
触っている技術 最近興味のある分野
概要 About this talk X React(Next.js)歴10ヶ月くらd X 体系的な知識を仕入れない状態でやってき$ X 一通り読んで気になった部分を話す(積読だった)
X 関数型プログラミン X フッ X パフォーマン X データ取t X Suspense https://www.oreilly.co.jp/books/9784873119380/ Alex Banks、Eve Porcello 著、宮崎 空 訳 Reactハンズオンラーニング 第2版 オライリー・ジャパン発行 ISBN: 978-4-87311-938-0
関数型プログラミング
関数型プログラミング JavaScriptにおける関数型プログラミングの説明が盛り込まれている 命令型との対比でこれから目指すコードの形が表されている ここを理解することがReactの設計の理解に繋がっている 宣言的に書けるか否かがReactらしいコードかどうか https://github.com/oreilly-japan/learning-react-2e-ja/tree/master/chapter-03/3.3/3.3.7
フック
フック ステートを管理して、値をバケツリレーで各コンポーネントに配るのが基本 ステートの管理に使えるフックなるものがある https://github.com/oreilly-japan/learning-react-2e-ja/tree/master/chapter-06/6.1/6.1.1 ステートの変更が再描画をトリガーするという認識は持った - useState - useReducer -
useContext Formのcontrolled/uncontrolled 前者はReactでステート管理出来る分多少重い 後者はRefを用いてDOMを参照する必要がある https://github.com/oreilly-japan/learning-react-2e-ja/tree/master/chapter-06/6.3/6.3.1
フック カスタムフックの設計 https://github.com/oreilly-japan/learning-react-2e-ja/tree/master/chapter-06/6.3/6.3.3 どんどん宣言的になっていくので、そちらを向いて作るのが良さそう 関心の分離を進めている フックの種類 useLayoutEffect...? → render後paint前に呼ばれる(useEffectとは違いレンダリングをブロックする) useEffect
→ 描画の副作用という認識を持つ https://github.com/oreilly-japan/learning-react-2e-ja/tree/master/chapter-07/7.1/7.1.1 render内ではUI構築に関する処理のみが書かれているべき console.logをuseEffect内で書くという発想はなかった →ログを非同期的に出力するカスタムフックになるのか…?
フック 依存配列の同一性について https://github.com/oreilly-japan/learning-react-2e-ja/tree/master/chapter-07/7.1/7.1.2 Reactで用意されているフックは参照を比較するが、深い比較をするライブラリもある… 参照を比較するのでスプレッド演算子が多用される傾向にある useMemoとuseCallbackの使い方 依存しているものが変わらない限り同一のものとして扱いたい →変更されると副作用や再描画が起こるため useReducerでのさらなる抽象化 https://github.com/oreilly-japan/learning-react-2e-ja/tree/master/chapter-07/7.3/7.3.1
パフォーマンス
パフォーマンス React.memo 使ってない… 複雑さを受け入れてでもパフォーマンスを求める場面が来たら使うという認識 理解せずに使うと意図せぬ挙動が起こりやすく見える とりあえず囲っておくのもありに見える predicateを使うより親でuseMemoやuseCallbackを使うパターンを取っている →linterもあるし楽 問題のあるところを計測して修正するのが良くて、 最初からパフォーマンスを過度に気をつけて作る必要はなさそう
→ある程度はReactがよしなにやってくれる
データ取得
データ取得 localStorage + FetchAPI + useEffectでの取得をしている https://github.com/oreilly-japan/learning-react-2e-ja/tree/master/chapter-08/8.3 データの管理が複雑なのでデータ取得ライブラリの有用性がわかる UIの構築に必要な戻り値を持つフックの提供があると楽(data,error,loading,etc...) 末端のコンポーネントでのAPI呼び出し
https://github.com/oreilly-japan/learning-react-2e-ja/tree/master/chapter-08/8.5/8.5.2 親コンポーネントでのデータ取得から分配するパターンを取ることが多いので 表現の違いが見える unmountされた際の検出とリクエストのキャンセル https://github.com/oreilly-japan/learning-react-2e-ja/tree/master/chapter-08/8.5/8.5.3 →データ取得を自前で実装することの面倒さを感じる
Suspense
Suspense ErrorBoundaryの関数コンポーネント or フックが欲しい https://github.com/oreilly-japan/learning-react-2e-ja/tree/master/chapter-09/9.u e React.lazyを使ったコンポーネントの遅延読み込V e Promiseを返す非同期処理 データ取得ライブラリと対応している
https://github.com/oreilly-japan/learning-react-2e-ja/tree/master/chapter-09/9.3/9.3.3 loading → Suspense.Fallback error → ErrorBoundary.Fallback Promise(非同期処理)の状態に合わせてどうするかを明確に書ける 異常系の処理を正常系の処理をしているコンポーネントの外に追い出せるのが良い
まとめ
まとめ 本を眺めた結果、Reactは - カスタムフックをどう設計するか - 1つのフックで多くのことをせずに複数のフックに分割する - 既存のライブラリがどういうフックを提供しているかから学ぶ - TypeScript力が試される
- State・Promiseをどう管理するか - Server/Global/Localの切り分けと再描画の管理 - 今のところ前2つはライブラリ依存なので、 LocalState以外を意識することがない に尽きる。(現在の自分の見える範囲) 書く時もこの辺で迷ってることが多く…
https://www.oreilly.co.jp/books/9784873119380/ Thank you! フックの依存チェーンが出来るのが厄介 これを分かりやすいと捉えるのが難しい 結局カスタムフックをどう作るかにぶつかる - 宣言的な書き方に慣れる - 手続き的なコードを末端に寄せていく
コンテナ・プレゼンテーションパターン 疎結合であること 反省 ハンズオンラーニングなのに手元でコードをまだ動かしていない…