Blazor - OnAfterRender sequence

[harleydk]

Describe the bug

With a page which has a 'main' component in it, referencing sub-components, the main-components onAfterRender is called before the sub-components onAfterRender.
Deliberately not using the async versions.

Expected behavior

I expected the sub-components onAfterRender to run before the the main-component's onAfterRender. I wanted the sub-components to report back before the main-component, like Angular's ngAfterViewInit does it.

To Reproduce

Steps to reproduce the behavior:

1. Using the latest .NET Core 3 preview with Latest VS 2019 Preview.
2. Start a new Blazor client-side project
3. Create a main-component which overrides the onAfterRender and writes a line to the console.
4. Create a sub-component which overrides the onAfterRender and writes a line to the console.
5. Create a page which has a main-component which holds a couple of sub-components inside of it.
6. The main-component's onAfterRender will run before the sub-component's same.

ComponentPage.razor.txt
SubComponent.razor.txt
MainComponent.razor.txt

[SteveSandersonMS]

Could you clarify why this makes a difference in your application? What are you doing that doesn't work because of this ordering?

[harleydk]

Thanks @SteveSandersonMS for getting back to me,

I'm testing Blazor by making a puzzle game. Within a main-component I have N sub-components which, after their initial render, will perform some actions (random positioning, some such). Only after that's done would I like the main-component to activate its onAfterRender and do some reporting back to the player.

Practical implementation aside - maybe there're better ways of going about that particular example.

The gist of it, it messes with my assumption of how I - personally - would logically expect something that's called onAfterRender to work. How can a parent-component reasonably conclude its own rendering before any of its child-components were done doing their own rendering.

[SteveSandersonMS]

Within a main-component I have N sub-components which, after their initial render, will perform some actions (random positioning, some such). Only after that's done would I like the main-component to activate its onAfterRender and do some reporting back to the player.

I'm not sure why you're tying all this stuff to rendering. Is it because you want to know when to run some JS interop calls?

I think you'll find this all much simpler if you factor out your game's business logic from the components that render the UI. If your game logic is a separate set of classes that do their thing using whatever C# patterns you like, you can then also use Blazor to render a UI for that.

Failing that, if you really do want a parent component to get notified when a child has done something, I'd recommend having the parent pass a callback to the child so the child can invoke it when it has done that thing.

How can a parent-component reasonably conclude its own rendering before any of its child-components were done doing their own rendering.

It doesn't fit into the model in general to imagine that children always complete rendering before their parent. The component model at its core is very unopinionated and doesn't have any rule like "all components must render once they first get instantiated". Technically a component can choose not to render itself at all, or can wait arbitrarily before doing so. The parent doesn't know in general what its children choose to do.

[harleydk]

I'm not sure why you're tying all this stuff to rendering. Is it because you want to know when to run some JS interop calls?

That's it. My onAfterRender allows a few third party javascript libraries to do shiny graphical things on some of the elements. I can't bring the game to a start until that's done.

I think you'll find this all much simpler if you factor out your game's business logic from the components that render the UI. If your game logic is a separate set of classes that do their thing using whatever C# patterns you like, you can then also use Blazor to render a UI for that.

Agreed. I keep only presentation logic in the UI components.

It doesn't fit into the model in general to imagine that children always complete rendering before their parent. The component model at its core is very unopinionated and doesn't have any rule like "all components must render once they first get instantiated". Technically a component can choose not to render itself at all, or can wait arbitrarily before doing so. The parent doesn't know in general what its children choose to do.

I see. Thank for clearing that up. The small game is actually an Angular application I'm trying to port, but I appreciate the life-cycles aren't compatible; Angular's are certainly more opinionated, to borrow your term, than Blazor's. Pros and cons.

I'll go ahead and close this. Thanks for your time.