From Ember to Elm

An introduction to Elm for Ember developers.

Transcript

1. from : a friendly introduction to Elm → for Ember developers elm by Kirill Korolyov
2. we ❤* * MOST OF THE TIME. CONDITIONS APPLY.
3. Why? better API for the web batteries included ember-cli component model scales rich addon ecosystem well-maintained just works! easy to start
4. BUT
5. Javascript npm null == this keyword not everything is an expression weak typing “JavaScript fatigue” slow installation times undefined is not a function (deprecated) thousands of tiny packages dynamic typing writing your own framework inheritance monkey patching jQuery runtime exceptions Native APIs maintainability TC39 backwards compatible forever undefined stringly typed makes me cry at night
6. Enter Elm
7. What is Elm? A delightful language for reliable webapps
8. What is Elm? typed, pure functional programming language for the browser (might sounds boring, but please stick around, there’ll be rainbows)
9. But I can have types and functional in JavaScript!
10. What is functional programming?
11. map/filter/reduce No.
12. High-order functions No.
13. Immutability Getting warmer. But still not the core idea.
14. A functional programming language is one that supports and encourages programming without side-effects. — Kris Jenkins http://blog.jenkster.com/2015/12/what-is-functional-programming.html
15. What is an (non-side) effect? • rendering and changing HTML • making a HTTP request • getting current time • generating random number • listening to DOM events • more generally, any interaction with the outside world — including the web browser
16. What is a side effect? An effect which is not an explicit input or output to a function Also, mutable state
17. A pure function always produces the same value when given the same arguments.
 It can’t “do” anything.
19. Pure functional programming means programming without side-effects Implies immutability
20. Why? • optimization • memoization • referential transparency • rendering performance • testing • easy understand and predict the behavior • time-traveling debugger • separation of concerns (what vs how)
21. How? We’ll see some examples later on
22. While JavaScript allows you to be functional, it will never save you from side-effects.
23. Installing Elm $ npm install -g elm
24. Creating a new project $ mkdir elm-tutorial $ cd elm-tutorial $ elm package install
27. It took
 3 seconds to install
30. Dude, where are my files?
31. Elm doesn’t care about where you place your code. There’s no magic either. Regardless, it enables you to write
 well-architected code.
32. Elm is not so opinionated • no defined file layout • no Ember Data alternative (but you might not need it) • no out-of-the-box routing solution (Elmers don’t even call it “routing”) (compared to Ember)
33. Elm is not a framework
34. Elm is opinionated about • transpiler • type system • semantic versioning • core library • DOM rendering elm-lang/core elm-lang/html (compared to pure JavaScript) the Elm architecture
35. The Elm Architecture “it will happen to you whether you know about it or not” — Evan Czaplicki, “An Introduction to Elm”
36. Ember Elm component function service function helper function model data template function
37. Application Model View Update Data Function Function
38. View a way to render your state as HTML Ember analogy: template, helper and parts of component
39. Let’s create Hello World
40. Start with one file Main.elm
41. Main.elm
42. How would it look like in JS? Elm Javascript
44. A very simple Ember component
45. Spot any problems? • is it clear what inputs to the template or component are? • what happens if user is undefined, has no name or is a number?
46. Same in Elm
48. So what about invalid arguments?
50. Elm has type inference
51. Elm has no runtime exceptions Also no null or undefined
52. If it compiles, it works Makes refactoring incredibly safe and straightforward
53. What does implicit type signature here look like?
54. Model the state of your app Ember analogy: internal state of store, all services and components
 not to be confused with Ember Data models

55. this is also state
56. this is also state
57. Anything that can change is part of state
58. Anything derived is normally not state
59. You are in control of the entire state tree
60. View is simply a function of the model
61. Update a way to update your state Ember analogy: calling this.set from an action handler
62. Show me some code.
63. Parrot
64. components/name-input/component.js components/name-input/template.hbs
65. Model
66. What’s Happening?!?! (in your app)
67. Message describes something that can happened Ember analogy: events and actions
68. Message
69. View
70. Update
71. How can I change state if everything is immutable?
72. Main function
73. All together now
75. A chat
76. A silent chat
77. A silent chat
78. A list of users
80. Expanding the model
81. Expanding the model
82. Expanding the model
83. Expanding message type
84. Same in Java
85. List of users in Ember components/user-list/component.js components/user-list/template.hbs
86. …now in Elm Ember
87. Not clear. Let’s refactor
88. Or like this
89. Or in JS
90. components/name-list-with-input/template.hbs
91. components/name-list-with-input/component.js
92. Expanding the view function in Elm
93. Expanding the update function in Elm
94. Expanding the update function in Elm
95. Hey Elm! Are we forgetting something?
98. Refactoring & Scaling
99. It’s OK to have very large Msg and Model
100. Recap Elm makes you write well-architected and maintainable code The type system and the compiler do amazing job at error detection Programming without mutations and side-effects Explicit state management In fact, we have only scratched the surface here!
101. The End Dremora Thank you!