去除showModalDialog API [英] Removal of the showModalDialog API
问题描述
showModalDialog
API,我们的公司像许多其他提供大型企业Web应用程序的公司现在面临有一个很大的困境。虽然我们已经将调用集中到了 showModalDialog
下面的三行代码,依靠此代码提供模式用户提示的反馈(快速搜索解决方案将显示大约2400个实例)。
我们可以将 showModalDialog
相当容易,并用一个基于Javascript / css的替代替换它,这不是一个问题。我们面临的问题是,所有的调用代码将不再被阻止,如
if(doConfirm(...)) {
...
} else {
...
}
由于引入了一个非阻塞的替代方案,上面的内容将会简单地通过。我们也不能使用内置的阻塞方法(alert,confirm),因为对话框按钮在许多情况下都是自定义的,并且也是为了适合我们的应用程序而设计的。
基于上述情况,是否有任何务实的解决方案/解决方案,可以用来避免重新分配这么多遗留以前的阻止代码?
实用的解决方法避免必须手动重新分配代码?
您可以尝试使用带来等待
关键字到js。它应该会自动将您的代码转换为异步版本。
声明:我没有使用任何这些 With the impending removal of the Whilst we have centralised the calls to We could rip out The above will simply fall through due to the introduction of a non-blocking alternative. We also cannot use the in-built blocking methods (alert, confirm) as the dialog buttons are customised in many cases and are also styled to fit in with our application. Based on the above, are there any pragmatic workarounds/solutions that could be employed to avoid having to re-factor so much legacy previously blocking code? You won't get around using asynchronous, event-based code. pragmatic workarounds to avoid having to re-factor the code manually? You can try a javascript-to-javascript compiler that brings the Disclaimer: I haven't used any of these 这篇关于去除showModalDialog API的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!showModalDialog
API from various browsers, our company like many others who provide large scale enterprise web applications are now faced with a significant dilemma.showModalDialog
down to 3 lines of code, we extensively rely on this code to provide feedback from modal user prompts (a quick search of the solution reveals around 2400 instances).showModalDialog
fairly easily and replace it with a Javascript/css based alternative, that's not a problem. The issue we face is that all of the calling code will no longer be blocking e.g.if(doConfirm(...)) {
...
} else {
...
}
await
keyword to js. It should automatically transpile your code to an asynchronous version.