Building Large, Real-world Ember Apps -- What the guides don't tell you

0
views
In this talk, we’ll go over some tips and best practices for creating and maintaining large-scale Ember apps. Creating your own core library, custom resolver types and other D.R.Y. techniques.

This was the slideshow for my Ember.js South California Meetup talk on July 29th, 2014 @ Pivotshare

Transcript

1. Jay Phelps https://twitter.com/_jayphelps July 29, 2014 Building Large, Real-world Ember Apps What the guides don’t tell you
2. Jay Phelps https://twitter.com/_jayphelps July 29, 2014 Building Large, Real-world Ember Apps What the guides don’t tell you
3. WHO I AM Jay Phelps
4. WHO I AM •Ember.js contributor Jay Phelps
5. WHO I AM •Ember.js contributor •CTO at Pivotshare Jay Phelps
6. WHO I AM •Ember.js contributor •CTO at Pivotshare •Loves code, hates condiments. Jay Phelps
7. WHO I AM •Ember.js contributor •CTO at Pivotshare •Loves code, hates condiments. Jay Phelps twitter: @_jayphelps github: @jayphelps
8. DOES EMBER SCALE?
9. “SCALE” IS A BUZZ WORD
10. BUT THAT’S O.K.
13. SCALE = OPERATING LEVERAGE Relative operating costs go down as overall revenue goes up.
14. WHAT HAS THAT MEANT FOR US?
15. WHAT HAS THAT MEANT FOR US? •Higher initial investment, i.e. learning curve.
16. WHAT HAS THAT MEANT FOR US? •Higher initial investment, i.e. learning curve. •Rapid iteration after.
17. THE FREE STUFF YOU KNOW
18. EMBRACE THE CONVENTIONS
19. EMBRACE THE CONVENTIONS
20. EMBRACE THE CONVENTIONS •Create your own “core” library.
21. EMBRACE THE CONVENTIONS •Create your own “core” library. •Base classes with common functionality
22. EMBRACE THE CONVENTIONS •Create your own “core” library. •Base classes with common functionality •Use a custom Ember.Resolver or extend an existing one
23. EMBRACE THE CONVENTIONS •Create your own “core” library. •Base classes with common functionality •Use a custom Ember.Resolver or extend an existing one •Ember-CLI or Ember App Kit
24. YOUR OWN CORE LIB
25. YOUR OWN CORE LIB •Abstract common functionality
26. YOUR OWN CORE LIB •Abstract common functionality •Routes, Views, Controllers, even Ember.Object itself (if you’re careful)
27. YOUR OWN CORE LIB •Abstract common functionality •Routes, Views, Controllers, even Ember.Object itself (if you’re careful) •Don’t .reopen() Ember built-ins, extend!
28. SIMPLE EXAMPLE Transitioning between sibling routes
29. channel.marketing.seo.reports.conversion -> channel.marketing.seo.reports.sessions
34. OR
36. WHY NOT JUST .REOPEN()?
37. WHY NOT JUST .REOPEN()?
38. WHY NOT JUST .REOPEN()? •Limit your scope
39. WHY NOT JUST .REOPEN()? •Limit your scope •.reopen() affects ALL existing object instances as well
40. WHY NOT JUST .REOPEN()? •Limit your scope •.reopen() affects ALL existing object instances as well
41. WHY NOT JUST .REOPEN()? •Limit your scope •.reopen() affects ALL existing object instances as well
42. WHY NOT JUST .REOPEN()? •Limit your scope •.reopen() affects ALL existing object instances as well
43. WHY NOT JUST .REOPEN()?
44. WHY NOT JUST .REOPEN()?
45. WHY NOT JUST .REOPEN()? •Limits scope
46. WHY NOT JUST .REOPEN()? •Limits scope •.reopen() affects ALL existing object instances as well
47. WHY NOT JUST .REOPEN()? •Limits scope •.reopen() affects ALL existing object instances as well •Allows you to use original, if ever needed
48. WHY NOT JUST .REOPEN()? •Limits scope •.reopen() affects ALL existing object instances as well •Allows you to use original, if ever needed •Future-proof (sorta)
49. WHY NOT JUST .REOPEN()? •Limits scope •.reopen() affects ALL existing object instances as well •Allows you to use original, if ever needed •Future-proof (sorta) •e.g. What if Ember introduces the same method of name?
50. EMBRACE THE CONVENTIONS
51. EMBRACE THE CONVENTIONS
52. EMBRACE THE CONVENTIONS •Create your own “core” library.
53. EMBRACE THE CONVENTIONS •Create your own “core” library. •Base classes with common functionality
54. EMBRACE THE CONVENTIONS •Create your own “core” library. •Base classes with common functionality •Use a custom Ember.Resolver or extend an existing one
55. EMBRACE THE CONVENTIONS •Create your own “core” library. •Base classes with common functionality •Use a custom Ember.Resolver or extend an existing one •Ember-CLI or Ember App Kit
56. CUSTOM RESOLVERS
57. CUSTOM RESOLVERS •https://www.youtube.com/watch?v=OY0PzrltMYc
58. CUSTOM RESOLVERS •https://www.youtube.com/watch?v=OY0PzrltMYc What is a Resolver?? Robert Jackson answers.
61. CUSTOM RESOLVERS
62. CUSTOM RESOLVERS require() is some form of synchronous module lookup
63. WHAT DOES THIS LET US DO?
64. CUSTOM FIRST-CLASS TYPES
65. CUSTOM FIRST-CLASS TYPES Tom Dale’s proposal on “Services”
66. WHAT HE PROPOSED
67. WHAT HE PROPOSED Defining a Service
68. WHAT HE PROPOSED
69. WHAT HE PROPOSED Using a Service
70. MY SOLUTION
71. MY SOLUTION Defining a Service
72. MY SOLUTION
73. MY SOLUTION Using a Service
74. COMPUTED INJECTIONS
75. COMPUTED INJECTIONS •Resolves via type:class-name
76. COMPUTED INJECTIONS •Resolves via type:class-name •Creates an instance of the given class when you .get() it
77. COMPUTED INJECTIONS •Resolves via type:class-name •Creates an instance of the given class when you .get() it •Tied to parent class. i.e. not a singleton.
78. COMPUTED INJECTIONS
79. COMPUTED INJECTIONS Gives you unlimited custom resolver “types”, not just services
80. COMPUTED INJECTIONS Gives you unlimited custom resolver “types”, not just services Available via bower if that’s your thing
81. COMPUTED INJECTIONS Gives you unlimited custom resolver “types”, not just services Available via bower if that’s your thing https://github.com/jayphelps/ember-computed-injection
82. QUESTIONS? https://twitter.com/_jayphelps
83. THANK YOU https://twitter.com/_jayphelps