lit.dev | The Lit website | Web Site library

You are setting the item only in the connectedCallback. Better you get the item dynamically via getter.

Regarding your question of setting an attribute of a slotted element, there is in my opinion no other way than programmatically.

Anytime we implement lifecycle callback methods, it's necessary to call the parent class's methods (so the superclass features work as-expected).

If you need to customize any of the standard custom element lifecycle methods, make sure to call the super implementation (such as super.connectedCallback()) so the standard Lit functionality is maintained.

Standard custom element lifecycle

In tsconfig.json you have to set option useDefineForClassFields to false to make lit run properly. For more information please see https://lit.dev/msg/class-field-shadowing .

To fully solve the issue with Storybook/Webpack I also had to do the following:

• yarn add -D ts-loader@8.3.0 (version 9.x does not work with Webpack4)

• [EDIT: Please check Vince's answer below ... his solution (= main.js + webpackFinal) seems to be the preferred way]

  Adding the following to .storybook/webpack.config.json (not really sure why):

By default lit element is acting in mode open. So customLitElement.shadowRoot returns a shadow-root.

If you want to run it in closed mode implement this method:

Deno 1.17.2 is able to successfully create a bundle. See https://github.com/denoland/deno/issues/13048 for background. As @jsejcksn said, SWC is most likely the culprit for the original issue.

Lit uses prefixes to indicate the type of expression in a component's template. The . prefix denotes a property expression; without the prefix it would be an attribute expression. Using a property expression makes it very easy and convenient to pass any JS object to a child element (in this case a Date object).

When using HTML attributes you need to be aware that they are always strings. JS data must be converted to a string on the parent element, and then possibly converted back to the corresponding JS type on the child element. No such conversion is performed with property expressions, because the data stays in "JS land".

So, why not always use property expressions? Two examples come to my mind right away:

1. For a property expression to work you need to know an implementation detail of the child element, i.e. that it has a corresponding JS property. (If you're dealing with your own Lit based elements inside a single project that is not a problem.)

2. If you want to apply selectors based on attributes (e.g. for styling my-button[disabled] { /* CSS ... /* } or using querySelector).

The goal of Lit, and of Polymer before it, is to help build web components and applications using browser features as much as possible.

For instance jQuery wrapped all the different browser features in it's own syntax, to the point where developers were learning jQuery, rather than Javascript. jQuery components assume that you have jQuery and rely on those jQuery methods to function.

Both Lit and Polymer championed web components - this makes each component much more self-contained. Using a mix of jQuery and any of its competitors was really painful, but that isn't the case here.

All the components used to build that shop are stable and still on npm. You can use them if you want and I have live applications that still use them.

However, championing the latest browser features has its risks. Polymer relied heavily on HTML Imports (that only Chrome ever implemented and were ultimately dropped) and its own template library. It was ultimately ported to ES6 modules, but the core design is far less suited to it. Those components are pretty stable, but you don't really want to start anything new with it.

Lit is quite a lot less opinionated than Polymer, and much lower level. For instance Polymer supported two way binding with {{property}} syntax, but had to make assumptions (that often broke) about what you were doing to support it. Lit drops that for extremely stable property setters but if you want to users to write values you have to subscribe to events and roll that yourself (Lit does make events very easy to manage though).

So if you're going to build your own web components or application Lit is by far the better choice, and LitElement is lightweight and extremely compatible with everything else. You can use those Polymer shop components in Lit (I have) but for most of them there are newer alternatives, in particular MWC.