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
Anti Hook
Search
Mark24
March 25, 2020
Programming
0
64
Anti Hook
You may not need Hook
Mark24
March 25, 2020
Tweet
Share
More Decks by Mark24
See All by Mark24
DSL分享
mark24code
0
110
Rails初探
mark24code
0
38
Git恢复Force Push内容
mark24code
0
55
Other Decks in Programming
See All in Programming
Rollupのビルド時間高速化によるプレビュー表示速度改善とバンドラとASTを駆使したプロダクト開発の難しさ
plaidtech
PRO
1
180
RuboCop: Modularity and AST Insights
koic
2
1.4k
Kamal 2 – Get Out of the Cloud
aleksandrov
1
190
複雑なフォームの jotai 設計 / Designing jotai(state) for Complex Forms #layerx_frontend
izumin5210
4
1.1k
Cursor/Devin全社導入の理想と現実
saitoryc
15
9.9k
MCP調べてみました! / Exploring MCP
uhzz
2
2.3k
Fiber Scheduler vs. General-Purpose Parallel Client
hayaokimura
1
110
サービスクラスのありがたみを発見したときの思い出 #phpcon_odawara
77web
4
680
エンジニアが挑む、限界までの越境
nealle
1
240
タイムゾーンの奥地は思ったよりも闇深いかもしれない
suguruooki
1
690
生成AIを使ったQAアプリケーションの作成 - ハンズオン補足資料
oracle4engineer
PRO
3
240
Road to RubyKaigi: Making Tinny Chiptunes with Ruby
makicamel
4
420
Featured
See All Featured
How to train your dragon (web standard)
notwaldorf
90
6k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.3k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.6k
Automating Front-end Workflow
addyosmani
1369
200k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
135
33k
The Pragmatic Product Professional
lauravandoore
33
6.5k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
GraphQLとの向き合い方2022年版
quramy
46
14k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
104
19k
Transcript
你可能不需要Hook @Mark 2020.03.25
Hook 是什么?
https://zh-hans.reactjs.org/docs/hooks-reference.html
None
useState模型 • 官⽅⽤法: https://codesandbox.io/s/react-hooks- demo-1-7lw3p • 简单实现:https://codesandbox.io/s/react-hooks- demo-2-4c92p
None
Flow&内部
None
实现 • 内部链表(理解成列表) ——> 单独储存 • 按顺序读取值,按顺序执⾏ hook (不断地rerender,状态 机)
• 触发更新,和 setState⼀样最后都进⼊ Fiber更新队列
优点 • 跨⽣命周期复⽤代码 • 你可以⾃定义Hook
本质:复⽤代码的尝试 PS:以函数为载体的复⽤
理论上
None
实际上
None
问题0:设计
违反单⼀,KISS原则
None
如果需要你学习很久,那其实 是很是失败的设计。 每个⼈理解的不⼀样。
问题1:可视化阅读
1.Class的⽣命周期,字⾯量划分被打 破。视觉阅读结束。 你需要去看每个函数式组件。 2.他并没有明显区分。
问题2:⼼智负担
1.Hook⾃⼰⽐较难理解 2.useEffect的官⽅介绍就要 70min
1.以前的组件⼼智模型⼀致 现在你需要知道Hook做了什么 你必须熟悉每⼀个Hook。 2.他⽤了什么state,还是context,他⽤了 effect还是什么 3.还有他⾃⼰写的Hook——毕竟这是跨⽣命周 期⾥⾯的复⽤。
问题3:滥⽤?闭包
1.你的代码会收获⼀⼤堆罗列在⼀起 的函 数。 2.看起来像极了C语⾔ 3.OO本身就是为了简化问题,这次反向倒⻋ 4.闭包是复杂的,潜在的内存泄漏
问题4:开发体验差
1.闭包,意味着你可能出现内存泄漏⽽ 不⾃制。轻轻松松写出有问题的代码。 2.⽆限循环之殇:写错了就要重启浏览 器。体验极差
问题5:代码真的少 了?
1.每⼀步都要追踪依赖,优化性 能,真的很麻烦 2.碎⽚化的useState未必真的好
你的开悟瞬间
⼀苇渡江 开悟时刻 技术的平衡游戏 平衡是编程⾥⾯的艺术
Hook也许不是为你准 备的
可能适合组件库 • 纯粹,⼀致性的组件。可以极⼤地发挥其复⽤性。 • 因为纯粹所以写不复杂。每个组件是健壮⽽⾼效的。
也许不适合业务
1.⾸先他不纯粹 2.易变化 3.琐碎且容⻓的业务逻辑 4.相似⼜不相关——并不能很好被复⽤ 5.可读性是业务代码中最重要的
理性拥抱新技术 新技术!==好技术 好技术===经得起时间考验的技术
参考资料 • 《useEffect 完整指南》https://overreacted.io/zh-hans/a- complete-guide-to-useeffect/ • https://github.com/brickspert/blog/issues/26 • https://github.com/donavon/hook-flow