Introduction to ConditionerJS at Kabisa

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.

F3c93cbf28ac15eab9655246e5667965?s=128

Rik Schennink

April 08, 2015
Tweet

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.

  25. None
  26. None
  27. None
  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.”