profile
viewpoint

issue commentPolymer/lit-html

Values changed outside of lit-html rendering are not updated from lit-html

I'm fairly certain the performance cost of using underlying properties for source of truth is very minimal. I am concerned it will cause problems with setters, both because it will invalidate the cache causing lit-html to write on every render, and because custom setters are generally more expensive to write to than basic properties.

justinfagnani

comment created time in 3 hours

issue commentPolymer/lit-html

Values changed outside of lit-html rendering are not updated from lit-html

That work around is correct, and is a somewhat heavy-handed but totally valid approach to getting the desired outcome.

The real problem is that the model (what lit-html thinks is the value of the input) and the reality (the actual state of the input) is not the same. This happens when "a radio button is set to checked outside lit-html" and this change is not correctly synced back into the model. If lit-html thinks the checked property was false and still is false, it won't bother setting it to false. This is good, because it cuts down on useless operations, but if your checked property changed to true outside the knowledge of lit-html, then it is obviously bad, because the property should be set to false again.

The "real" solution to fixing this problem is by making sure your input state is always synced with what lit-html thinks, but this can be very cumbersome and sometimes hard do correctly. In those cases, a simple solution like the above can be appropriate.

I will try my hand at implementing a live directive over the weekend, which is an alternative to this force directive, but in the grand scheme of things I expect the performance difference between these to not be very significant.

justinfagnani

comment created time in a day

issue commentPolymer/lit-html

Feature request, boolean property shorthand

This is about the templating system. <my-elem> in this example is not necessarily LitElement based. It may be any type of Element, that may not set the property based on presence of attributes.

In addition to that, setting attributes is generally more expensive than properties.

rictic

comment created time in a day

issue commentPolymer/lit-html

Feature request, boolean property shorthand

This is not possible. We don't parse the contents of templates, except those surrounding escaped values to determine what part to create. (more or less)

The feature request was about setting properties, not attributes. @CaptainCodeman

rictic

comment created time in a day

create barnchruphin/concurrency-test

branch : master

created branch time in 5 days

created repositoryruphin/concurrency-test

A simple concurrency mutex testing shell

created time in 5 days

issue commentPolymer/lit-html

Values changed outside of lit-html rendering are not updated from lit-html

There are multiple reasons why you generally want to use properties over attributes when possible.

The fist one is that attributes are generally used to set the initial state of an element, and properties generally reflect the current state of an element. Not every element reacts to changes in attributes, but changing the state through properties will almost always have an effect.

The second reason is that attributes have overhead. You don't need to interact with the DOM if you set properties directly.

justinfagnani

comment created time in 11 days

issue commentPolymer/lit-element

LitElement lifecycle timing issue

What you are seeing is most likely an unrelated issue.

In the connectedCallback there are no guarantees that your children have been attached.

The browser constructs the DOM tree in parsing order, and if it encounters any custom elements, these are connected before their content is parsed and connected. This means that if your custom element is loaded and defined before a document is parsed, the connectedCallback will be called before the children are attached. Aside from the loading order, it also depends on if the element is inside a document body, or if it is being cloned from a template or something like that.

I have a demonstration of this here: https://codepen.io/ruphin/pen/omjYQj?editors=1001

The correct method to interact with your children is to use the slotChanged event: https://developer.mozilla.org/en-US/docs/Web/API/HTMLSlotElement/slotchange_event

ruphin

comment created time in 11 days

issue openedPolymer/lit-element

LitElement lifecycle timing issue

Description

When awaiting a resolved promise in the connectedCallback, the first render call either did or did not yet occur, depending on the browser. Chrome will always perform an initial render before resolving any promises created in the connectedCallback, but Firefox and Safari may resolve promises in the connectedCallback before performing the initial render.

Live Demo

Open this page in Chrome, Firefox, and Safari: https://codepen.io/ruphin/pen/JgOaKP?editors=1010

In Chrome, the resolution order will be CONNECTED CALLBACK RENDER PROMISE RESOLVED

In other browsers, the resolution order will be CONNECTED CALLBACK PROMISE RESOLVED RENDER

Browsers Affected

<!-- Check all that apply -->

  • [x] Chrome
  • [x] Firefox
  • [x] Safari 11

Versions

  • lit-element: v2.2.1

created time in 20 days

push eventruphin/dotfiles

Goffert van Gool

commit sha 9326c50a2855d8f265a0ffca8cb05e55606dfb59

fix ls colors for macos

view details

push time in 20 days

push eventruphin/dotfiles

Goffert van Gool

commit sha 583d5600ea84a2f9fb7901d6f85818c90c366e6b

