Hyperhtml: Use of hyperHTML inside property getters

[jfrazzano]

For a few months, I have been using string literals inside getters in property definitions.

function Templator(){ Object.defineProperties(this,{ "templates":{ enumerable: true, configurable: true, get: function(){ let colors=["red","skyblue", "green", "yellow"]; return { butt:(colors)=>

${colors.map((c, i)=><input type="button" value="${c.toUpperCase()}" id="${1+c.toString()}" onclick="jannew.templates.start(64,${i+1} )" style="${'min-width: 200px; min-height: 70px; background: ' + c.toString() + '; padding: 12px; margin:0 20px 20px 20px;'}">).join(" ")}

, layout:(jindex, index, array)=>hyperHTML.wire()

, updategrid:(array, jindex)=>hyperHTML.bind(document.body)

${array.map(this.templates.layout)}

${this.templates.butt(colors)}`,
start:(number, jindex)=>{
let array=[];
for(let j=0;j this.templates.updategrid(array, jindex);
},

        };
    },
},

});

this.templates.start(64,1);

}

let jannew =new Templator();`

the above, without the hyperHTML should work. if you remove the wire, in the layout, and look at the demo page--- you will see that clicking the buttons on the bottom still "changes" the page. But I get the text blowout, I had mentioned before, without using a an insert.

here are three test pages:

first works fine: Its hyperHTML in the wild. Just out in a pen, plain js.

http://codepen.io/jfrazz/pen/JWaBdd

the second pen, uses the wire and we only see [object HTMLElement],
http://codepen.io/jfrazz/pen/73ec6ec23a1910291c44a07d8d8286cd
the third
I remove the wire, which makes it even more clear that the bind is working, the content is being changed, but the render is an issue...
http://codepen.io/jfrazz/pen/LWJgPM/

I could just be miss-using string literals or hyperHTML or both ... I was just hoping i could implement the updating advantages of your work in a larger dashboard project. I do not believe I have done that well in the above examples.

[WebReflection]

You had spaces around the HTML/Array/fragment entry

>${
  array.map(this.templates.layout)
}<

works

There are two rules to remember in hyperHTML and viperHTML

• attributes always in single/double quotes
• everything that is not surrounded by > and < will be text. This includes spaces or new lines

[WebReflection]

https://github.com/WebReflection/hyperHTML/blob/master/GETTING_STARTED.md#how-to-define-hyperhtml-templates

[jfrazzano]

Thanks so much... awesome and easy fix. My bad. Thanks again.

[jfrazzano]

Can everything be done in reduces? It's just easier to chunk Dom that way
and it's where I turn object arrays into elements

On Tue, Mar 28, 2017 at 3:11 AM Andrea Giammarchi [e-mail]
wrote:

>

https://github.com/WebReflection/hyperHTML/blob/master/GETTING_STARTED.md#how-to-define-hyperhtml-templates

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/WebReflection/hyperHTML/issues/28#issuecomment-289683427,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHxnvqHmrLTl_19XL9WO2TCRbU9QP9o3ks5rqLK4gaJpZM4MrBZP
.

>

---

Jason C. Frazzano Esq.
Founder and Master Coach, Focused Coaching
Stanford University, B.A. M.A., with honors and distinction
Columbia Law School, J.D., Stone Scholar
www.focusedcoaching.com
[email protected]
[email protected]
office: 732-671-1834

[WebReflection]

One does not simply "_chunk DOM_", you still want all those nodes to render as singular nodes, right?

the only issue I see is that you're using wires in the wild while you probably need to just return strings as those are.

In that case, you'll reduce automatically as single innerHTML operation, instead of appending _O(N)_ runtime created document fragments.

Once again, please take 5 minutes to read the documentation, including the getting started and the deep dive.

[WebReflection]

https://github.com/WebReflection/hyperHTML/blob/master/DEEPDIVE.md

[jfrazzano]

Youre right I never use the append I run continual strings tjrough reduces

Based on data whose structure will be unknown a priori.

So based on types and depth of data

Three templates I have been working on for fiive months unpack the data and
make beds guess on the element type arrangement,nesting labeling and
functions that should be bound.

I can't figure a way to use a spread operator select elements types and
order and use append, particularly with out gaps, as operations sometimes
just have to be carried out mid flow

I do "hurl chunks in the sense I can render from more or less any scope

A string is a string and an array of an array as far as data goes

A lot of the code I use is very similar actually

Particularly the attribute parsing, for on... Where u use the open gets and
sets I use a set-of-pseudo or proxyish objects

And then just assign
There.

The reason I made that choice was so that two objects that represent the
same data but from vastly different sources and sent in in very different
forms could be handled by a common registrar

What still keeps me hammering away at trying to meld the work, however, has
to do with a comment you made about a Dom one or zero prefix method-code

Like in c string terminus is handled by a null sequence

What makes a Dom node a Dom node a bit a string

A space obviously in one sense

But at the core level how might one tell one part of the Dom that he was
still handling a string and tell another part that all was copacetic and we
were all nodes on the board

It's not just spaces

Chaotic "Dom" jarring booed all object.on listeners and all declarative.

It loses this in large compiled objects that use property defines to
constantly update and remove properties

A number of things make the system shake

Is the a prefix, terminus, or similar semantic that allows the semantics of
this hyper arbitrary Dom to be sidestepped?

From your facility with the work, I imagine the answer is yes

On Wed, Mar 29, 2017 at 4:03 PM Andrea Giammarchi [e-mail]
wrote:

https://github.com/WebReflection/hyperHTML/blob/master/DEEPDIVE.md

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/WebReflection/hyperHTML/issues/28#issuecomment-290208670,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHxnvkrdt9J6_YyFrDw8qUzZP4-7ukClks5rqrkKgaJpZM4MrBZP
.

>

---

Jason C. Frazzano Esq.
Founder and Master Coach, Focused Coaching
Stanford University, B.A. M.A., with honors and distinction
Columbia Law School, J.D., Stone Scholar
www.focusedcoaching.com
[email protected]
[email protected]
office: 732-671-1834

[WebReflection]

you can nest wires, strings, and templates, ther's nothing complicated on a single update but definitively you need to figure out if it's cheaper to re-render all at once, or involve deep tree hierarchies and figure out what changed.

The problem with your approach, is that if you use hyperHTML.wire() N times, for N times you'll create new wires, as document fragments, and map them to their content.

If you used hyperHTML.wire(dataObject) instead, you'll create wires only once, because any other time, if dataObject is the same object that was used in that list before the update, operations will be instantly made (or fully skipped if same node).

hyperHTML.wire()`<li>hello</li>`;

That's always different from itself.

hyperHTML.wire(object)`<li>hello</li>`;

Will always be identical node, if object is the same.

If you change objects, through JSON.parse as example, per each update, forget about hyperHTML.wire() , it'll be useless.

What you'll need at that point is just an array of <li>hello</li> strings.

If you need a combination of strings and wires per single array/map/reduce, then your data is broken or inconsistent, which is another problem you could still address, but maybe the problem is not exactly hyperHTML or any other abstraction you could think of.

However, if you always have broken data, I don't think hyperHTML is a solution for your case, or better, it won't improve any performance compared to alternatives, it'll just be lighter and probably in most cases, but not all, faster.

It's your call, really, but don't expect changes in hyperHTML regarding hybrid collections or all its simplicity will be lost and there is already Virtual DOM for those hybrid scenarios, a different use case, IMO.

[WebReflection]

P.S. by broken, I don't mean hyperHTML can't work with conditional fields per object, it's quite the opposite, but you need a better strategy to target wires or you'll never see a performance boost

[WebReflection]

P.S.2 a concrete, simple, example written as indented code would be easier to show better patterns/approaches.
So far the GitHub post you wrote is absolutely unreadable and the code pen is too hard to follow due missing indentation.