[page lifecycle series] relocating base.Init()


I want to keep the order of initialization from what was the case in WebForms with its page lifecycle. This meaning that the code of the override is executed last in the hierarchy.

I saw that this arrangement works:
instead of leaving it like default:

What do you think?

That makes sense. It doesn’t matter to DotVVM how you do it, DotvvmViewModelBase.Init is empty. The Init/Load/PreRender of child view models is always invoked after the parent

So my understanding is correct that,

in the case where I don’t have a second level override over Init() (override Init() in VM B deriving from A that also has override and derives from DotvvmViewModelBase),

changing return base.Init() (which you say is empty) to ‘await base.Init()’ and placing it at the start of method body does in fact not effect any change in what code runs when.

Is this future proof? (I ask this because I got burnt with WebForms on various scenarios where nested calls of lifecycle handlers of a given single event like Init, hid various silent bugs, hard to pin point, lost in the woods of nested UserControls and their own lifecycles)

Future proof against us adding something to the base.Init()? Yes. Half of the users don’t even call the base.Init, because it’s not needed now. We can’t add anything to the base, except maybe optimizing how we create the completed task :slight_smile:

You can still obviously burn yourself with your own inheritance hierarchies

1 Like