AnsweredAssumed Answered

Different widget initialisation API 4.16 vs 4.15?

Question asked by FreddyBroring on Jul 22, 2020

I am in the process of updating our apps from API 4.15 to the new API 4.16. After removing all amd-dependency comments and removing declared() from the widget subclassing (and some other things...), it compiles and builds fine now.

 

But when I test the application I see an important difference in the widget initialisation: with 4.15 the postInitialize is executed right after the constructor has been executed (as described in de documentation).

In the 4.16 API it looks like the postInitialize is run right before the widget is going to be rendered. This makes a huge difference if you are relying on widget properties that are initialised in de postInitialize method.

 

For example:

 

@4.15

@subclass('test.MyWidget')
class MyWidget extends declared(Widget) {
@property()
public customProp;

constructor(params: any) {
   super(params);
}

postInitialize() {
   this.customProp = 'whatever';
}

render() {
   return <div>`CustomProp ${this.customProp}`</div>;
}
}

@4.16
@subclass('test.MyWidget')
class MyWidget extends Widget {
@property()
public customProp;

constructor(params: any) {
   super(params);
}

postInitialize() {
   this.customProp = 'whatever';
}

render() {
   return <div>`CustomProp ${this.customProp}`</div>;
}
}

Then create an instance in the calling class:

 

 

const myWidget = new MyWidget({container: 'myDiv'});
const proppy = myWidget.customProp;
// 4.15: 'whatever'
// 4.16: undefined

 

 

It's a very simple example but it's just to describe the problem. The problem becomes more obvious when you create (sub)widgets in widgets.


We make use a lot of initialisation in the postInitialize so this has lots of impact on our code.

 

So my questions are: Are we using the postInitialize in a wrong way and what is the best way to solve this problem? 

 

Rene Rubalcava?

Outcomes