Lit-html: Include a small example for a Polymer 3.0 element in the README.md

[vudzero]

Hi,

I see the example with a 'generic' element using the 'render()' function. I was wondering if it was possible to add a simple example with a polymer 3.0 element to the readme file? Or at least define what the CoolLitMixin contains?

Thanks

[DerDrodt]

I just wrote lit-element which is a class that allows you to use lit-html easily with Custom Elements, especially if you are familiar with Polymer.

It is in really early stage, as I did it just this morning, but it seems to work as expected.

[kenchris]

I have something similar here: https://sensor-compass.appspot.com/scripts/lit-element.js feel free to pick pieces if that makes sense :)

[nicolasparada]

[KeithHenry]

I think a mixin is a better fit here, rather than extend a base class.

This way the mixin can be used with Polymer.Element or Element or anything else.

Something like...

import { html, render as litRender } from '/modules/lit-html/lib/lit-extended.js';
export function WithLit<T extends Constructor<Element>>(Base: T) {
    return class extends Base {
        render(template: TemplateResult): void {
            ...
            const r = this.shadowRoot || this.attachShadow({ mode: 'open' });
            litRender(template, r);
        }
    }
}

export class MyElement extends WithLit(Polymer.Element) {
    ready() {
        super.ready();

        this.render(html`<div>${123}</div>`);
    }
}

CoolLitMixin is the other way round - expecting the extended base to have a render method and adding the result of that to the shadow DOM.

[justinfagnani]

@kenchris I have a little bit of feedback on your base class. Let me know if you want to chat about it :)

[kenchris]

@justinfagnani sure, I am interested. Tried to ping you in private on Twitter, but I think you don't follow me. What would be the best way to talk?

[kenchris]

I know it misses case conversion etc :) but that should be easy to add

[justinfagnani]

Honestly, I'd skip the case conversion and have the property definition include the attribute name. No ambiguity that way.

[daKmoR]

awesome idea :) just included the case conversation in my lit-element... but that sounds way nicer :)

[kenchris]

@justinfagnani I fixed your comments and pushed to a new repo: https://github.com/kenchris/lit-element

To anyone here: Tests and PRs are welcome :-)

[klebba]

@kenchris Can you add some commentary about why you use Promise.resolve() ahead of the render?

[kenchris]

@klebba read this: https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/

Promise.resolve() basically puts it back on the event loop (makes it async), which is handy because it (invalidate) might be called from anywhere (ie from events themselves, timers etc) - that also makes things consistent.

Basically it becomes a microtask

"Microtasks are usually scheduled for things that should happen straight after the currently executing script, such as reacting to a batch of actions, or to make something async without taking the penalty of a whole new task."

"The microtask queue is processed after callbacks as long as no other JavaScript is mid-execution, and at the end of each task. Any additional microtasks queued during microtasks are added to the end of the queue and also processed. Microtasks include mutation observer callbacks, and as in the above example, promise callbacks."

So the whole point with this is to batch updates. Like during one execution of the event loop, you might run code - say in same scope - updating multiple properties all resulting in invalidate() calls. Additionally there might fire multiple events also resulting in invalidate() calls. Now all of these marks that a render is required and that is then executed as a microtask afterwards - thus batching the updates.

[web-padawan]

BTW, Polymer uses its own microtask implementation, see here:

Note that microtask timing is achieved via a single MutationObserver, and thus callbacks enqueued with this API will all run in a single batch, and not interleaved with other microtasks such as promises. Promises are avoided as an implementation choice for the time being due to Safari bugs that cause Promises to lack microtask guarantees.

[kenchris]

I added a bit of documentation now: https://github.com/kenchris/lit-element/blob/master/README.md

[klebba]

@kenchris Thanks!

[kenchris]

@klebba I added some demos as well https://kenchris.github.io/lit-element/

I still need to make an npm module, but I have never done that before :-) so need to figure out how

[kenchris]

OK, so I published an npm module 'lit-html-element' for now, but I will want to fix paths etc

[NeoLegends]

Hey @kenchris! lit-element looks neat! I made a PR with some changes I think fit nicely.

---

We have an another stance on lit-html + web components: We created a combination of redux + web components + lit-html called 💪-html. We tried to keep the total size of the library below 5kb to fit the original spirit of this library and we're introducing Redux into the mix for a cleaner application structure. (this means that fit-html is probably unsuited for single components like buttons, date pickers, etc.)

Would love to see some feedback. :)

[kenchris]

Hi there @NeoLegends - cool, I will have a look :-) I just got back from the US so I am a bit jetlagged still though.

I have the plan to ship my mini element into a set of mixins, but I have to find the proper way of doing so.

[justinfagnani]

FYI, there's a lit-element in progress here: https://github.com/PolymerLabs/lit-element

[justinfagnani]

Closing as more relevant to lit-element.