Re: [w3c/webcomponents] The custom element state when constructor thrown (#533)

It seems to me like preventing the constructor from ever running again is not the best thing to do. What if some error state elsewhere in the app causes the constructor to fail, and then that error state goes away, in which case the element should come alive again the next time it is used.

Or, does this explicitly prevent the constructor from running twice on a specific element such that if I removed `<some-element>` then attached a new `<some-element>` then the new one will have it's constructor called?

```js
class SomeElement extends HTMLElement {
  constructor() {
    if (!someStateInTheApp) {
      throw SomeError('...')
    }

    // ...
  }
}
```

Would the best practice for a library that writes a constructor like that be to encourage the failed element to be removed and for the user to try again by adding a new element?

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/533#issuecomment-238043384

Received on Saturday, 6 August 2016 19:05:07 UTC