Rendering issue with a component and initial render

[alankila]

Hello,

for some reason I'm observing a bug where the first, initial render of a component defined like this:

    export default class MyComponent extends Ember.Component {
        foo = true;
        bar = false;
    }

etc. renders as if foo is set to true, and bar is set to false, even when the template binds the variables to different values, such as if I do this:

{{my-component foo=false bar=true}}

If something causes the component to re-render, e.g. I might have a computed property on it that gets updated, then it seems to get all the right values afterwards. I think the cause is that the defaults set by the bindings get destroyed by the object's TypeScript constructor, which overwrites those properties, and that breaks the bindings.

A more verbose class definition such as this:

    export default class MyComponent extends Ember.Component {
        foo?: boolean;
        bar?: boolean;

        constructor() {
            super();
            if (this.foo === undefined) {
                this.foo = true;
            }
            if (this.bar === undefined) {
                this.bar = false;
            }
        }
    }

shows no issue, because it's careful to avoid overwriting whatever is already in foo and bar. Of course, from an OO theoretical point of view what Ember is doing here is nonsense because the properties defined in this class can't possibly have any values before the object's constructor is ready with them. The constructor is supposed to have a private copy of the object first, and only after it returns, the object is accessible from elsewhere. In this case, I think that the object gets constructed with these property values already grandfathered in, which is unusual from OO point of view.

A consequence of doing this workaround is that every use of this.get("foo") must now deal with possibility that the value is undefined, even when it never is, really. This mostly concerns TS compiler options such as strictNullChecks and strictPropertyInitialization. Leaving out the ? in foo? makes TypeScript compiler complain that this.foo is used before it is initialized, so that's not good either.

Would it be possible to defer setting up Ember's bindings somehow that TS constructor gets run first, and then any bindings would get written by Ember to the object?

I am using ember 3.0.0 and ember-cli-typescript 1.1.5 with typescript 2.7.2.

[chriskrycho]

I'll answer your last question first: it's definitely not possible for this addon to rewrite Ember internals! Also along those lines note that TypeScript isn't doing anything special here; you'll see the exact same things if you use classes without TS.

This behavior is surprising mostly because of how the legacy Ember Object model interacts with class definitions.

The first thing to understand is the order in which things run during setup (a function of how things are installed on the prototype by the legacy Ember Object model):

import Component from '@ember/component';

export default class MyComponent extends Component.extend({
  init() {
    this._super(...arguments);
    console.log('this runs first');
  }
}) {
  init() {
    super.init(...arguments);
    console.log('this runs second');
  }

  constructor() {
    super();
    console.log('this runs last');
  }
}

The second thing to understand is what class property initialization is actually doing. These two are identical:

// property initializer
class MyClass extends SomeOtherClass {
  foo = true;
  bar: string;

  constructor() {
    super();
    this.bar = 'wahoo';
  }
}

// constructor initializer
class MyClass extends SomeOtherClass {
  foo: boolean;
  bar: string;

  constructor() {
    super();
    this.foo = true;
    this.bar = 'wahoo';
  }
}

And in fact, if you look at how they're compiled, you'll see that those two generate precisely the same output.

The combination of these (and especially the latter) are why you're seeing what you are. By the time that a constructor runs, the values have already been set on the instance, and you're overriding them.

The way we handle this in our own app is:

import Component from '@ember/component';
import { defaultTo } from 'lodash';

export default class MyComponent extends Component {
  foo: boolean = defaultTo(this.foo, true);
  // everything else
}

This gives us the desired behavior.

As regards an OO-theoretical point of view, that might be true if you're talking about Java or C#, but it's certainly not true of JavaScript. Protototypal inheritance means things can totally have values (and they often do!) before the constructor for a given class runs. class is just sugar for prototypal inheritance, not bringing classical inheritance to JS.

[chriskrycho]

I've closed the issue because this isn't a bug but literally a feature of ES6 classes, but feel free to ask further questions etc. here to clarify. You may also find this blog post helpful, as I discussed it with a lot more detail and nuance there.

[alankila]

I thank you for the in-depth commentary. I wish I had hit your blog post first, as it covered every question I had, pretty much. I have now adopted the defaultTo approach to solve the problem of providing default values to properties that may be bound elsewhere. I would be grateful if you expanded the top-level Component example to include it because that would have immediately solved my problem.

[jacobq]

FWIW, although the longer articles & TS handbook together probably cover this, I keep coming back here to refer to this comment. It might be worthwhile to have something like this in the docs.

[chriskrycho]

I added a note to that effect in the overarching issue I've created for tracking the docs restructure/improvement/etc. we'll be doing over the next while.

[oliverlangan]

In place of the defaultTo solution, @pzuraq pointed me to the @ember-decorators/argument package which allows default values to be provided without overriding a passed-in value. Check it out!

[chriskrycho]

While that works in basic JS, per many conversations with @pzuraq my understanding is it does not work with TypeScript today.

[pzuraq]

Yeah, this is true unfortunately. Typescript decorators currently do not give us any way to access the value of a field at definition time 😕Hopefully we'll be able to figure out a way to use the babel transforms instead of the TS transforms with Babel 7