Aspnetcore: Explicit client-side areas for JavaScript-based DOM manipulation with Blazor (server/client)

[Tragetaschen]

I have a Blazor page where I client-side-render SVG for graphs. I use JavaScript interop to push the raw data to the client and then use d3 to generate graphs, axes, and most importantly animations. All this is done based on an initial skeleton SVG where then paths are filled, text elements are created and so on. This works today, but it isn't compatible with the documentation, which currently, generically states:

Warning
The preceding example modifies the Document Object Model (DOM) directly for demonstration purposes only. Directly modifying the DOM with JavaScript isn't recommended in most scenarios because JavaScript can interfere with Blazor's change tracking.

On the other side, @SteveSandersonMS put that a bit into context here: https://github.com/aspnet/AspNetCore.Docs/issues/12020#issuecomment-485552533

I think it's viable to have an explicit mechanism that marks parts of the Razor document as out-of scope for the diff algorithm. So after pushing it out to the browser initially, there is a guarantee that Blazor's change tracking won't ever interfere and client-side JavaScript can party on those portions of the DOM.

Further technical details

• ASP.NET Core version 3.0

[SteveSandersonMS]

If your code doesn't modify a specific subtree in the document, then Blazor shouldn't attempt to update it further either.

So it doesn't seem like we need any feature to stop Blazor from modifying a subtree, since it's up to your code whether or not it does.

If I'm misunderstanding the scenario and the reason why that's not sufficient, please let me know!

[Tragetaschen]

I know it doesn't happen today and it's unlikely that this implementation detail changes in the future. However right now, this looks like I'm relying on this specific implementation and the documentation tries to drive me away from doing what I'm doing.

I'm looking for ways to make the status quo feel/look/actually more supported.

[SteveSandersonMS]

OK, thanks for clarifying. Mutating the DOM is a subtle area that the docs rightly warn people away from because you really have to be careful. It's the same with other SPA frameworks.

[Tragetaschen]

Hrmpf. I have presented a way to make it less subtle and you haven't commented on that.

I guess I just have to live with changing subtleties in future releases then—very frustrating.

[SteveSandersonMS]

Sorry, it wasn't my intention to be frustrating! I'm happy to talk more.

In general there's a real cost to adding to the framework's concept count. While this may be a bonus in your scenario, it costs literally every other Blazor developer because they need to know this feature exists and what it means. Building a usable framework means trading off these concerns, and in particular not letting it grow into a monster with hundreds of special cases that everyone has to be aware of, because who knows what random combination of features some other developer has previously been using in the project you're now maintaining.

Not only that of course, but we have finite resources to build and maintain the framework, with many other pressing priorities.

If there was a really clear pattern among other SPA frameworks that people have learned this kind of feature really needs to exist, then it would be a strong argument in favour of it. But if that's not the case, and in other similar technologies people manage without such a feature or perhaps address the problem in a different way entirely, then that's a strong case for not adding something like it.

I hope that makes sense, and sorry for not giving more of an explanation before.

[Tragetaschen]

Thanks for that, really appreciated! I understand the concept-count argument and indeed the Angular application I'm porting didn't have those guarantees either—neither in code nor in documentation.

Would you say it's feasible to extend the documentation with patterns that are safe for client-side DOM manipulation?

You basically commented like that over in the docs comment. Currently, it's "There be dragons" and future programmers (me in two months) looking at the code have to re-evaluate why and that it's probably, currently still safe to do what it's doing. This is a cost on my end :)

[SteveSandersonMS]

Yes, that sounds like a good strategy to me! Filed https://github.com/aspnet/AspNetCore.Docs/issues/15603