Add bash configuration

view details

push time in 20 days

fork ruphin/lit-demos

Examples for using the lit-html library and LitElement base class

https://open-wc-lit-demos.stackblitz.io/basic

fork in 23 days

fork ruphin/lit-demos

Examples for using the lit-html library and LitElement base class

https://open-wc-lit-demos.stackblitz.io/basic

fork in 23 days

issue commentPolymer/lit-html

Support namespaced attributes

The current solution is to use a directive, which works fine for your usecase. An example of such a directive and how to use it can be found up in this thread: https://github.com/Polymer/lit-html/issues/423#issuecomment-432056517

silenceisgolden

comment created time in 25 days

issue commentPolymer/lit-html

repeat directive documentation

Technically, Array.prototype.map also retains the state of the DOM elements.

The difference between Array.prototype.map and repeat is that repeat is keyed. In other words, in repeat each DOM element is associated with a unique key in the source array item.

Practically this means repeat has the following behaviours:

  • If the source array re-arranges the items, the DOM elements will also re-arrange in the same way.
  • If an item in the source array is deleted and replaced with an item with a different key, the associated DOM element will also be deleted and replaced with a new one.

In these cases Array.prototype.map would retain all the original DOM elements (and their state) in the original order. It will only re-assign the dynamic values if appropriate.


Note that by default the key in repeat is the index in the array, which effectively makes repeat behave exactly like a more computationally expensive Array.prototype.map. The key function is an optional argument in the repeat directive, but you should never use repeat without a key function.

jadjoubran

comment created time in a month

issue commentPolymer/lit-html

Values changed outside of lit-html rendering are not updated from lit-html

This is an unrelated issue, there is most likely some kind of error in your code that passes the data around. Here is a working example of what you are trying to do:

https://codepen.io/ruphin/pen/EBJGaa?editors=1010

justinfagnani

comment created time in a month

Pull request review commenting-bank/lion

