Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Mistakes I made writing React/Redux applications

Mistakes I made writing React/Redux applications

43aed98b8c4c276ddbb2c8e2fb8fb464?s=128

Alexandre Santos

November 16, 2018
Tweet

Transcript

  1. Mistakes I made writing React / Redux applications require(‘lx’) Alexandre

    Santos
  2. Who am I? Software developer @ KI Labs ampsantos0 asantos00

    Alexandre Santos, 24yo 2
  3. What is this talk about? 3

  4. Before we start React? Redux? 4

  5. 5

  6. 6

  7. #1 - Trying to componentize too soon 7

  8. #1 - Trying to componentize too soon 8

  9. #1 - Trying to componentize too soon 9

  10. #1 - Trying to componentize too soon 10

  11. #Lesson 1 - Do not predict the future, simplify 11

  12. #1 - Trying to componentize too soon 12

  13. ❌ Trying to componentize too soon ✅ Create components as

    needed, simplify 13
  14. 14 Just one more drink

  15. #2 - Add “one more prop” 15

  16. #2 - Add “one more prop” 16

  17. #2 - Add “one more prop” 17

  18. #Lesson 2 - Compose components, the open-closed principle 18

  19. #2 - Add “one more prop” 19

  20. #2 - Add “one more prop” 20

  21. #2 - Add “one more prop” 21

  22. ❌ Add “one more prop” ✅ Add props that have

    meaning for the button ✅ Extend without having to change the component ✅ Avoid prop hell ✅ Use children prop ✅ Use render props 22
  23. #3.1 - Bad redux store planning 23

  24. #Lesson 3.1 - Think state as a database 24

  25. #3.1 - Bad redux store planning 25

  26. ❌ Redundancy ❌ Store lists in arrays ❌ Disregard “indexes”

    ✅ Store in objects for easy access (by id p.ex) ✅ Have references to avoid duplicates ✅ Think store state as a database 26
  27. 27

  28. #3.2 - Couple data with UI 28

  29. #3.2 - Couple data with UI 29

  30. #Lesson 3.2 - Keep UI and Data decoupled, avoid nesting

    30
  31. #3.2 - Couple data with UI 31

  32. #3.2 - Couple data with UI 32

  33. ❌ Mix UI state with Data ❌ Have various levels

    of nesting ❌ Couple store with component structure ✅ Store UI state and data in different indexes ✅ Have an almost flat store, with references ✅ Store mimics the domain model 33
  34. 34

  35. #4 - Access the store directly from components 35

  36. #4 - Access the store directly from components 36

  37. #4 - Access the store directly from components 37

  38. #4 - Access the store directly from components 38

  39. #Lesson 4 - Use selectors 39

  40. #4 - Access the store directly from components 40

  41. 41

  42. ❌ Couple components with store structure ❌ Do unnecessary logic

    to get same values ✅ Use selectors as “getters” for store values ✅ Have memoized selectors that don’t recalculate if arguments don’t change 42
  43. #5 - Duplicate reducer logic 43

  44. #5 - Duplicate reducer logic 44

  45. #5 - Duplicate reducer logic 45

  46. #Lesson 5 - Use higher order reducers 46

  47. #5 - Duplicate reducer logic 47

  48. #5 - Duplicate reducer logic 48

  49. ❌ Do not reuse reducer code ❌ Lack coherence in

    action names ✅ Use Higher order reducers ✅ Reuse logic ✅ Enforce namespacing/coherence 49
  50. #6, #7, #8... - Think redux as a library instead

    of a pattern 50
  51. 1. Try to componentize too soon 2. Add “one more

    prop” 3. Bad redux store planning 3.1. Redundancy/Lack of index 3.2. Couple store with UI 4. Components directly accessing the store 5. Duplicate reducer logic 6. Think redux as a library ❌ Mistakes 51
  52. 1. Do not predict the future, extract to reuse 2.

    Compose components, think extensibility 3. Rethink the redux store structure 3.1. Think store as a database 3.2. Keep UI and Data decoupled, avoid nesting 4. Use selectors 5. Use higher order reducers 6. Think redux as a pattern ✅ Lessons learned 52
  53. Questions? 53

  54. ampsantos0 asantos00 Alexandre Santos Thank you! 54 alexandre.santozz@gmail.com