websocket - Blazor 服务器 : How to reliably handle the delay of user actions?

Question

将 Blazor Server 与 Blazor WebAssembly 进行比较，我发现了一个可能/应该对应用程序设计产生重大影响的显着差异。让我根据一个简单的要求来概述这种差异:

Clicking a button to increase a counter and whenever the counter reaches 10, the button will be disabled.

让我们比较一下:

• Blazor WebAssembly:单击事件处理程序在用户单击按钮后立即在浏览器中同步执行。计数器增加并检查条件。如果计数器为 10，则将使用属性绑定(bind)禁用该按钮。用户不可能点击第十一次。
• Blazor 服务器:点击事件处理程序在服务器上异步执行，只有在点击事件发布到 channel 并被服务器接收后才会执行。 这可能需要任意时间，具体取决于 Internet 连接。 服务器上的计数器会增加，并且会检查条件。然而，在浏览器获知按钮可能的状态变化之前，用户可以点击按钮一次或多次，导致服务器上的事件处理程序再次执行，从而可能增加计数器超过允许的值。

---

作为使用 Blazor Server 的程序员，我不能再依赖我可能习惯于在 JavaScript 应用程序中同步不间断地处理用户交互事件。 我必须通过额外的健全性检查来打乱我的所有事件处理程序，以确保没有意外发生。这也阻止了从 Blazor WebAssembly 直接迁移到 Blazor Server(坦率地说，反之亦然)。 p>

请注意，我不相信延迟如此之小以至于在 GUI 更新之前没有真正的用户能够再次单击的论点。即使对于非常受控的网络条件，延迟也可能会意外发生。此外，依靠机会和外部因素从来都不是一个好的选择。还记得墨菲定律吗？

我的问题是:您在实践中是如何处理这个问题的？您是否费心在事件处理程序中编写所有这些完整性检查？

Answer 1

我的结论是，为了在源代码级别平等对待 Blazor WebAssembly 和 Blazor Server，您必须为自己应用某些模式和限制，否则运行时行为可能会有所不同。

其中之一是 Blazor 服务器中发生的输入延迟。即使它很小——或者应该很小，如果你希望在从 WebAssembly 切换到服务器时防止严重的错误，你仍然必须解决它。

解决它的一种方法是使用代码保护每个事件处理程序(对用户交互事件使用react)，确保前端的状态确实可以安全地执行此处理程序。在“传统的”SPA Web 应用程序(如 Angular)中，无论如何都应该防止在服务器端进行不需要的操作，在 Blazor 应用程序中也是如此。但是，在 Blazor 应用程序中，您还还必须更加严密地保护您的前端，因为您不能依赖不间断的同步处理程序执行。

在我看来，Blazor 是一个有漏洞的抽象，因为 WebAssembly 和服务器之间的决定不仅仅是一个实现细节。