Popper.js implementation in LocalOverlay

 import { overlays, LocalOverlayController } from '@lion/overlays'; export class LionPopup extends UpdatingElement {   static get properties() {     return {-      position: {-        type: String,+      placementConfig: {+        type: Object,       },     };   } +  get placementConfig() {+    return this._placementConfig;+  }++  set placementConfig(config) {+    this._placementConfig = {+      ...this._placementConfig,+      ...config,+    };++    if (this._controller && this._controller._popper) {+      this._controller.updatePlacementConfig(this._placementConfig);+    }+  }

You can use getters and setters with or without having the property in static get properties. If you have it in properties, the element will trigger a render when the setter is called. Alternatively, you can call this.requestUpdate() in the setter, but in general, I think placing the property in properties is the preferred method if the element needs to re-render when the property changes.

For properties that do not trigger renders, getter and setter without having it in properties is fine.

jorenbroekema

comment created time in 2 months

push eventruphin/proxy-clone

Goffert van Gool

commit sha 672ab07e026b3b4c9001b5c2d8be5840d25dd6de

test

view details

push time in 2 months

push eventruphin/proxy-clone

Goffert van Gool

commit sha 853b196dc30b485df5beb50654a15cb15738b902

Fix

view details

push time in 2 months

push eventruphin/project

Goffert van Gool

commit sha 771a80fc6ede5a8219398b0a4e1c320d878a9980

Rename docker image

view details

push time in 2 months

push eventruphin/proxy-clone

Goffert van Gool

commit sha 7058aacbd2b661208214998038aead1a86b384a1

Add proxy project

view details

push time in 2 months

push eventruphin/project

Goffert van Gool

commit sha 33ba5f08b754bbca8a33c2e76bd2539e18f58784

Initial commit

view details

push time in 2 months

create barnchruphin/project

branch : master

created branch time in 2 months

created repositoryruphin/project

created time in 2 months

push eventruphin/proxy-clone

Goffert van Gool

commit sha 779a8cfdcf71cf2d43e49cab1d9bb557abdc65ae

Add file server

view details

push time in 2 months

push eventruphin/proxy-clone

Goffert van Gool

commit sha a1ce0c46b7e9ed5e7843aa51606301818e54361d

Remove old certs

view details

push time in 2 months

push eventruphin/proxy-clone

Goffert van Gool

commit sha 6d3a4f99b17d52ae2955e72838390f8e76acbae8

Remove nginx resolver

view details

push time in 2 months

push eventruphin/proxy-clone

Goffert van Gool

commit sha aca0d4d43749777c8cbf09dbcf58532a226eab24

Fix container name

view details

push time in 2 months

create barnchruphin/proxy-clone

branch : master

created branch time in 2 months

created repositoryruphin/proxy-clone

created time in 2 months

issue commentPolymer/lit-html

Request to clarify DOM-updating feature

If the original author thinks this issue can be closed, we can probably close it. I will find a new appropriate space to continue the naming discussion.

sdegutis

comment created time in 2 months

push eventing-bank/lion

Goffert van Gool

commit sha 21640405736cc7cdb8b54c2322dfccbcbf03ba3d

Update LionIcon.js Only show nothing if `svg` is `undefined`.

view details

push time in 2 months

pull request commenting-bank/lion

Update LionIcon to no longer render 'undefined'

Personally, I think handling undefined is not necessarily violating the API. undefined is literally the absence of a value, and not a special value type that you have to coerce into String. The API is that the svg property contains a String (or any Object), in which case that String is inlined as the used svg image, or the svg property is undefined, in which case the content is empty.

There are obvious cases why it is desirable from a user perspective to have this behaviour. The main reason is that the <lion-icon> element takes space in the layout. An empty <p> still has margins and takes space in the layout, and an empty <lion-icon> should do the same. A common use case is a list of icons with labels. I want the labels to align, so the icons need to always take a predictable amount of space, even if no icon is defined for a specific label. If I have to conditionally render <lion-icon>, I need to either wrap it in another element with a defined and predictable size, or have some kind of replacement <lion-icon-spacefiller> element that I can render instead if the icon is undefined. This is incredibly inconvenient.

There are plenty of cases where showing nothing is the desired behaviour, but it is never correct to paint the text "undefined".

I know the <img> element coerces undefined to string in the src property, but I consider that behaviour broken. Lets not do things "because that's the way it always has been done", but make decisions based on reason.

It doesn't even take extra code to handle the undefined case like this. If we agree that the element should be consistent, i.e. it should render "undefined" in the <lion-icon></lion-icon> case, that will take additional code, which is probably just as much as the code required to handle undefined gracefully.

I have made my case. You can decide what behaviour you would like this element to have. My main priority is making it deterministic, so if you make a choice I will refactor this PR to implement whichever option you choose.

ruphin

comment created time in 2 months

issue commentPolymer/lit-html

Request to clarify DOM-updating feature

MDOM or MemDOM is a good suggestion, I like it.

sdegutis

comment created time in 2 months

issue commentPolymer/lit-html

Request to clarify DOM-updating feature

Also, I think what HyperHTML does well is communicate directly that it is a "VirtualDOM replacement" which immediately sets the user's expectation, which seems to be the main source of confusion for the OP. I think lit-html could do much better in that sense, because it's current description of "HTML templating library" is rather vague and doesn't leverage the user's existing knowledge.

sdegutis

comment created time in 2 months

issue commentPolymer/lit-html

Request to clarify DOM-updating feature

I think using (nested) tagged template string literals to construct a tree of dynamic and static parts of DOM is the key differentiating idea. The method used to update the dynamic parts (either using domdiff or previous-value-comparisons like what lit-html seems like a detail that is not necessarily novel or relevant to create understanding of how the system works (You can even call that part 'dom diffing' and leverage on the user's existing knowledge).

It would be nice if we could find a name for the concept of constructing a tree of dynamic and static parts, and using that information to render and propagate updates.

sdegutis

comment created time in 2 months

issue commentPolymer/lit-html

Request to clarify DOM-updating feature

I think something that would help a lot in educating people on how lit-html works and what it does is find some kind of nomenclature for the underlying algorithm, like how React has VirtualDOM. We have several implementations of the same general algorithm now; HyperHTML, lit-html, lite-html; but there is no common way to describe what they are doing.

I find that users are much more open to learning/understanding an idea or concept like "VirtualDOM" than something like "How React works internally". A term like 'VDOM' or 'VirtualDOM' is also portable between different implementations of it, and once users grasp the concept, they will understand what React, Preact, Vue, and all these frameworks do, without having to understand their specific implementation.

Instead of explaining how lit-html works, can we find a common nomenclature for this type of updating DOM, and focus on explaining that? That way we can combine educational efforts from multiple projects, and it also opens up things like speaking about the concept at general JavaScript conferences without being focused on one project.

Paging @WebReflection

sdegutis

comment created time in 2 months

pull request commenting-bank/lion

Update LionIcon to no longer render 'undefined'

This is most certainly a bug.

svg is part of the state of the element. With the current implementation I can have two identical <lion-icon> elements with identical properties and state, and one of them shows nothing and the other shows the text "undefined". It's not about correcting malformed input to the svg property, it's about consistency of how you handle state.

Here is an example where you run into this problem:

const items = [
  {
    icon: '<svg>...</svg>',
    title: 'Something with icon',
  },
  {
    title: 'Something without icon',
  }
];

render(items.map(item => 
  html`
    <div>
      <lion-icon .svg=${item.icon}></lion-icon><span>${item.title}</span>
    </div>`
  ), container)

This code works just fine, and items without an icon render a blank icon. However, when we re-render and some items may no longer have an icon because the list changed, we randomly start rendering "undefined" for some of the icons. My template is fully delcarative, so it should not have any problems, but <lion-icon> breaks, because the element has a hidden "I once had a non-undefined value in my svg property" state that I cannot access. I don't see how this can be considered not a bug. As it is now the element behaves in a non-declarative way, and I cannot deterministically set it's behaviour without destroying it and re-creating it to ensure it is in the right state.


If you decide that a <lion-icon> element that has an undefined svg property should render the text "undefined", then it should also render "undefined" in every case where svg is undefined, including when you create a new icon without setting the svg property initially.

If you decide that a <lion-icon> element with an undefined svg property should be blank, then it should be blank in all cases where svg is undefined.

Personally I don't see why anyone would consider the first scenario to be correct, but if you choose to do that for whatever reason, it's fine with me. I just need it to be consistent.

ruphin

comment created time in 2 months

pull request commenting-bank/lion

Update LionIcon to no longer render 'undefined'

I updated the entire class a bit. I verified that the test cases we discussed are handled correctly. I don't know why the tests were producing unexpected results. The test setup you are using seems unnecessarily complex to me, I used something simple like this and it worked for me:

let resolveA;
  const a = new Promise( resolve => {
    resolveA = () => resolve('thing');
  });
  let resolveB;
  const b = new Promise( resolve => {
    resolveB = () => resolve('other');
  });
ruphin

comment created time in 2 months

push eventing-bank/lion

Goffert van Gool

commit sha 2e2acfd74ff88daf5ea6f07f584d71d6990c9749

Fix eslint thing

view details

push time in 2 months

push eventing-bank/lion

Goffert van Gool

commit sha 29714573e710865bcb03b83a614a4998bd9ce0d5

Update LionIcon.js Cleaned up the implementation

view details

push time in 2 months

push eventing-bank/lion

Goffert van Gool

commit sha b2c9ac93e422b9ad4358b2b87c06f38baa4c198c

Fix typo

view details

push time in 2 months

PR opened ing-bank/lion

Update LionIcon to no longer render 'undefined'

Fixes #115

+13 -15

0 comment

1 changed file

pr created time in 2 months

create barnching-bank/lion

branch : ruphin-patch-1

created branch time in 2 months

issue commenting-bank/lion

[bug] Icon renders 'undefined'

I have a fix for it already. I'll submit a PR tomorrow.

ruphin

comment created time in 2 months

issue openeding-bank/lion

[bug] Icon renders 'undefined'

When you create a new <lion-icon> element, the svg property is initially undefined, and it renders nothing (blank space).

When I explicitly set the svg property to the value undefined (after it being set as something else) it renders the text "undefined" instead of rendering blank space.

I expect the element to render nothing when I set the svg property to undefined.

created time in 2 months

issue commentPolymer/lit-html

Discussion: use semantic-release and conventional commits

Checking out what is the latest state of the library is already possible by installing from the master branch on github. Installing packages off a git repo is supported in NPM, but unlike a different package version it is very clear that it is something you should probably never do in a published package.

web-padawan

comment created time in 2 months

issue commentPolymer/lit-html

Discussion: use semantic-release and conventional commits

I think not releasing often is a feature, not a bug. Lit-html is quite fragile in the sense that applications stop working if for any reason multiple versions of lit-html exist. Because NPM does not really having any features to systematically avoid this, the more often we get new releases the more often things will break.

Also, packages that depend on some kind of pre-release version will be incompatible with packages that depend on a non-pre-release version, by definition. I think it's a terrible idea to have two "official" releases that are incompatible with eachother, it will just lead to fragmentation of the ecosystem.

web-padawan

comment created time in 2 months

issue openedwebcomponents/polyfills

Stylesheet link support

The following syntax is allowed in the Web Component v1 specification and currently works correctly on Chrome and Safari:

<template id="element-template">
  <link rel="stylesheet" href=style.css">
  <div>...</div>
</template>

At the moment, this polyfill only seems to support inline style tags. Is support for link tags in the pipeline, or will it remain unsupported?

created time in 3 months

more