Closed kouts closed 6 years ago
This is actually an intentional decision from before my time. I believe the original reasoning was that instances are already constructing when they're created, so there's no reason to fire a construct too. Components and on
events still fire construct because that's the only hook available for a component and on
events are inherited and thus can't skip it.
Should construct be adjusted to fire for new
ed instances?
I'm confused. I would also expect above example work in the same way the following one:
let ractive = new Ractive({
el: '#main',
template: '{{text}}',
data: {
text: "Hello!"
},
on: {
construct: function(){
alert('this construct works')
},
init: function(){
alert('this init works too')
}
},
onconstruct: function(){
alert('onconstruct fired');
},
oninit: function(){
alert('oninit fired');
}
});
I think if both init
hooks work, then both construct
hooks should work too.
I think I agree. I was just explaining the original logic of there's no need for onconstruct
for an instance init because you're already sitting at the construct
phase. Effectively new (class SomeClass() { constructor() { /* effectively onconstruct */ } })()
.
because you're already sitting at the construct phase
I was not clear if I understood correctly, but yes, now I got it.
Description:
onconstruct event does not fire as expected
Versions affected:
0.10.9
Platforms affected:
Browsers
Reproduction:
Playground link