we are evaluating Blazor as tech stack for a large enterprise application and I’m having some questions.
Let’s say we have two text boxes and both can be edited by the user. When one edits the first one, a backend code is executed which might end in a code where the second text box (bind to property) is edited, one second after the first edit.
That can cause issues because the user might have typed in the second textbox in the meantime.
We might block user inputs while the backend code is running, however, I’d prefer to not block user inputs during server calculations.
Is there any good way of handling that?
The perfect solution would be that a popup appears because of concurrent edits, and the user can decide what to do. At least he is informed that his value might be overwritten.
Any ideas?
Thanks
3
Answers
As pointed out in one of the replies, the concurrency issues are the same irrespective of the framework. However the implementation can differ drastically depending on whether you use Blazor Server or Blazor WebAssembly.
Finally, you can always resolve concurrency optimistically (like EF Core). But keep in mind the fact that with WA, the concurrency conflict might become known only at the point of commit – unless addressed explicitly.
Blazor Optional Input Value
Not sure this helps, but in Blazor Server you can do all kinds of creative combinations of what you describe.
One way to do this is the following: Instead of binding the first input to the second you just call a method and run your await-async server process that returns a new modified value based on the first input. The user can continue filling out the second input (or any input) as the asynchronous server Task is processing and it returns the new modified value.
When the await call to the server returns the new value, a JSInteropt call triggers a regular JavaScript
window.confirm(x)
popup with a question in the browser. They can choose to keep their value, clicking"ok"
, or accept the one from the second input clicking"cancel"
. Its not very sexy but it gives you an idea. Note: In this example below Im not modifying the first input from the server call, just passing the raw value to the second input.You can paste the code below into any Blazor Server component and test it:
I realize this is kinda sloppy. I’m not a fan of using JSInterop or JavaScript prompts like this. You run the danger of calling the JavaScript global window object outside of
SignalR
and dropping the WebSocket connection when you do these tricks or going over the Blazor Server SignalR MaximumReceiveMessageSize limit of 32k. But Blazor gives you that creative ability to add all kinds of goodies like this.A better way of using a custom popup would be to just build a new
Blazor Component in HTML with CSS
as a<div>
and have that layer over your screen usingz-index in CSS
, then show and hide it based on the events above. Or this can be a tiny blazor component that slides into view beside the input with a choice they can quickly click.But at least this shows you one of the many ways in Blazor to handle these kinds of scenarios.
So do exactly what you have described, where’s the problem?
If you are familiar with Reactive Extensions, I would build an operator (or extension method to detect changes to particular field while you are waiting for the source observable (
CalculatePropertyBAsync
) to emit a value and make this reusable. Something like:the advantage is, that you can combine this with
Switch/SelectMany
(better known as SwitchMap in RxJS) orThrottle
operators to handle concurency issues when PropertyA changes too ofter and so on.