3

I've started looking at Blazor, and as I've built up some common Blazor Components, I've started to realise that I'm still unclear about a few design considerations. Theres not a great deal of guidance out there at the moment, and from what I have read it seems that the guidance/best practice will be put together from developers initial experience.

So these are the questions that are still niggling at me

Use of JavaScript.

Is JavaScript to be avoid as much as possible, I've read (and can understand why) modifying the DOM with JS could cause problems, and there are still a number of holes in the API that can only be solved with JS (setting focus being one example), But should JS be avoided where possible?

Performance

From what I can see the entire page is rendered regardless of the change made to it (the render tree is diff'ed and the changes applied to the DOM), this would appear to be an acceptable approach for low frequency page changes, but for finer more frequent changes will this end up causing performance problems? I'm thinking of interactions like drag and drop, opening menus, any mouse move interaction that changes the UI. Will this style of change remain the job of JavaScript?

Async and events

The Blazor environment strongly encourages the use of async methods, which on whole works, until you get into handling events raised within the Model or ViewModel where the handler needs to invoke Async methods. An approach I've been experimenting with is to use Async Events, but I'm unsure of whether this will cause problems down the line. The other approach is to block on the Task.Wait, but this seems unsatisfactory. I guess this is not entirely a Blazor design issue, but it seems to have presented itself quite a lot in my Blazor experience. Thoughts?

Sprotty
  • 5,676
  • 3
  • 33
  • 52
  • "the entire page is rendered regardless of the change" is incorrect. You explain why in your next sentence. – H H Dec 14 '19 at 10:47
  • Async and events don't mix too well. But Blazor does support sync methods (and event handlers) for just about anyrhing. That just means that Blazor will handle the .Wait() in a safe way. – H H Dec 14 '19 at 10:49
  • @enet I've got no answers to these issues, hence the question. I'm new to Blazor (~3 weeks), I've changed my thinking on many of these issues a number of times as I've picked things up, but I'm still not happy I have a 'good' approach to them. Much the code I've been looking at takes varied approaches to these issues. For example Telerik, Syncfusion and MatBlazor make quite heavy use of JS, and events become an issue if you want to perform an async action on them, which given most of your middleware methods end up being async is not that uncommon. – Sprotty Dec 14 '19 at 11:23
  • @HenkHolterman The event issue I keep running up against is; the UI causes changes to a Model object which raises a syncronous event, the code handling that event needs to make async calls (typically an IO call or initiate async UI changes), I could kick these off with Task.Run, but if I expect a result back I have to Wait, which means the async operation that caused the event to be raised is blocked (again fairly new to async-wait coding but that's my understanding - https://stackoverflow.com/questions/13140523/await-vs-task-wait-deadlock). – Sprotty Dec 14 '19 at 11:35
  • Yes, async is an all-or-nothing game. And events don't fit in very well. So: could you design your models & viewmodels to do without events? – H H Dec 14 '19 at 11:54
  • @HenkHolterman It would be possible to re-factor the event publishers, so subscribers registered a notification interface that contains Async notification methods, but it adds complexity, events hide all that pretty nicley. I'm experimenting with async delegates `public delegate Task AsyncEventHandler(object sender, EventArgs eventArgs);`, and a custom `InvokeAsync' method, which seem to work well, but I have a niggling feeling they'll cause me threading or synchronisation problems down the line. – Sprotty Dec 14 '19 at 12:07

0 Answers0