Introduction to ConditionerJS at Kabisa

An introduction to ConditionerJS and the problems it tries to tackle, a presentation given at a Fronteers meetup hosted by Kabisa.

Transcript

1. Conditioner Frizz Free, Environment-aware, JavaScript Modules
2. Freelance Front-end Developer Rik Schennink @rikschennink
3. origins Another day another framework
4. Writing maintainable JavaScript for big web platforms is though. Now do it for the multi device web, k-thanks-bye!
5. no pixels lot’s of pixels
6. no pixels lot’s of pixels
7. touch mouse pen gesture remote voice keyboard virtual gyro no pixels lot’s of pixels
8. It’s all a bit overwhelming.
9. Let’s take a step back.
10. Can’t make decisions based on device type. “Phone or tablet… fablet… god dammit.”
11. Features are way more interesting. “User moves his mouse… and the viewport is pretty wide…”
12. HTML works everywhere.
13. Features are stable while context is volatile.
14. Screensize “User resizes the window or rotates his device…” Input type “User interacts with touch then moves to his mouse…” Cookie support “User decides to not allow cookies…”
15. These changes give us valuable info about the context the user is in.
16. “We want to measure the users’ context and respond appropriately.”
17. touch mouse pen gesture remote voice keyboard virtual gyro CURRENT TIME LIGHT LEVEL SESSION LENGTH NAVIGATION HISTORY SCROLL POSITION proximity LOCATION VELOCITY WEATHER CONNECTION STABILITY HISTORICAL BEHAVIOR MOTION
18. demo
19. HOW DO I USE IT Programming principles https://www.flickr.com/photos/j_regan/6454408915/in/photostream/
20. game development A quick side track
21. Game development turned out to be more difficult than expected.
22. How to make these systems play nice together… Particle engine Achievement dispenser Game loop Render engine Collision detection
23. How to make these systems play nice together… I had no clue…
24. My developer skills were lacking, I needed engineering skills.
28. The most important take-away…
29. Single Responsibility Principle
30. Using this principle while examining the responsive web I found why my code spiralled out of control each time.
31. A typical piece of code was… Feature testing Waiting for DOMContentLoaded Monitoring events Expecting other code
32. So in the next project, I separated all code using modules based on AMD.
33. I needed to build an entity that could load those modules without taking too much responsibility.
34. That entity is Conditioner. And it’s build on the following 3 principles.
35. 1. module isolation A strict separation between modules
36. Modules are separated for maintainability.
37. You bind modules in the HTML itself.
38. index.html <a href="http://maps.google.com/?ll=51.741,3.822"
 data-module="ui/GoogleMap">
 View on GoogleMaps
 </a>
39. ui/GoogleMap.js define(function(){
 
 var exports = function GoogleMap(element) {
 
 };
 
 return exports;
 
 });
40. document.querySelectorAll("[data-module]");
41. Conditioner measures context and will load all relevant modules without knowing anything about them. Just that they’re bound with data-module.
42. 2. module decoupling Making modules environment agnostic
43. Setup context parameters using the “data-conditions” attribute.
44. index.html <a href="http://maps.google.com/?ll=51.741,3.822"
 data-module="ui/GoogleMap"
 data-conditions="media:{(min-width:40em)}">
 View on GoogleMaps
 </a>
45. A condition consists of a monitor and an expected value for said monitor.
46. media:{(min-width:40em)} <monitor>:{<expected-value>}
47. window element media pointer connection available monitors width, height visible, width, height query, supported near, fine any
48. Build your own custom monitors.
49. monitor/light.js {
 trigger:{
 'devicelight':window
 },
 test:{
 'min-lumen':function(data,event) {
 return data.expected <= event.value;
 }
 }
 }
50. light:{min-lumen:200}
51. Combine monitors in expressions. media:{…} and not (element:{…} or pointer:{…}) Use the was operator to remember state. pointer:{was near}
52. .is('media:{(min-width:40em)}').then(…); .on('media:{(min-width:40em)}',function(){…}); API
53. 3. module reusability Uniform configuration of module properties
54. Configuration is done through so called options.
55. ui/GoogleMap.js define(function(){
 
 var exports = function GoogleMap(element,options) {
 
 }; 
 exports.options = { zoom: 10, type: 'map', key: null }; 
 return exports;
 
 });
56. main.js conditioner.setOptions({ modules:{ 'ui/GoogleMap':{ options:{ key: '123ABC' } } } };
57. index.html <a href="http://maps.google.com/?ll=51.741,3.822"
 data-module="ui/GoogleMap"
 data-conditions="media:{(min-width:350px)}"
 data-options="type:terrain">
 View on GoogleMaps
 </a>
58. Conditioner automatically merges these option objects.
59. { zoom: 10, type: ‘map’, key: null } { key: ’123ABC’ } ‘type:terrain’ module website element
60. { zoom: 10, type: ‘map’, key: null }
61. { zoom: 10, type: ‘map’, key: ’123ABC’ }
62. { zoom: 10, type: ‘terrain’, key: ’123ABC’ }
63. new GoogleMap(element,{ zoom: 10, type: 'terrain', key: '123ABC' });
64. loose ends Pro’s, con’s and future developments
65. Fast development; Separate requests; Save CPU cycles; Pros
66. Separate requests; CPU cycles; It’s a framework; CONS
67. Currently working on various improvements. “Always looking for feedback on the idea and execution.”
68. Mr. Miyagi “Every piece of code should only have one responsibility.”