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?
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:
<blazor-component> wrapper<blazor-component> wrapperThis 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%.
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%.