These are chat archives for jdubray/sam

7th
Nov 2017
Jean-Jacques Dubray
@jdubray
Nov 07 2017 13:10
Not sure if you knew this trick, it's awesome: https://twitter.com/maxpeterhill/status/926585490144419840
Jean-Jacques Dubray
@jdubray
Nov 07 2017 13:43

I have a Web Component component question.
Say I defined one like this (lit-html):

 class MyCustomElement extends HTMLElement { ... }

 customElements.define('mce-representation', MyCustomElement )      

 let mce = document.getElementById('mce')

is mce an instance of the class MyCustomElement ? if yes, I should be able to call any method of the class? if no, why not?

short answer: yes
(and BTW that article is simply fantastic)
Jean-Jacques Dubray
@jdubray
Nov 07 2017 14:14
yes, thank you, I was able to get a reference, I was just confused about the instantiation vs id. I needed to add something like:
<mce-representation id="mce"><mce-representation>
That being said, it's not rendering the template literal correctly, yet. I'll start exploring that aspect.
Jean-Jacques Dubray
@jdubray
Nov 07 2017 14:26
Looks like I may need to use web-components-shards
Paolo Furini
@pfurini
Nov 07 2017 14:26
yes they are simply html elements in the dom, as the others, so to get a reference in your code you use the usual methods for getting a reference, nothing special here
Jean-Jacques Dubray
@jdubray
Nov 07 2017 14:27
yes, I understand now, it makes sense. Thank you again.
Paolo Furini
@pfurini
Nov 07 2017 14:29

Looks like I may need to use web-components-shards

for components reuse in multiple pages?

Jean-Jacques Dubray
@jdubray
Nov 07 2017 14:30
It seems that error I get is related to that, event though at this stage, I am running some basic SPA code:
Error: Failed to execute 'define' on 'CustomElementRegistry': this name has already been used with this registry
at eval (_inline_script_1.js:33)
at Object.getAnonymousModule (ModuleStoreImpl.js:285)
at eval (_inline_script_1.js:1)
at eval ()
at LoaderCompiler.evaluateCodeUnit (LoaderCompiler.js:91)
at EvalCodeUnit.evaluate (InternalLoader.js:173)
at InternalLoader.evaluate (InternalLoader.js:564)
at InternalLoader.handleCodeUnitLoaded (InternalLoader.js:448)
at InternalLoader.js:285
Paolo Furini
@pfurini
Nov 07 2017 14:30
that's the problem of a vanilla approach, at the end you'll end up using a myriad of satellite libraries, from known and less known sources.. that's why google is maintaining two separate front-end efforts (polymer and angular)...
Jean-Jacques Dubray
@jdubray
Nov 07 2017 14:30
I see
Paolo Furini
@pfurini
Nov 07 2017 14:31
but they are converging now.. the next step will be slowly migrating "traditional" angular components with WC ones, soon without polyfills at all
angular will remain only to glue together the native web components, and polymer will be integrated in a bigger effort (angular based, if they'll continue with the same name)
Jean-Jacques Dubray
@jdubray
Nov 07 2017 14:33
I can see the big picture, but again, I would prefer that the rendering/listeners be outside Web Components (like lit-html)
Paolo Furini
@pfurini
Nov 07 2017 14:33
the rendering I fear will be always seen tied to the internal structure of the WC itself
Jean-Jacques Dubray
@jdubray
Nov 07 2017 14:34
There are really two parts, building the state representation (DOM tree), then "render".
I don't mind if each component own their state representation, that would make sense to me
but I need render to be outside. lit-html has an independent render function (html and render), but for now I cannot get it to run outside a component.
Paolo Furini
@pfurini
Nov 07 2017 14:35
to be really portable (think of using the same component in angular and react) it must own its state repr
Jean-Jacques Dubray
@jdubray
Nov 07 2017 14:36
yes, I have no problem with that.
Paolo Furini
@pfurini
Nov 07 2017 14:36
why you need to extract the rendering?
Jean-Jacques Dubray
@jdubray
Nov 07 2017 14:36
I just need to call render(overallStateRepresentation)
This is part of the Single-State-Tree/Unidirectional-Data-Flow architecture
you want the overall state representation to be computed from the sum of the component state representation and then say render
Of course, I can create a container component for that, but I don't like it.
IMHO, the computation of the state reprensentation and the rendering should be entirely separate.
Paolo Furini
@pfurini
Nov 07 2017 14:40
I see, I agree then
One approach (with standard WC, don't know lit-html) is to use template cloning, but constructing the innerHTML property of the template before cloning and attaching to the VDOM
this should be repeated at every render, don't know the performance implications
Paolo Furini
@pfurini
Nov 07 2017 14:47
or even easier with shadow dom alone:
// in ctor
this.attachShadow({mode: 'open'});
// in render()
this.shadowRoot.innerHTML = yourComputedHtmlContent;
I never tried this approach, but I know it worked even before v1.. you could simply replace the entire vdom content at every cycle, and expose the render method as an instance method of the WC itself
Paolo Furini
@pfurini
Nov 07 2017 14:52
now, as I said before, I don't know if, without some specific optimisations to recognize mutations even when replacing the entire tree, the performance will become horrible for large trees of components that re-renders themselves everytime
from my limited knowledge of react (or mithrill) they using diffing algs to minimize the impact of re-rendering whole trees, but that's impact processor performance in slower devices (and very large trees)
Jean-Jacques Dubray
@jdubray
Nov 07 2017 14:57
thank you, I'll try it tonight.
Paolo Furini
@pfurini
Nov 07 2017 14:59
a simple diffing alg, beside full dom diffing like in react, could be defining multiple roots inside a complex component tree, and re-rendering of each root (subtree) will be triggered only by mutating state pertaining that subtree
that is, you are decomposing a single VDOM tree in multiple trees, and you maintain root references to each subtree, then during render you'll replace the representation of subtrees that are associated with effectively mutated state
Paolo Furini
@pfurini
Nov 07 2017 15:04
we could also factor this in a reusable lib, that keeps track of DOM roots and associated state triggers. we could associate a private function, like _renderSubtree1 with a mutation trigger, so that the root render function will be (transparently) decomposed in multiple micro render functions (incapsulated in WC, only the root render function will be public)
Jean-Jacques Dubray
@jdubray
Nov 07 2017 16:20
Yes, in essence that's already what I am doing with hash-dom
I was trying to avoid using innerHTML since people seem to see it as "not-as-safe" as dom manipulations (via vdom algorithms)
Fred Daoud
@foxdonut
Nov 07 2017 17:14
https://awelonblue.wordpress.com/2012/07/01/why-not-events/
Jean-Jacques Dubray
@jdubray
Nov 07 2017 17:58
@foxdonut that's a really good summary explaining why you need to implement event handlers with the SAM pattern!
Jean-Jacques Dubray
@jdubray
Nov 07 2017 18:54
As with most systemic accidental complexity, this is not obvious until you’ve experienced something better.
Fred Daoud
@foxdonut
Nov 07 2017 19:12
@jdubray :thumbsup: