Oleksii Levzhynskyi "Solving behavioral complexity with FRP"
•Télécharger en tant que PPTX, PDF•
0 j'aime•351 vues
At Grammarly, we have tried different approaches to handle behavioral complexity. We made a long journey from callback hell to FRP, and from dynamic to static typing. We will discuss how FRP helped us build stable high-loaded front-end applications with complex async actions for millions of daily users.
Recommandé
Contenu connexe
Similaire à Oleksii Levzhynskyi "Solving behavioral complexity with FRP"
Similaire à Oleksii Levzhynskyi "Solving behavioral complexity with FRP" (20)
Plus de Fwdays
Plus de Fwdays (20)
Dernier
Dernier (20)
Oleksii Levzhynskyi "Solving behavioral complexity with FRP"
- 1. Solving behavioral complexity with FRP Oleksii Levzhynskyi Grammarly
- 2. • Web Editor • Desktop Editor • Web Extension (past) • @grammarly/focal contributor Oleksii Levzhynskyi
- 7. ((([t ]*rn)?[t ]+)?[-!#-'*+/-9=?A-Z^- ~]+(.[-!#-'*+/-9=?A-Z^-~]+)*(([t ]*rn)?[t ]+)?|(([t ]*rn)?[t ]+)?"(((([t ]*rn)?[t ]+)?([]!#-[^-~]|([t -~])))+(([t ]*rn)?[t ]+)?|(([t ]*rn)?[t ]+)?)"(([t ]*rn)?[t ]+)?)@((([t ]*rn)?[t ]+)?[-!#- '*+/-9=?A-Z^-~]+(.[-!#-'*+/-9=?A-Z^- ~]+)*(([t ]*rn)?[t ]+)?|(([t ]*rn)?[t ]+)?[((([t ]*rn)?[t ]+)?[!-Z^-~])*(([t ]*rn)?[t ]+)?](([t ]*rn)?[t ]+)?) RFC 5322
- 8. 99%
- 10. Where it comes from
- 11. Where it comes from • => Historically - “front-end is simple”
- 12. Where it comes from • Historically - “front-end is simple” • => Incomplete requirements
- 13. Where it comes from • Historically - “front-end is simple” • Incomplete requirements • => 3rd parties that force different approaches
- 14. Where it comes from • Historically - “front-end is simple” • Incomplete requirements • 3rd parties that force different approaches • => “Small” changes on the middle of development
- 15. Where it comes from • Historically - “front-end is simple” • Incomplete requirements • 3rd parties that force different approaches • “Small” changes on the middle of development • => It just complex
- 16. Where it comes from • Historically - “front-end is simple” • Incomplete requirements • 3rd parties that force different approaches • “Small” changes on the middle of development • It just complex • => …
- 17. How to detect complexity
- 18. How to detect complexity • => Challenge requirements
- 19. How to detect complexity • Challenge requirements • => Talk with colleagues
- 20. How to detect complexity • Challenge requirements • Talk with colleagues • => Architecture design sessions
- 21. How to detect complexity • Challenge requirements • Talk with colleagues • Architecture design sessions • => Prototyping
- 22. What we are looking for?
- 28. Async
- 29. How to deal • => Callbacks
- 30. How to deal • => Callback hell
- 31. How to deal • Callback hell • => Promise
- 32. How to deal • Callback hell • Promise • => Event emitter
- 33. How to deal • Callback hell • Promise • Event emitter • => Flux/Redux
- 34. RP “Manages asynchronous data flows between sources of data and components that need to react to that data.”
- 35. RP
- 36. RP + FP Deal with async data streams in a functional way: • => pure function
- 37. RP + FP Deal with async data streams in a functional way: • pure function • => immutable data
- 38. RP + FP Deal with async data streams in a functional way: • pure function • immutable data • => composability
- 39. RP + FP Deal with async data streams in a functional way: • pure function • immutable data • composability +
- 40. FRP “It’s a different way of thinking: the program is expressed as a reaction to its inputs, or as a flow of data.” Stephen Blackheath, Anthony Jones. “Functional Reactive Programming.”
- 41. 1. Events
- 42. 2. Behaviors
- 43. 3. Composition and Transformation
- 44. Chapter #2 Real life example
- 45. Cards List
- 48. Todo • => Cards list • Active card • Animate active card • Animate cards positions • Optimization
- 54. Card #3
- 55. Card #3
- 57. Too wordy…
- 59. F.div = div + observable props
- 60. Atom = Behavior
- 61. Atom = Behavior
- 65. ViewModel
- 66. Card #3
- 68. Cards List • [Done] Cards list • => Active card • Animate active card • Animate cards positions • Optimization
- 70. undefined?
- 71. Idiomatic handling for empty values
- 72. Idiomatic handling for empty values
- 77. Cards List • [Done] Cards list • [Done] Active card • => Animate active card • Animate cards positions • Optimization
- 80. Animate it
- 85. Cards List • [Done] Cards list • [Done] Active card • [Done] Animate active card • => Animate cards positions • Optimization
- 87. position: absolute top: <N>px transform: translateY(<N>px) transition-property: transform
- 92. Composition
- 94. Cards List • [Done] Cards list • [Done] Active card • [Done] Animate active card • [Done] Animate cards positions • => Optimization
- 95. Interfaces
- 97. Interfaces
- 101. Cards List • [Done] Cards list • [Done] Active card • [Done] Animate active card • [Done] Animate cards positions • [Done] Optimization
- 102. Tips
- 103. #1 The complexity - is ok
- 104. #2 Think about complexity in advance
- 105. #3 Expect async
- 106. #4 Try FRP to solve it
- 107. #4 Try FRP to solve it
- 108. Further reading • Reactive manifesto - https://www.reactivemanifesto.org • The complexity trap - https://danielwestheide.com/blog/2018/12/07/the-complexity- trap.html • A quick introduction into FRP - https://medium.freecodecamp.org/functional- reactive-programming-frp-imperative-vs-declarative-vs-reactive-style-84878272c77f • Functional Reactive Programming, Stephen Blackheath and Anthony Jones • Professor frisby's mostly adequate guide to functional programming • https://github.com/gcanti/fp-ts
- 109. The End
Notes de l'éditeur
- Поведенческая сложность возникает в момент взаимодействия модулей, но не когда вы читаете код, а когда они начинают посылать друг другу сообщения в рантайме.