Aspnetcore: SVG-replacement of Font Awesome 5 breaks BrowserRenderer.applyEdits()

[DNF-SaS]

When using Font Awesome's new feature of replacing the element (usually a span with some css-classes) with a real SVG element, it breaks Blazor's applyEdit logic.
This is because FontAwesome comments out the original element and puts a new SVG-Element in _additon_ as a sibling into the DOM right before the original element.
This results in the parent element having an additional child, changing the childIndex of every element after the inserted one.
If I'm correct, Blazor's BrowserRenderer determines the element for applying dom-edits by remembering it's position in the childNodes-Array of the parent. Because of FA's element-insertion, the following code will return the wrong DOM-element:

https://github.com/aspnet/Blazor/blob/3bbe9f50c94661cc36527be67200b04e630d642f/src/Microsoft.AspNetCore.Blazor.Browser.JS/src/Rendering/BrowserRenderer.ts#L85

Because of that, the next line of code in BrowserRenderer.ts will replace the wrong element's textContent generating unpredictable results.

[DNF-SaS]

As a workaround, Font Awesome can be configured to remove the SVG-replaced original element by setting keepOriginalSource to false.

Example:

<script>
  window.FontAwesomeConfig.keepOriginalSource = false;
</script>

[SteveSandersonMS]

Thanks for posting info about the workaround.

In general, libraries need to not mutate the DOM in unpredictable ways, as it would break both Blazor any anything else based on diffing.

Closing as external.