LifeCycle events order of nested custom elements inconsistent across Chrome and Firefox

[AndyOGo]

LifeCycle events order of nested custom elements inconsistent across Chrome and Firefox

[AndyOGo]

@WebReflection
I refactored our whole codebase using your awesome polyfill, and I wanted to say thank you and sorry for the noise.
I had to wait quite some time to get it all reviewed, but it really works pretty well, to say zero problems at least.

It lays the base to extend built-in tables for us👍
We decided to link and recommend your solution in our readme:
Repo (beta): https://github.com/axa-ch/patterns-library
Demo (beta): https://axa-ch.github.io/patterns-library/

[WebReflection]

You cannot have attributes within the constructor, this is a native lifecycle issue that doesn't reflect in the polyfill (and it won't).

You are not seeing all the errors Chrome triggers in the console.

Once you stop using the id which is also invalid because IIRC it cannot contain a number at its beginning, the polyfill and the native works as expected: connectedCallback is always triggered after init and there are no issues whatsoever.

The initialization of a custom element is problematic, and requires a lot of knowledge that I won't explain in here, but I can suggest you to use html-parsed-element as base class instead of your in-house one.

There are links there about what are the various issues in injecting nodes or adding attributes during the constructor time, which results in: you can't, you should't, don't do that.

As summary, if you use _id instead of an attribute in your pen, all is good.

https://codepen.io/WebReflection/pen/jeXBQQ?editors=0010#0

P.S. it is not this project intention to simulate 1:1 the order, as long as it grants a reliable and standard lifecycle per each component. If you file a bug about that layout being different, it will be ignored because it's not needed to be identical, it's a polyfill and its workarounds might be slightly different from the native thing. That's true for every polyfill, this one is too rock-solid / battle tested to be changed for not compelling reasons.

[AndyOGo]

Damn, you are right, that was my mistake, can't set DOM properties of related HTML attributes.

I updated it to use this._id 👍

So I will dig deeper, because one thing is still weird.
Our current code base uses https://github.com/webcomponents/custom-elements polyfill and works in Firefox.
I just replaced it with your polyfill and everything is broken in Firefox. I will double check if I made a mistake and will check the instructions from your readme again 🤔

[WebReflection]

You cannot just replace it with my polyfill, you need to at least address the constructor which is not patched/same in that poly. Other things are also not the same.

Just please consider this one has been around for years and it has 0 issues for a reason: it's really battle tested and it really targets all those devices mentioned in the README.

This is just so maybe before opening bugs here you should be sure whatever you are doing makes sense and works at least in native Chrome, I wouldn't care less about the other poly.

Thanks for your understanding.

[AndyOGo]

I see. Hope I find what I'm missing. Thank you very much for your time.

[AndyOGo]

Alright, I re-studied your readme, checked all source files and I use the suggested init workaround everywhere.

We use higher-oder-classes to add various functionality to our custom elements like updates, re-rendering, contexts to other custom elements, etc.

Interestingly all I changed works in Chrome, but is broken with Firefox which needs the polyfill.

Here is what I did with our base component:

import withUpdate from './hocs/with-update';

class BaseComponent extends HTMLElement {
  constructor(self) {
    // eslint-disable-next-line no-param-reassign
    self = super(self);

    self.init();

    return self;
  }

  init() {
    this._id = getId(this.nodeName);
    this._initialised = true;
  }
}

export default withUpdateHOC(withUpdateHOC)

All other components extend from this and no one implements any other constructor.
We extends the custom elements node with various _ prefixed functionalities. But those aren'T available within the connectedCallback(), like:

const withUpdateHOC = (Base) =>
class WithUpdate extends Base {
  init() {
    super.init();
   
    this._foo = 'not available in connectedCallback :('
  }

  connectedCallback() {
    super.connectedCallback()

    this._foo // -> undefined
  }
}

[WebReflection]

I've no idea what export default withUpdateHOC(withUpdateHOC) means/does/produces/patches

[WebReflection]

also, your base class doesn't have a connectedCallback so without knowing what your withUpdate does I cannot help.

Just try to imagine if you drop your withUpdate thing everything works ...

[WebReflection]

last, but not least, I'm fairly sure you are transpiling code which might as well be the cause of your issues.

Use Babel 7 which included my patch to transpile properly classes, TypeScript and Babel 6 are plain broken with that, as example.

I've finished ideas on what's wrong with your code until further details.

[WebReflection]

I'm fairly sure you are transpiling code which might as well be the cause of your issues.

how would you know that? write the following and tell me what's the result:

class List extends Array {
    constructor(...args) {
        const self = super();
        self.push(...args);
        return self;
    }
}

console.log(new List instanceof List);

The expected result is true, I might bet your built code would show false like TypeScript does when targeting ES5.

Babel 6 used to have the same issue.

[AndyOGo]

Thank you. You are right, we transpile our code.
I will get back too you with above transpile result.

[WebReflection]

So, if you transpile with TypeScript, either target ES2015 or drop it, because TypeScript has many issues targeting ES5 (classes in primis, but also template literals are broken, and much more).

If you are using Babel 6, try using babel-plugin-transform-builtin-classes which is basically the same patch that landed in Babel 7

[WebReflection]

Alternative keep this polyfill and the base class out of your bundling 'cause it looks like your bundling is the source of the issue.

[AndyOGo]

Yes we use Babel 6, actually we use already babel-plugin-transform-custom-element-classes.
I will try the other one.

[AndyOGo]

Awesome, Firefox works now as expected:)
Thank you a lot, you are an awesome dude man.

This was the problem since my first issue, sorry for my wrong reports...

I also removed the other babel plugin, which we used to make V1 class syntax work in non ESnext browsers.

But I still need to find out what went wrong with the context of my class methods 🤔

[WebReflection]

But I still need to find out what went wrong with the context of my class methods

it wasn't the one returned by the super, it was just a duplicated instance

glad you solved

[AndyOGo]

I figured that too, but don't which code point causes this.

Well i would say you solved it👍

[AndyOGo]

Ahh it just came into my mind, any value which is returned from a constructor function becones the context.

I would have never thought that babel didn't take care of that🤔

Anyway now i know where my second instance comes from