Aspnetcore: Avoid blazor-component wrappers for components that supply exactly one top-level node

Created on 26 Mar 2018  路  8Comments  路  Source: dotnet/aspnetcore

Looking at the Elements output in chrome I see several blazor-component nested tags and then I also see blazor-component tags surrounding some of the NavLinks. I think in some cases this will mess with css cascade for some existing bootstrap templates, for example, that have css like li > a vs li > blazor-component > a. Is there some reason for this blazor-componsnt tag in the dom when something like a data attribute could be set on the a tag instead maybe?

area-blazor

Most helpful comment

@bdparrish I'm not totally certain what you're asking, but if you mean "where would this be implemented", it would be in BrowserRenderer.ts. It's probably best if I implement this myself as I already have 90% of it done in a private local branch (including tests) and am pretty clear about what's needed for the last 10%.

All 8 comments

Hmmm, yeah I guess I see but this may cause unintended issues with css and broad adoption possibly using the non-standard tags. I hope the team looks for a better more standard way to accomplish this. Hopefully some of those bullet points for the future will help...

The current short-term plan is to put in a special case where:

  • If your component renders exactly one top-level element, then we'll not insert the <blazor-component> wrapper
  • If your component renders 0 or 2+ top-level elements, then we will insert the <blazor-component> wrapper
  • If your component switches between inserting ==1 and !=1 top-level elements, then we dynamically insert/remove the wrapper as part of the rendering process.

This preserves the O(1) lookup during diff applications while giving developers an easy way to avoid the weird wrapper elements in most realistic cases. Normally it does make sense for a component to supply exactly one top-level element.

I know there are still some edge cases where you really want to return multiple top-level elements and really don't want a wrapper, but that's something we'd probably leave until further in the future to implement. It's certainly possible; we just need to do more complex things to keep the optimizations working.

But is the wrapper around anchor tags a bug?

No, it's currently by design, with the intention of removing it soon as described above.

ok thanks!

@SteveSandersonMS

Trying to track down the reference for all this in the code base, but I am coming up empty. Where is the complexity pieces for this? Blazor.Browser.JS or Blazor project?

@bdparrish I'm not totally certain what you're asking, but if you mean "where would this be implemented", it would be in BrowserRenderer.ts. It's probably best if I implement this myself as I already have 90% of it done in a private local branch (including tests) and am pretty clear about what's needed for the last 10%.

Was this page helpful?
0 / 5 - 0 ratings