Blazor source, a little advice needed.

[footysteve]

Hi

I'm looking into seo with Blazor. At the moment google & co don't appear to work well with WebAssembly apps.

Looked at some seo related posts here, #5464 for example. I think, maybe, I might have a practical and efficient solution though I'm still getting to know the internals of wasm/mono.

I've downloaded and built Blazor and have been familiarising myself with the codebase though I haven't been able to step through code yet as I need to change the language services extension version numbers or uninstall the extension I guess.

It's a big project, lots of code so I wondered if someone might be able to give me a little info about, or point me to a document that details the process flow of Blazor, what happens under he hood. I'm looking for the point in code where a page has been constructed but not yet packed ready for download.

Thanks
Steve

PS. Sorry the image isn't showing up, still figuring out GitHub, clicking the link shows the image.

[SteveSandersonMS]

For the WebAssembly hosting model, the flow is roughly:

• Client-side JS code starts up the Mono runtime and executes the program entrypoint
• This goes through a setup process calling your ConfigureServices, Configure, etc., and then internally instantiates a BrowserRenderer and tells it to add one (or more) of your app's components
• The BrowserRenderer:
  • Gives an ID to the component and uses JS interop to notify the JS-side code that a component with a certain ID should be associated with a certain DOM element selector
  • Instantiates the component, and starts its lifecycle, passing any params to it (which is an empty set in the case of the root component)
• The component's lifecycle
  • Calls its Init, InitAsync, etc.
  • Asks for itself to be rendered (e.g., in the BlazorComponent base class, SetParams calls StateHasChanged, which issues the request to be rendered)
• [A] When the renderer receives a request for a component to be rendered, it adds it to the current render queue, or starts a new one if there isn't one in progress. Then for each entry in the render queue,
  • Calls the component's Render to populate a render tree
  • Diffs the output against the previous one for that component, adding the diff to the output batch
• At the end of the queue, the output batch is passed to the JS-side code (see UpdateDisplay in BrowserRenderer), where the JS-side code uses it to update the DOM
• Later, when some event handler is triggered, this sends a message to the component via JS interop. The component runs whatever logic it wants, then requests itself to be re-rendered. Go to [A] above.

I'm looking for the point in code where a page has been constructed but not yet packed ready for download.

Yes, that would be when the output batch has been constructed and needs to be sent to the JS-side code, i.e., UpdateDisplay on the renderer.

I think, maybe, I might have a practical and efficient solution though I'm still getting to know the internals of wasm/mono.

Definitely very happy to take a contribution for prerendering - thanks for your interest. Please note this has been attempted before (#785) so you might want to check the approach used there. As we commented on dotnet/blazor#785, getting this baked in will require some nontrivial design, so if your goal is to achieve this in the short term (next couple of months, say), it would be best to find ways to structure it as an external package rather than something integrated into this repo so that it can be published soon. Please let us know if you think any additional extensibility points would be needed to enable that!

Closing as hopefully the question is answered.

[footysteve]

Brilliant thanks for such detailed info, Steve, appreciated. I'll see what I can come up with. Thanks!