DOM Templating and Interpolation

WIP…

Prior art

<rant>The future is so not evenly distributed

Tons of technologies (still, always) floating around for solving this banal (bikeshedding?) issue. Nu, evolution (>1,000 revisions!?). But what irks me is the inconceivable variance in… let’s call it “maturity”? And don’t get me started on their adoption distribution/demographics.

Nevertheless, after wading through NPM (where any common search produces infinite results — is this a thing already?), I’m still uncomfortable with the state of the art — which seems to be Transparency, or Pure, or Rule? — and considering forking/writing my own (aka yet another)!

(Contemplating: in a distant future, will they be as horrified, with things I now consider “neat”, as I am with five year old abominations, like, say, JsRender? ;o)

</rant>

Client side is different

“Isomorphic” JavaScript is a load of hooey. Yeah it’s the same rotten language (uh, actually, CoffeeScript on SS) — so what? Utterly different tasks.

Server side templating I’ve “solved” already, elsewhere: HTML templating: CoffeeCup, Teacup… Double Macchiato. Client side is a different story. [Explain.]

Typology

Rough attempt at classifying the various mechanisms, and evolutionary stages:

  1. HTML generators: server-side (originally, and typically), output is one string, serialized DOM, final state representation.
  2. “Inverting the sock inside-out”: from HTML strings embedded in program code, to code embedded in an HTML document.
  3. String interpolators, aka “logic-less”
  4. “Logic” languages
  5. (SS DSLs — see HTML templating with Double Macchiato)
  6. DOM populating: map or merge data onto the DOM. (“No HTML on the wire — only JSON”, and “the DOM is the model!”)

DOM pupulating

[Explain why evolutionary step over interpolation based paradigm. HTML <template> used as DOM, not string!]

Dreamcode first

  1. Preparation phase on server-side, rendering presentation into HTML:
    {h2,li,ol,p,template}=require 'double-macchiato'
    div '#foo',->
    	h2 'Fill'
    	p 'these up.'
    
  2. Then, client-side, populate that DOM in situ:
    $ '#foo'
    .contents() # (Optionally?)
    .fill data
  3. Or using HTML <template>, which the browser will automagically parse — no string interpolations:
    empty=undefined # (Syntactic sugar.)
    ol '#listing'
    template '#li-template',->
    	li ->
    		h2 '.title'
    		p '.description' 
    
  4. (Or “li ‘.event’,->h2();p()” and use longer selectors, “.event h2,.event p”, to style them, instead? Nu, CSS cascading issues… we won’t get into here.)
  5. Explicitly iterating over data, cloning a DOM fragment:
    template=$ '#li-template' # Find once, not in loop.
    .contents() # To discard wrapping <template> when cloning.
    $ '#listing'
    .append for x in data # (Loops are expressions in CoffeeScript!)
    	template
    	.clone() # Instantiate.
    	.fill x # Fill it up...
    

    Same, in more compact/familiar list-comprehension syntax:

    $('#listing').append (template.clone().fill(x) for x in data)
  6. Or iterate implicitly/automatically? [Hide distinction between object and iterable in API? Why?]
  7. Absolutely no need for looping or conditional “logic” in template: write these in our preferred programming language instead — CoffeeScript! Keep content (or semantic structure, in template’s case) in HTML.
  8. But, what’s in “data”? List of events, an array of objects, obviously. [What about recursion?]
  9. [Hide distinction between populating visible vs shadow DOM?]
  10. [Also, an inverse operation, say “scrape”, would be so cool! Especially since I’m big on contenteditable. Examples?])

Shape-shifting

  1. Neat if keys were actual CSS selectors indicating where values should be interpolated, but… limitations? Complications?
  2. Apparently, I want an explicit mapping so as not to persist data with CSS selectors in its keys: separation of concerns — selectors encode presentation (structure), not semantics. (Don’t I? I’m not sure, because HTML (which is what CSS selectors describe) is ideally content, not presentation, so selectors should have worked? Ouch, that’s “presentation” in the styling (CSS) sense vs “(re?)presentation” in the state (REST) sense!)

And the winner is…

[Transparency does the render nicely with “default” directives auto-detecting element/class/ID/[data-bind]?; Rule does full(?) CSS selectors right (actual DOM reliance, appropriately?), but, directives again; and Pure, neither?]

[But, Transparency’s implementation, if indeed parses HTML, as opposed to Rule (I think!?), sucks! I don’t care about Node, and browser has already parsed my template! And DOM already does CSS selectors!]

  1. Transparency
    1. They call it “zero configuration” (what does it even mean, in this context? what would non-zero configuration be?), but the data must either be structured to match the DOM “template” — implicitly configuring the mapping — or “directives”, viz configuration, need to be explicitly provided. WTF? [I’d rather not persist data structured isomorphically to its DOM: it’s the presentation model, not data model.]
    2. Maps keys to DOM elements, class, ID, and… attributes? But, how?
    3. Iteration is automatic (but requires container). Recursion?
    4. Similar/related: fill
  2. Pure is purely horrible: neé 2008, presumably preceding Transparency, seems to have lost their way: shape configuration (“directives”) is convoluted, and the implementation regresses to string interpolation?! [But, innerHTML used to be a performance thing?]
  3. Rule?

Bookmarks



Comments are closed.