Skip to content

Latest commit

 

History

History
59 lines (57 loc) · 4.34 KB

doing.org

File metadata and controls

59 lines (57 loc) · 4.34 KB

Feature: client-server browser detection

In order to decide what javascript features we can use, we want to know what is supported by our (prospective) users’ browsers. As developers and user experience persons. “Another factor that makes developing for responsive design hard is the rate with which mobile users update their phones and browsers” http://responsivenews.co.uk/post/18948466399/cutting-the-mustard On the qwan contact form, I got a report from a customer that he could not see the contact form, but I had no way to figure out what he was seeing. Storing

Cutting the mustard test client side in FAY

Inspired by the above and http://gomakethings.com/ditching-jquery-for-vanilla-js/ .*

print presence of elements to consule.

Start with a type to detect presence of various elements, ‘anding’ the ones we are interested in is for later. Baby steps:

document.QuerySelector

window.addEventListener

Array.prototype.forEach

We may not care about this, as Fay takes care of our client side code. On the other hand, I ran across some code that did use javascript arrays.

local storage (just out of curiosity)

classList support

support for touch events?

Think mobile first

Route to Post

Save result in database

Timestamp plus one parameter

all parameters (“list” of supported functions comma separated in a text field, and

a count column for number of supported features

show X out of Y features supported in browser

Save browser type

look in to browser fingerprinting? take browser info from http headers? Hmm. it is more complicated than that. https://github.com/NielsLeenheer/WhichBrowser

Meta: test framework

  • Something simple that can be run in a browser (using wrapped HTML) and through node interpreter
  • Mimic what HUnit provides: A Test data type that can be built from basic assertions, or from a list of tests
  • A Test executor objects that goes through a tree of tests, evaluates each assertions and outputs a TestResult
  • Provide an HTML renderer for TestResult objects

Basic test framework that works using an HTML page

  • implemented poor man’s ready() function that ensures runTestHTML only starts when node is built, uses standard event disregarding compatibility with IE8-
  • this needs to be moved to DOM package…
  • had a hard time debugging my code as nothing appeared, logs where uninformative. Initially thought code was too lazy, but things were caused by the fact DOM was unavailable hence msg could not be displayed, and of course not evaluated

basic test framework that works with node.js

Meta: composable GUI components

  • Having a look at Om which is a Clojurescript wrapper around react
  • React principles:
    • Wrap DOM into custom tree, main method of React instances is render which returns a pseudo-DOM tree to be rendered by React engine. In react, there is a custom language (JSX) for expressing “templates” in a HTML-like form, this is a pre-processor that outputs custom objects
    • Register callbacks invoked using requestAnimationFrame (or setTimeout), each callback corresponding to one “root” component to render
    • When rendering, computes a pseudo-edit distance between current DOM and requested DOM to minimize what’s to be recomputed. Then generates HTML/DOM to inject into the DOM tree representing current state of application
    • Mostly declarative: components are built using React class, implementing lifecycle methods
  • Om adds clojure syntax, wrapping React DOM objects into clojure fns. It also adds cursors which are objects containing the state of the application, mutated using specific functions. Components are functions that creates instances of IRender which are then used to create the actual React object
  • Data-flow always goes in one direction, data coming from user input is handled by event handlers, events are wrapped by React to unify across browsers
  • React is huge as far as JS goes: As of 0.10 react.js is 4258 lines long…