Simplified Blazor Component Model to reduce overhead in lists

[neufel42]

I would love to see a simplified Blazor Component Model that is just basically a RenderFragment. I have a few lists where each row of the list is a set of components. These are basic components just so I don't have to have 10 lines of html code for each column. These lists when done with components get really slow really fast. (25 - 50 rows and it almost becomes unusable). To work around this I use RenderFragments and it works well and makes it speedy again. However, I then lose the nice readability of using a custom tag for each item. Instead I find myself injecting code within my razor component page.

// This just returns a RenderFragment
@MyComponent.RenderComponent(new MyComponentOptions()
{
Param1="some `Parameter",
Param2="some Parameter",
Param3="some Parameter",
})

instead of:
// Can not use simple components that just basically render html because they make the application way too slow
<MyComponent
Param1="some Parameter",
Param2="some Parameter",
Param3="some Parameter" >

[mrpmorris]

Are you using @key ?

[neufel42]

Accessing or updating the DOM for a certain element isn't the problem. Just rendering that list get's painfully slow really fast. I have discovered I can speed things up by setting ShouldRender to false. Obviously this isn't ideal but all I want to do is have html wrapped in a component. Still doing more tests to see if this speeds up my components enough to make them useful

[mrpmorris]

So, is that a "yes"? :)

[javiercn]

@neufel42 thanks for contacting us.

Could you provide some more details as well as confirmation of whether or not you are using @key as @mrpmorris was asking?

@SteveSandersonMS thoughts?

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.

[SteveSandersonMS]

Interesting idea, and closely matches some possibilities the team speculated about in the past.

Personally I think this is a worthwhile thing to consider. I'd imagine some kind of directive like @inlinecomponent you can put at the top of your .razor file that means:

• Instead of generating a class that inherits from ComponentBase, we inherit from some other new base class like StatelessComponentBase which doesn't have any lifecycle methods at all
• You're not allowed to have any code in the @code block except for [Parameter] properties that are simple { get; set; } auto properties
• You can't have any other directives like @inject that participate in the component lifetime or @inherits or @implements. Or keep it simple: you just can't have any other directives at all. Maybe @using and @namespace and @preservewhitespace are OK.
• When a parent component tries to include this component, the renderer:
  • Instantiates your component type as normal and uses its default parameter-assigning logic
  • Calls its BuildRenderTree inline in the parent component's rendering flow, so it's not a separate component at all as far as the runtime and diffing is concerned - it's just like invoking a __builder method
  • On subsequent renders, we continue to preserve the component instance and update its parameters as if it was a normal component, and then invoke its BuildRenderTree inline again. We do not check whether the parameters are unchanged, since we have to re-render it regardless.

The part of this I like least is trying to detect whether there is any code in @code except for the parameters, or whether the parameters have getters/setters. Maybe that's best done via an analyzer rather than a Razor compiler pass.

Also I'm not keen on how it would make the Razor compiler a bunch more complicated, because these components will violate its assumptions is various places.

Another drawback is that it will be quite hard for developers to make sense of these restrictions, and it's still not quite as performant as a static __builder method (because it has to instantiate the component and use the render tree to pass parameters, instead of just doing a native C# method call). So perhaps we should focus on making __builder methods nicer to use instead of doing this.

[SteveSandersonMS]

Another, perhaps bolder design, would be expanding the set of things that the Razor compiler can consider to be "components" to include __builder methods. That is, it detects __builder methods via some annotations or conventions, and has them show up in intellisense as a component. The compiler output for including that component would be "call the __builder method directly", passing the parameters as plain C# method parameters.

That's way better really.

I'm unsure how practical it is to discover these __builder methods inside the Razor compiler. Do we have to walk literally every method on every type in the compilation? Also it only helps the component consumer have a better experience - it doesn't help the component author. And my sense currently is that consuming a __builder method isn't the awkward part about them - it's the authoring that is.