Is calling Task.Yield() in OnInitializedAsync() a safe way to get @ref= variables populated?

[DavidThielen]

Hi all;

At present, the way to get any @ref= variable declared in a component reference in the razor page is to call Task.Yield() in OnInitializedAsync(). When it returns from the Yield(), all of the @ref variables are now set. So as of today, this works.

One experienced Blazor developer I respect says this is supported and will work going forward and as such, can be depended on. A second experienced Blazor developer I also support a lot says this is just how Blazor works today, it may not work tomorrow, and all code needed to reference an @ref should go in OnAfterRenderAsync().

So my question is, can I depend on calling Task.Yield() in OnInitializedAsync() to populate all @ref variables? Or should I move that code to OnAfterRenderAsync()? I figure if that stops working there's going to be a lot of Blazor apps breaking. But breaking changes like that happen and best as I can find, there is no promise that Task.Yield() will accomplish anything.

thanks - dave

[DavidThielen]

With no guidance from the Blazor developers I've decided to first access the @ref variables in OnAfterRenderAsync(). I know that's safe and depending on Task.Yield() strikes me as fragile.

[En3Tho]

I am not from the blazor team but it does seem like relying on a some kind of context switch call to force other things to do their initialization first is not the way. It awfully feels like an implementation detail indeed or something might not work all the time etc.

Blazor has proper lifecycle events/stages that are properly documented, will be supported etc. And using the right one is always a better choice.

What is the need of using refs in OnInitialized in the first place?

[javiercn]

Nope.

It's only ever safe to access ElementReference instances within OnAfterRender|Async