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
710
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Reactハンズオンラーニングを読んだので感想を語る
あけの
September 08, 2022
More Decks by あけの
See All by あけの
TypeScriptのエラー処理(ES2022の新機能を添えて)
akeno
3
3.1k
oapi-codegenを使ってみた
akeno
0
2.9k
こんな案件は嫌だ(※個人の感想です)
akeno
1
240
SQLアンチパターンから学ぶテーブル設計
akeno
0
770
VSCode Remote Containers のすすめ
akeno
0
360
設計とテストの必要性について考える
akeno
1
320
Other Decks in Programming
See All in Programming
act2-costs.pdf
sumedhbala
0
120
AWS CDK を「作」ってみた 〜フルスクラッチで見えた CDK の裏側〜 / aws-cdk-from-scratch
gotok365
3
500
継続モナドとリアクティブプログラミング
yukikurage
3
630
Apache Hive: Toward a Cloud Native Lakehouse
okumin
0
160
琵琶湖の水は止められてもNet--HTTPのリトライは止められない / You might be able to stop the water flow of Lake Biwa but you can't stop Net::HTTP retries
luccafort
PRO
0
430
為什麼你並不需要ViewModel / No, you don't need a ViewModel
lovee
0
180
エンジニア向け会社紹介/Findy Company Profile
findyinc
6
360k
これからAgentCoreを触る方へトレンドはGatewayです
har1101
6
500
鹿野さんに聞く!『TypeScriptコードレシピ集』で磨く実践力
tonkotsuboy_com
4
1.1k
【やさしく解説 設計編・中級 #6】良いアーキテクチャとは ~ 一本の登り道の、行き先 ~
panda728
PRO
0
180
共通化で考えるべきは、実装より公開する型だった
codeegg
0
270
生成AI導入の「期待外れ」を乗り越える ー 開発フロー改革が目指す、真の組織変革
starfish719
0
1.8k
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.7k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.7k
Raft: Consensus for Rubyists
vanstee
141
7.6k
Agile that works and the tools we love
rasmusluckow
331
22k
jQuery: Nuts, Bolts and Bling
dougneiner
66
8.5k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.8k
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
65
57k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3.4k
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
280
Visualization
eitanlees
152
17k
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
livdayseo
0
160
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
1
320
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! フックの依存チェーンが出来るのが厄介 これを分かりやすいと捉えるのが難しい 結局カスタムフックをどう作るかにぶつかる - 宣言的な書き方に慣れる - 手続き的なコードを末端に寄せていく
コンテナ・プレゼンテーションパターン 疎結合であること 反省 ハンズオンラーニングなのに手元でコードをまだ動かしていない…