Slide 1

Slide 1 text

Conditioner Frizz Free, Environment-aware, JavaScript Modules

Slide 2

Slide 2 text

Freelance Front-end Developer Rik Schennink @rikschennink

Slide 3

Slide 3 text

origins Another day another framework

Slide 4

Slide 4 text

Writing maintainable JavaScript for big web platforms is though. Now do it for the multi device web, k-thanks-bye!

Slide 5

Slide 5 text

no pixels lot’s of pixels

Slide 6

Slide 6 text

no pixels lot’s of pixels

Slide 7

Slide 7 text

touch mouse pen gesture remote voice keyboard virtual gyro no pixels lot’s of pixels

Slide 8

Slide 8 text

It’s all a bit overwhelming.

Slide 9

Slide 9 text

Let’s take a step back.

Slide 10

Slide 10 text

Can’t make decisions based on device type. “Phone or tablet… fablet… god dammit.”

Slide 11

Slide 11 text

Features are way more interesting. “User moves his mouse… and the viewport is pretty wide…”

Slide 12

Slide 12 text

HTML works everywhere.

Slide 13

Slide 13 text

Features are stable while context is volatile.

Slide 14

Slide 14 text

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…”

Slide 15

Slide 15 text

These changes give us valuable info about the context the user is in.

Slide 16

Slide 16 text

“We want to measure the users’ context and respond appropriately.”

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

demo

Slide 19

Slide 19 text

HOW DO I USE IT Programming principles https://www.flickr.com/photos/j_regan/6454408915/in/photostream/

Slide 20

Slide 20 text

game development A quick side track

Slide 21

Slide 21 text

Game development turned out to be more difficult than expected.

Slide 22

Slide 22 text

How to make these systems play nice together… Particle engine Achievement dispenser Game loop Render engine Collision detection

Slide 23

Slide 23 text

How to make these systems play nice together… I had no clue…

Slide 24

Slide 24 text

My developer skills were lacking, I needed engineering skills.

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

The most important take-away…

Slide 29

Slide 29 text

Single Responsibility Principle

Slide 30

Slide 30 text

Using this principle while examining the responsive web I found why my code spiralled out of control each time.

Slide 31

Slide 31 text

A typical piece of code was… Feature testing Waiting for DOMContentLoaded Monitoring events Expecting other code

Slide 32

Slide 32 text

So in the next project, I separated all code using modules based on AMD.

Slide 33

Slide 33 text

I needed to build an entity that could load those modules without taking too much responsibility.

Slide 34

Slide 34 text

That entity is Conditioner. And it’s build on the following 3 principles.

Slide 35

Slide 35 text

1. module isolation A strict separation between modules

Slide 36

Slide 36 text

Modules are separated for maintainability.

Slide 37

Slide 37 text

You bind modules in the HTML itself.

Slide 38

Slide 38 text

Slide 39

Slide 39 text

ui/GoogleMap.js define(function(){
 
 var exports = function GoogleMap(element) {
 
 };
 
 return exports;
 
 });

Slide 40

Slide 40 text

document.querySelectorAll("[data-module]");

Slide 41

Slide 41 text

Conditioner measures context and will load all relevant modules without knowing anything about them. Just that they’re bound with data-module.

Slide 42

Slide 42 text

2. module decoupling Making modules environment agnostic

Slide 43

Slide 43 text

Setup context parameters using the “data-conditions” attribute.

Slide 44

Slide 44 text

Slide 45

Slide 45 text

A condition consists of a monitor and an expected value for said monitor.

Slide 46

Slide 46 text

media:{(min-width:40em)} :{}

Slide 47

Slide 47 text

window element media pointer connection available monitors width, height visible, width, height query, supported near, fine any

Slide 48

Slide 48 text

Build your own custom monitors.

Slide 49

Slide 49 text

monitor/light.js {
 trigger:{
 'devicelight':window
 },
 test:{
 'min-lumen':function(data,event) {
 return data.expected <= event.value;
 }
 }
 }

Slide 50

Slide 50 text

light:{min-lumen:200}

Slide 51

Slide 51 text

Combine monitors in expressions. media:{…} and not (element:{…} or pointer:{…}) Use the was operator to remember state. pointer:{was near}

Slide 52

Slide 52 text

.is('media:{(min-width:40em)}').then(…); .on('media:{(min-width:40em)}',function(){…}); API

Slide 53

Slide 53 text

3. module reusability Uniform configuration of module properties

Slide 54

Slide 54 text

Configuration is done through so called options.

Slide 55

Slide 55 text

ui/GoogleMap.js define(function(){
 
 var exports = function GoogleMap(element,options) {
 
 }; 
 exports.options = { zoom: 10, type: 'map', key: null }; 
 return exports;
 
 });

Slide 56

Slide 56 text

main.js conditioner.setOptions({ modules:{ 'ui/GoogleMap':{ options:{ key: '123ABC' } } } };

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Conditioner automatically merges these option objects.

Slide 59

Slide 59 text

{ zoom: 10, type: ‘map’, key: null } { key: ’123ABC’ } ‘type:terrain’ module website element

Slide 60

Slide 60 text

{ zoom: 10, type: ‘map’, key: null }

Slide 61

Slide 61 text

{ zoom: 10, type: ‘map’, key: ’123ABC’ }

Slide 62

Slide 62 text

{ zoom: 10, type: ‘terrain’, key: ’123ABC’ }

Slide 63

Slide 63 text

new GoogleMap(element,{ zoom: 10, type: 'terrain', key: '123ABC' });

Slide 64

Slide 64 text

loose ends Pro’s, con’s and future developments

Slide 65

Slide 65 text

Fast development; Separate requests; Save CPU cycles; Pros

Slide 66

Slide 66 text

Separate requests; CPU cycles; It’s a framework; CONS

Slide 67

Slide 67 text

Currently working on various improvements. “Always looking for feedback on the idea and execution.”

Slide 68

Slide 68 text

Mr. Miyagi “Every piece of code should only have one responsibility.”