Revisit RemoteRenderer deriving from HtmlRenderer

[pranavkm]

Feels like we may need to think this through.

[javiercn]

Can you elaborate?

[SteveSandersonMS]

I'd be very happy for us to revisit the arrangement of our Renderer family tree altogether! From a comment elsewhere:

I'm becoming quite concerned about the state of Renderer.cs. Not exclusively because of this PR, but because of a series of changes that have stacked up over time. Apart from just being a long file, it has so many intricate behaviors (some managed based on internal mutable state), and lots of assumptions about what things happen synchronously versus asynchronously. There's so much coupling between the inner workings of the Renderer base class and its subclasses, especially when making a bunch more stuff protected in this PR.

Although it's possible that it's currently bug-free in all our subclasses, it's getting really hard to reason about, and I think eventually this is going to burn us. [...] we need to start considering extensions to the Renderer base class as problematic and possibly needing a broader refactor first.

I'd really like to see a simpler base class for the core-most logic. Perhaps this could tie in with restructuring where "remote" and "prerendering" concerns live.

[javiercn]

@SteveSandersonMS I think I agree with you.
IMO we could break the functionality into 3 different pieces.
ComponentStateManager -> Handles the component state trees
RenderQueue -> Handles the rendering process and when to update the display.
Renderer -> Sits at the top and coordinates the two of them. Provides a couple of protected virtual methods:

• CreateRenderQueue
• CreateStateManager

That calls to initialize them.

• Renderer dispatches most of the functionality to the state manager and the RenderQueue

[SteveSandersonMS]

Maybe! I'd be interested in trying to break down why the current code structure is inadequate, what concerns are intermingled, and what would have to be true about different designs to make things clearer while handling all our use cases.

[pranavkm]

Looks like this was addressed as part of #12996. Closing since the original intent of this issue is resolved.