Refine API and refactor #132

sorvell · 2018-07-25T00:57:19Z

WIP (do not merge). Tests do not pass.

does not rely on Polymer
API
- startup:
  - constructor => initialize => createRoot
  - connectedCallback => enableUpdate => invalidate
- update/render:
  - property change => invalidate =>
  - (async) shouldUpdate => update
  - resolves any updateComplete promise

justinfagnani · 2018-07-25T18:34:41Z

src/lit-element.ts


  /**
-   * Override which sets up element rendering by calling* `_createRoot`
-   * and `_firstRendered`.
+   * Override which performs element rendering by calling the `render` method.


"Override which performs..." -> "Performs..." to follow the 3rd person, starts with a verb phrase style.

justinfagnani · 2018-07-25T18:40:33Z

src/lit-element.ts

-   * TemplateResult. By default this template is rendered into the element's
-   * shadowRoot. This can be customized by implementing `_createRoot`. This
-   * method must be implemented.
+   * The implementation must return a `lit-html` TemplateResult.


How about:

Invoked on each update to perform rendering tasks. This method must return a lit-html TemplateResult.

justinfagnani · 2018-07-25T18:42:39Z

src/lit-element.ts

-    this.__isInvalid = true;
-    super._invalidateProperties();
+  protected render(): TemplateResult {
+    throw new Error('render() not implemented');


It'd be nice to mark this method (and class) as abstract so IDEs will tell you to implement it. TS doesn't support default implementations on abstract methods though, so the error would have to go. Luckily, we'll still get an exception in update, which I think is good enough. If we wanted to add nicer messages, we could check for the existence of render in update.

justinfagnani · 2018-07-25T18:42:51Z

src/lit-element.ts

-  private __isInvalid: Boolean = false;
-  private __isChanging: Boolean = false;
-  private _root?: Element|DocumentFragment;
+export class LitElement extends UpdatingElement {


Mark as abstract

justinfagnani · 2018-07-25T18:44:26Z

src/lib/updating-element.ts

+ * Creates a property accessor on the given prototype if one does not exist.
+ * Uses `getProperty` and `setProperty` to manage the property's value.
+ */
+function makeProperty(name: string, proto: Object) {


I prefer all functions that don't need a bindable this to be const arrow functions. They should be very marginally faster in VMs.

justinfagnani · 2018-07-25T19:31:54Z

src/lib/updating-element.ts

+   * return `this`.
+   * @returns {Element|DocumentFragment} Returns a node into which to render.
+   */
+  protected createRoot() {


createRoot -> createRenderRoot?

justinfagnani · 2018-07-25T19:33:04Z

src/lib/updating-element.ts

+   * @returns {Element|DocumentFragment} Returns a node into which to render.
+   */
+  protected createRoot() {
+    this.root = this.attachShadow({mode : 'open'});


If the contract is that this method should always set this.root, why not just have this method return something and do the assignment in initialize?

justinfagnani · 2018-07-25T19:35:09Z

src/lib/updating-element.ts

+    for (const p in (this.constructor as typeof UpdatingElement)._classProperties) {
+      if (this.hasOwnProperty(p)) {
+        // tslint:disable-next-line no-any
+        const me = (this as any);


I'd do the cast on p, since this line won't be won't be compiled out.

justinfagnani · 2018-07-25T19:35:44Z

src/lib/updating-element.ts

+    this.createRoot();
+    // save instance properties.
+    for (const p in (this.constructor as typeof UpdatingElement)._classProperties) {
+      if (this.hasOwnProperty(p)) {


Comment on why this if block is here

justinfagnani · 2018-07-25T19:45:10Z

src/lib/updating-element.ts

+  /**
+   * Object with keys for all properties with their current values.
+   */
+  props: AnyObject = {};


I think this can be typed better as just props: this

graynorton

I haven't dug deeply, but it appears the coupling between lit-html and the rest of the implementation here is very loose. If there's literally nothing lit-specific in the rest of the implementation, I'd argue in favor of publishing it as a separate library so that it could potentially be paired with a renderer other than lit. Could still live in the same repo, of course.

graynorton · 2018-07-27T00:03:06Z

src/lib/render-helpers.ts

+ * http://polymer.github.io/PATENTS.txt
+ */
+
+import {camelToDashCase} from '@polymer/polymer/lib/utils/case-map.js';


Is the plan to copy/paste or reimplement here and remove this dependency on Polymer (along with the declared dependency in package.json)?

rickcnagy · 2018-07-27T22:02:04Z

Hey @sorvell, @rictic mentioned this PR in a chat about other lit-element things. Looking through this, I’m noticing that it seems like there’s no equivalent for _propertiesChanged(). Is that intentional? Right now my team is using that fairly extensively to make GETs after a necessary ID attribute is set at runtime. We could change to a different pattern if that’s what you recommend.

* Property options have been updated to now include: `attribute`: set to explicitly false to not observe, to a string to customize name, or true or absent to observe lowercased name; `type`: if a function, used to deserialize attribute value, otherwise can be an object with {fromAttribute: deserializing function, toAttribute: serializing function}; `reflect`: if true, property reflects to attribute using type.toAttribute if present; `shouldInvalidate`: function used to determine if a change should trigger invalidation. * setting properties in update now does not trigger invalidation and does not issue a warning. This can and should be done to compute values before updating. * finishUpdate has been added to perform post update tasks like direct dom manipulation. It is an async function which will be awaited before resolving the updateComplete promise. Setting properties in finishUpdate will trigger invalidation and this will finish before the updateComplete promise is resolved. * no longer depends on polymer.

sorvell · 2018-08-04T00:55:18Z

@justinfagnani PTAL Lots of changes per offline discussion:

The property options have been updated.
The update lifecycle has been updated.
The logic in invalidate is especially tricky and could probably use better factoring.
I'm still calling invalidate in connectedCallback rather than when constructed due to some trickiness with ShadyCSS that we can discuss.

TODO

We need to decide if UpdatingElement should be separate and in this package or broken out.
Need to move the render-helpers into lit-html.

justinfagnani · 2018-08-04T01:23:45Z

@rickcnagy the pattern here would be to override update(changedProps). It should map pretty cleanly.

justinfagnani

Not a full review, but a couple of quick comments...

justinfagnani · 2018-08-04T01:24:55Z

src/lib/updating-element.ts

+   * implemented to render and keep updated DOM in the element's root.
+   * * @param _changedProperties changed properties with old values
+   */
+  protected update(_changedProperties: AnyObject) {}


Make this abstract

justinfagnani · 2018-08-04T01:27:04Z

src/lib/updating-element.ts

+      this._validationState = ValidationState.Valid;
+      // During finishUpdate, setting properties does trigger invalidation,
+      // and users may choose to await other state, like children being updated.
+      await this.finishUpdate(changedProps);


Doing this as:

if (this.finishUpdate !== undefined) { await this.finishUpdate(changedProps); }

will mean one less microtask in the case where there's no finishUpdate defined.

justinfagnani · 2018-08-04T01:27:12Z

src/lib/updating-element.ts

+   * `invalidate` and `updateComplete` Proimses.
+   * * @param _changedProperties changed properties with old values
+   */
+  protected async finishUpdate(_changedProperties: AnyObject) {}


Make this abstract

I did, but TypeScript doesn't seem to support an optional abstract method. Left it in so we can verify that.

Yeah, looks like it'd just be optional then, with no implementation. ie, optional => abstract.

justinfagnani · 2018-08-04T01:28:06Z

src/lib/updating-element.ts

+    // did not trigger more work).
+    if (this._validationState === ValidationState.Valid) {
+      while (this._validateResolvers.length) {
+        const resolver = this._validateResolvers.pop();


You don't need the variable:

this._validateResolvers.pop()!();

justinfagnani · 2018-08-04T01:29:20Z

src/lib/updating-element.ts

+    }
+    this._validationState = ValidationState.Invalid;
+    // Make a new validate promise and put the resolver on the stack.
+    this._validatePromise = new Promise((resolve) => this._validateResolvers.push(resolve));


Why is there a stack of resolvers? Could use some docs around it's relation to reentrant invalidate calls.

justinfagnani · 2018-08-04T01:30:47Z

src/lib/updating-element.ts

+    // Only resolve the promise if we finish in a valid state (finishUpdate
+    // did not trigger more work).
+    if (this._validationState === ValidationState.Valid) {
+      while (this._validateResolvers.length) {


Since you resolve all the Promises at once, is seems like we could just share a single Promise. Are they ever resolved separately?

Yeah, that had occurred to me as well and I forgot to clean it up. Will do that.

https://github.com/webcomponents/custom-elements/issues/167

* mark update/finishUpdate as abstract * remove stack of promises in `invalidate`

justinfagnani · 2018-08-05T23:18:51Z

README.md

 and renders declaratively using `lit-html`.

+  * **Setup properties:** LitElement supports a static `properties` getter in which element property


I'd suggest leading with a more generic description of properties:

LitElement supports observable properties which may trigger an update when set. These properties can be written in a few ways:

As class fields with the @property decorator (with links to class fields and decorators proposals?), if you're using a compiler that supports them, like TypeScript or Babel.

With a static properties getter or property.

By manually writing getters and setters

And then go into each method.

https://github.com/tc39/proposal-decorators#decorators

justinfagnani · 2018-08-05T23:19:43Z

README.md

+  * **Setup properties:** LitElement supports a static `properties` getter in which element property
+  accessors are described. For each property, an object configures settings where the options are:
+
+    * attribute: if false, do not add to observedAttributes, if true or absent, observe the


Add backticks around the property names: attribute, observedAttributes, etc.

I think the leading word after the colon should be capitalized, and each "If...` clause a sentence.

Instead of doing the camel casing automatically, why not also allow attribute: 'my-custom-name' as well, so that I can choose the mapping name that I want

This seems to be exactly what you are doing in the TS example:

@property({attribute: 'more-info', type: (value: string) => `[${value}]`})

OK, you seems to be doing exactly what I wanted, but the documentation doesn't mention that

justinfagnani · 2018-08-05T23:21:53Z

README.md

@@ -70,8 +81,8 @@ and renders declaratively using `lit-html`.
  1. Create a class that extends `LitElement`.
  1. Implement a static `properties` getter that returns the element's properties
  (which automatically become observed attributes).
-  1. Then implement a `_render(props)` method and use the element's
-current properties (props) to return a `lit-html` template result to render
+  1. Then implement a `render()` method and use the element's


I think a minimal TypeScript example should be right up top to sell things a little.

justinfagnani · 2018-08-05T23:24:07Z

README.md

+  * `finishUpdate(changedProps)` (protected): Called after element DOM has been updated and
+  before the `updateComplete` promise is resolved. The `changedProps` argument is an object
+  with keys for the changed properties pointing to their previous values. This is an
+  async function which is *awaited* before resolving the `updateComplete` promise.


Async or not is an implementation detail of a function. I'd just say it can return a Promise

justinfagnani · 2018-08-05T23:25:32Z

src/lib/render-helpers.ts

+    classInfo: {[name: string]: string|boolean|number}) {
+  const o = [];
+  for (const name in classInfo) {
+    const v = classInfo[name];


move classInfo[name] into the if condition

justinfagnani · 2018-08-06T00:14:20Z

src/lib/updating-element.ts

+ * Change function that returns true if `value` is different from `oldValue`.
+ * This method is used as the default for a property's `shouldChange` function.
+ */
+// tslint:disable-next-line no-any


using unknown should remove the need for the lint directive

justinfagnani · 2018-08-06T00:17:31Z

src/lib/updating-element.ts

+  return old !== value && (old === old || value === value);
+};
+
+enum ValidationState {


I really prefer avoiding enums and namespaces in TypeScript. They're the only non-type extensions to JS, and I think generally considered a mistake. Unless you need the bidirectional mapping of enums, using a plain object or a union type of literals usually suffices, ie:

type ValidationState = 'disabled' | 'valid' | 'invalid';

or:

const disabled = 0; const valid = 1; const invalid = 2; type ValidationState = typeof disabled | typeof valid | typeof invalid;

justinfagnani · 2018-08-06T00:22:57Z

src/lib/updating-element.ts

+   * to `fooBar` property.
+   */
+  private static _attributeToPropertyMap: AttributeMap = {};
+  /**


style nit, here and throughout: I think it's easier to read with a blank line before doc comments.

justinfagnani · 2018-08-06T00:25:02Z

src/lib/updating-element.ts

+  /**
+   * Memoized list of all class properties, including any superclass properties.
+   */
+  static _classProperties: Properties = {};


Why do you need this and properties? Can't the decorator just write to properties?

It's a memoization for efficiency so we don't need to look at the superclass properties at runtime. This is info is really frequently needed: when a property invalidates or deserializes, for example.

justinfagnani · 2018-08-06T00:27:56Z

src/lib/updating-element.ts

+    }
+    // finalize any superclasses
+    const superCtor = Object.getPrototypeOf(this);
+    if (superCtor.prototype instanceof UpdatingElement) {


Rather than an instanceof check, can we rely on the presence of the _finalized method? This would make subclassing work across multiple versions of this package.

kenchris · 2018-08-06T09:50:29Z

README.md

+
+* When the element is first connected or a property is set (e.g. `element.foo = 5`)
+  and the property's `shouldInvalidate(value, oldValue)` returns true. Then
+  * `invalidate()` tries to update the element after waiting a microtask. Then


Does regular users understand about microtasks? Like to explanation?

kenchris · 2018-08-06T09:50:58Z

README.md

+* When the element is first connected or a property is set (e.g. `element.foo = 5`)
+  and the property's `shouldInvalidate(value, oldValue)` returns true. Then
+  * `invalidate()` tries to update the element after waiting a microtask. Then
+    * `shouldUpdate(changedProps)` is called and if this returns true which it


comma before which

kenchris · 2018-08-06T09:52:04Z

demo/lit-element.html

+      get zot() { return this.getProperty('zot'); }
+
+      set zot(value) {
+        this.setProperty('zot', Number(value));


Would be nice if the example explained exactly what you are trying to accomplish here. Like why is this useful?

Probably something to cover in a getting started guide, but tweaked it a bit.

kenchris · 2018-08-06T09:57:15Z

src/lib/updating-element.ts

+  type?: AttributeProcessor|Function;
+  /**
+   * Describes if setting the property should be reflect to the attribute value.
+   * If true, then if present the `type.toAttribute` function is used to serialize


I find this English a bit hard to follow. "then if present the ... is used" - at least add a comma after "present".

An example would probably also make this more clearer, like why is this useful and when to use

kenchris · 2018-08-06T09:57:50Z

src/lib/updating-element.ts

+   * This function takes the new and oldValue and returns true if invalidation
+   * should occur. If not present, a strict identity check is used.
+   */
+  shouldInvalidate?(value: unknown, oldValue: unknown): boolean;


a motivating example on when you don't want something to invalidate would be quite useful

kenchris · 2018-08-06T10:00:56Z

src/lib/updating-element.ts

+  private _changedProps: AnyObject|null = null;
+
+  /**
+   * Node or ShadowRoot into which element DOM should be renderd. Defaults


rendered - missing e

jolleekin · 2018-08-06T13:27:00Z

The current convention is _ prefix for protected members and __ prefix for private members. However, looks like this convention is not strictly followed. Examples:

  private __isChanging: Boolean = false;
  private _root?: Element|DocumentFragment;
  _firstRendered() {}
  protected _createRoot(): Element|DocumentFragment

Also test subclass/superclass do not improperly interact.

sorvell · 2018-08-07T02:27:37Z

Reflecting attributes in the property setter does not work since Safari does not allow an element to produce attributes in the constructor. We will need to move this to update or specially handle this on first invalidate.

kenchris · 2018-08-07T08:46:53Z

README.md

-    * shouldInvalidate: optional function which should return true if setting the property
-    should cause the element to invalidate causing it to asynchronously update.
+  * **Setup properties:** LitElement supports observable properties which may trigger an
+  update when set. These properties can be written in a few ways:


indentation

kenchris · 2018-08-23T08:43:23Z

README.md

+  for calling methods on rendered elements, for example focusing an input:
+  `this.shadowRoot.querySelector('input').focus()`. The `changedProperties` argument is a Map
+  with keys for the changed properties pointing to their previous values.
+  Note, calling `super.update()` is required. Before calling `super.upadate()`,


spelling: upadate

kenchris · 2018-08-23T08:49:39Z

README.md

+      does by default:
+      * `update(changedProperties)` is called to update the element.
+        Note, setting properties inside `update()` will set their values but
+        will *not* trigger `invalidate()`. This calls


It will after calling super.update() right

kenchris · 2018-08-23T08:50:52Z

README.md

+        will *not* trigger `invalidate()`. This calls
+        * `render()` which should return a `lit-html` TemplateResult
+          (e.g. <code>html\`Hello ${world}\`</code>)
+      * `finishFirstUpdate()` is then called to do post *first* update/render tasks.


finishFirstUpdate() was also removed

justinfagnani · 2018-08-23T19:25:38Z

package.json

@@ -13,7 +13,7 @@
    "build": "tsc",
    "gen-docs": "typedoc --readme none --mode modules --excludeNotExported --excludePrivate --exclude **/*_test.ts --out ./docs/api .",
    "test": "npm run build && wct",
-    "checksize": "uglifyjs lit-element.js -mc --toplevel | gzip -9 | wc -c",
+    "checksize": "rollup -c ; rm lit-element.bundled.js",


don't you need a rollup config?

See https://github.com/Polymer/lit-html/blob/master/rollup.config.js

justinfagnani · 2018-08-23T19:26:58Z

README.md

-  of whether or not any property changes are pending.
+## Advanced: Update Lifecycle
+
+* When the element is first connected or a property is set (e.g. `element.foo = 5`)


I find the nesting here to make this visually more complicated than it is. Also the "thens", "Notes" and other connector words.

justinfagnani · 2018-08-23T19:29:17Z

src/lib/updating-element.ts

+}
+
+/**
+ * Object that describes accessors to be created on the element prototype.


super nit: You don't need phrases like "Object that", you can just start with "Describes...". Also, the second sentence doesn't describe the interface, but some other thing that uses it.

justinfagnani · 2018-08-23T19:35:24Z

src/lib/updating-element.ts

+  private static _finalized = true;
+
+  /**
+   * Memoized result of computed observedAttributes.


Why does this have to be memoized? For customElements.define it's torn off at define time and remembered by the browser.

Idea was for calls to super.observedAttributes in overrides but probably not needed. Can remove.

justinfagnani · 2018-08-23T19:38:34Z

src/lib/updating-element.ts

+    if (this.prototype.hasOwnProperty(name)) {
+      return;
+    }
+    const key = typeof name === 'symbol' ? Symbol() : `__${name}`;


Seems like the key should be a Symbol either way

Will perf test.

justinfagnani · 2018-08-23T19:42:58Z

src/lib/updating-element.ts

+   * Called when a property value is set and uses the `shouldInvalidate`
+   * option for the property if present or a strict identity check.
+   */
+  private static _propertyShouldInvalidate(value: unknown, old: unknown,


Since we don't have the property name here, I'd consider a name like _valueShouldInvalidate, as _propertyShouldInvalidate sounds like the function you'd get for a specific property (the third arg here).

justinfagnani · 2018-08-23T19:50:27Z

src/lib/updating-element.ts

+
+  /**
+   * Updates the element. By default this method reflects property values to attributes.
+   * It should be implemented to render and keep updated DOM in the element's root.


"implemented" -> "overridden"

justinfagnani · 2018-08-23T19:51:45Z

src/lit-element.ts

-   * @param props Current element properties
-   * @param changedProps Changing element properties
-   * @param prevProps Previous element properties
+   * Override which performs element rendering by calling the `render` method.


These will be the docs shown in the doc viewer. I don't think "Override which..." provides a lot of information. I'd copy a lot of the docs from UpdatingElement

justinfagnani · 2018-08-23T19:52:47Z

src/lit-element.ts

-      this.__resolveRenderComplete(true);
+  protected update(_props: PropertyValues) {
+    super.update(_props);
+    if (typeof this.render === 'function') {


A method can't both be abstract and have an implementation. For TypeScript users, they'll get an error in their IDE that they should implement, which is better because it's sooner.

justinfagnani · 2018-08-23T19:53:10Z

src/lit-element.ts

-    this.__isInvalid = true;
-    super._invalidateProperties();
-  }
+  protected firstRendered?(): void;


…ng. Fixes tests on Edge / IE.

This helps typescript users get a nice warning if they forget to implment `render`.

kevinpschaaf · 2018-08-24T00:21:58Z

src/lib/updating-element.ts

+    // Note: special case `Boolean` so users can use it as a `type`.
+    const toAttribute = options.type === Boolean ? toBooleanAttribute :
+        (options.type && (options.type as AttributeSerializer).toAttribute || String);
+    return (typeof toAttribute === 'function') ? toAttribute(value) : null;


Defaults to String, so check is unnecessary

kevinpschaaf · 2018-08-24T01:04:40Z

src/lib/updating-element.ts

+  /**
+   * Validates the element by updating it via `update`.
+   */
+  private _validate() {


"validate" to me means "check if valid or not", not "make valid"

Consider "flush" to mean "flush all queued invalidated (dirty) properties by calling update"

I really don't like "flush" as a name. It's pretty vague and doesn't relate to either the "update" or "invalidate" terminology we've used so far. "validate" was used correctly - it also means to mark as valid.

If we don't like _validate, I'd suggest something like _revalidate or _doUpdate.

kevinpschaaf · 2018-08-24T01:12:59Z

src/lib/updating-element.ts

+};
+
+const microtaskPromise = new Promise((resolve) => resolve(true));
+


Let's comment what these states are relevant for.

Also suggest changing STATE_IS_UPDATING -> STATE_IS_INVALID (or STATE_IS_DIRTY)
"Is updating" doesn't seem like good nuance for "has an invalidated, dirty property"

kevinpschaaf

LGTM

Fairly arcane, but looks like immediately invoking async function assigned to a getter that uses `super` loses `this` context on Safari 10 so working around by using Promises directly instead.

…into refactor

Add workaround for Promise timing bugs. Promise microtasks are not guaranteed to go before tasks.

Same issue as Polymer/polymer#5336.

Steven Orvell added 2 commits July 19, 2018 18:57

Refactor API (wip)

94d4e48

remove microtask lib in favor of Promise.

f8f8862

sorvell requested review from justinfagnani and kevinpschaaf July 25, 2018 00:57

justinfagnani requested changes Jul 25, 2018

View reviewed changes

graynorton reviewed Jul 27, 2018

View reviewed changes

Steven Orvell added 4 commits August 3, 2018 10:15

Update tests and Readme

dc5d931

Tweaks based on review.

5861e0e

More review tweaks.

8f83306

Lint fixes.

e18819e

justinfagnani reviewed Aug 4, 2018

View reviewed changes

Steven Orvell added 2 commits August 4, 2018 19:25

work around custom elements polyfill issue in tests

da54543

https://github.com/webcomponents/custom-elements/issues/167

Changes based on review

b39b480

* mark update/finishUpdate as abstract * remove stack of promises in `invalidate`

morbidick mentioned this pull request Aug 5, 2018

get code base DRY (attribute reflection, change notification) morbidick/bootstrap-webcomponents#1

Closed

justinfagnani requested changes Aug 6, 2018

View reviewed changes

kenchris reviewed Aug 6, 2018

View reviewed changes

Steven Orvell added 2 commits August 6, 2018 18:36

Documentation updates and type tweaks based on review.

5ef504e

Allow symbols as properties

10fdf29

Also test subclass/superclass do not improperly interact.

kenchris reviewed Aug 7, 2018

View reviewed changes

kenchris reviewed Aug 23, 2018

View reviewed changes

Steven Orvell added 2 commits August 23, 2018 10:33

Documentation fixes based on feedback.

9a9aced

Fix lint errors.

4bab118

justinfagnani approved these changes Aug 23, 2018

View reviewed changes

Steven Orvell added 7 commits August 23, 2018 13:08

Update gitignore and add rollup.config.js

88a1ad9

Don't bother memoizing observedAttributes since it's accessed once.

10edcc6

IE11 test fixes and slight change to styleString

a447927

Updates based on review.

ec02fd8

Minor doc fixes

b77ee89

invalidate waits for the previous update to complete before advanci…

b0c7428

…ng. Fixes tests on Edge / IE.

Make render abstract

9341ae2

This helps typescript users get a nice warning if they forget to implment `render`.

kevinpschaaf reviewed Aug 24, 2018

View reviewed changes

Rename flag based on review

d3a781b

kevinpschaaf requested changes Aug 24, 2018

View reviewed changes

Steven Orvell added 2 commits August 23, 2018 18:28

Renaming based on feedback

af1c542

Remove unnecessary check

e9d400e

kevinpschaaf approved these changes Aug 24, 2018

View reviewed changes

Steven Orvell and others added 9 commits August 23, 2018 18:51

Bump version

bb6d73d

Bump lit-html constraint to require 0.11.0-dev.3 (#151)

55bc308

Bump version to 0.6.0-dev.5

b611732

Fix tests on Safari 10

d11ba45

Fairly arcane, but looks like immediately invoking async function assigned to a getter that uses `super` loses `this` context on Safari 10 so working around by using Promises directly instead.

Merge branch 'refactor' of https://github.com/PolymerLabs/polymer-lit …

a85f4bb

…into refactor

Fix tests on Safari 9

c312464

Add workaround for Promise timing bugs. Promise microtasks are not guaranteed to go before tasks.

Now fix tests on Edge 17

84180cd

Update Safari 11 version to test

49cc74c

Avoid Firefox timeout issue on Travis by testing on Sauce

ffbfead

Same issue as Polymer/polymer#5336.

sorvell merged commit c191c9a into master Aug 24, 2018

sorvell deleted the refactor branch August 24, 2018 19:10

		and renders declaratively using `lit-html`.

		* Setup properties: LitElement supports a static `properties` getter in which element property

		};

		const microtaskPromise = new Promise((resolve) => resolve(true));

Refine API and refactor #132

Refine API and refactor #132

Conversation

sorvell commented Jul 25, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

graynorton left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rickcnagy commented Jul 27, 2018

sorvell commented Aug 4, 2018

justinfagnani commented Aug 4, 2018

justinfagnani left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kenchris Aug 6, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kenchris Aug 6, 2018 •

edited

Loading