Aspnetcore.docs: RenderTreeBuilder coverage feedback

[guardrex]

@Lupusa87 commented on https://github.com/aspnet/Docs/pull/11016 ...

I am sorry but I don't agree here in lot of things.
It will be hard to explain but I will try.

I think we should not hide and put behind this great approach to build components dynamically.
Building dynamic components is strength of blazor which makes it powerful tech.

There is a question? Can we do everything what we need using both approaches, with razor pages and with buildrendertree?
I think no and name dynamic is relevant here.

In razor pages we can use if, switch to adapt UI on parameters/state but it is still static at this point, when in code behind we render completely UI as we need and it can be 100% depended on code logic.

For example my SvgHelper which is separated blazor lib (published on nuget) is receiving builder as parameter and adding tags based on what developer did with c# svg classes.
Can you do same in razor pages? No.

This approach is dynamic because everything is generated based on provided logic and methods (internal or external) can return pieces of UI and together build whole component body.

@rynowak Had idea to make same for razor pages which will be great but is not available yet.
https://twitter.com/aVerySpicyBoi/status/1104110920102375424

If someone likes razor way and thinks it is enough and finds it simpler, no problem, they can do it as they like.
But it does not give too much coding sugar and doing rendering in c# can be preferred way to many developers, especially when doing blazor native components, blazor libs, tools and bit complex apps.

I can agree that this is bit advanced scenario but not too much and it should be considered and recommended as general development style.

There is nothing hard and highly advanced to use buildrendertree even for entry level developer, for bit experienced devs it should be trivial thing.

Warning that there can be unclosed tag is not relevant because same is still problem in razor page because compiler is not detecting it and any other html syntax errors.
Unclosed tag or any similar issue we detect and solve when build/test our apps and can not be reason not to chose buildrendertree way.

Hard code sequence numbers is not possible because as said already in c# class we can realize complex logic based on parameters/state and generate huge UI so it is impossible to hard code sequence, if it is problem it should be solved with another way rather than telling developers don't do this.
Dynamic nature makes no sense hard code recommendation.

Using razor pages should be recommended in very simple cases, leading way should be c# way.
It should be well documented, explained and supported with examples.

Blazor is going to be standard way to build web applications at least for .net developers and it should not concentrate on toys like razor page, most developers will skip it in most apps which are bit complex than counter sample, we expect in future to see large and wide range web apps ported or build in blazor, this naturally requires buildrendertree.

People with serious intentions to blazor should see how powerful mechanism do they have in their hands.

Components are basic concept for blazor and option to build them dynamically and unlimited is what we should tell everyone and make it mainstream.

Here you are people whom I hard imagine to teach something but in this case I can't not to protect better approach and not try to push it forward.

I am sorry if my comment is confusing or not clear, it is hard to do better because of my limited English.

Please consider that I am facing this situations each day and I share my thoughts with you as one blazor dev, you can ask another devs too.
People who work close to components will have fast answer on this issue.

@Andrzej-W commented ...

I have to say that @Lupusa87 is 100% right. If you want to create complex and reusable component it is sometimes impossible to do it in standard way (in .razor file). Even if it is possible it is often easier to do it in code. As @Lupusa87 said it have to be well documented and that is the only problem.

Nobody likes something like this in the doc:

When creating components dynamically, always hardcode the sequence number. Do not generate the number using any sort of calculation or counter.

The question immediately arises: what is wrong with sequence++ statement?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 11a64802-62dc-40e0-034f-fcee55f31d4e
• Version Independent ID: 038d7f90-aa71-a35c-cee9-c8543403cfd7
• Content: Create and use Razor Components
• Content Source: aspnetcore/razor-components/components.md
• Product: aspnet-core
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

From @SteveSandersonMS in https://github.com/aspnet/Docs/pull/11016#issuecomment-476779607 ...

Sequence numbers are what the diff algorithm used to produce minimal diffs quickly. It can see where loops and branches are in your code.

If you do seq++, you are providing literally no useful information. We still make it work, but the efficiency will be nowhere near as good. This is one of the great advantages of writing .razor files - the compiler deals with this for you automatically.

[SQL-MisterMagoo]

@SteveSandersonMS so, are you saying that a simple example like this

int c = 0;
builder.OpenElement(c++, "drag-item");
builder.AddAttribute(c++, "id", ID);
builder.CloseElement();

Will this be a performance problem?

[Lupusa87]

@SteveSandersonMS

After your comment motivation behind sequence number is clear but in case we need buildrendertree and dynamic rendered content is there way to track sequence numbers internally without providing it as parameter?

[SteveSandersonMS]

Since this keeps coming up, I've now written up a detailed explanation with examples here: https://gist.github.com/SteveSandersonMS/ec232992c2446ab9a0059dd0fbc5d0c3

[SQL-MisterMagoo]

@SteveSandersonMS
Thank you for writing that, it's much appreciated.
It seems to be a problem only related to when unnecessary changes are made to the sequence of a region. So with this information we can ensure any code that requires use of manually coded components observes good practice.

[Lupusa87]

@SteveSandersonMS
Thank you, it is much clear now.

I can't stop using buildrendertree because I found it very convenient and powerful, so all I will do now is hard coding current line numbers in buildrendertree methods after finish to write component code.

It is sad to know that this procedure should be done again after any changes in code because line numbers will be changed, but not big tragedy before better times :)

OpenRegion/CloseRegion is good advise, it can be used in injected methods which itself have not any loops or conditionals, so numbering once will be enough and not requires line numbers anymore, thank you.

This was helpful but there are some component related bugs and missing features I am going to raise issues for.

Hope your gist will be used in docs and my main concern not to cover buildrendertree with razor will be considered in future.

[guardrex]

Hope your gist will be used in docs

When @danroth27 triages this, he'll let us know. We can add content to the existing section from the Gist or merely add a line at the end of that section ("For more information, see ...") and link to the Gist.