现代 JavaScript 设计方法来管理复杂性？
我有一个带有 javascript 代码库的 Web 应用程序，它的大小已经足够大，以至于我不得不开始重新评估如何最好地设计它来管理复杂性。这让我对 JavaScript 设计模式产生了一些疑问：
- HTML5 data- 或其他自定义属性是否是好主意？他们可能会通过将控制器/视图模型逻辑耦合到表示层来产生问题吗？这是否会与测试驱动的开发方法产生潜在的冲突？
- 数据属性与扩展属性具有相同的用途吗？
从经验、轶事证据或其他方面来看，MVVM 模式在实践中被证明有多有用？您认为它有什么限制吗？我发现，从 javascript 对象到 UI 控件并不总是存在直接的数据绑定。例如，将集合绑定到 jQuery 插件/小部件。与 WPF/Silverlight 一样，如果控件作者没有设计控件来支持 MVVM 模式，那么您可能会被迫创建变通方法。
在 javascript 中进行轮询有多大问题（例如 window.setInterval)?如果我想在典型应用程序中轮询 10、100 或 10,000 个 javascript 对象（无网络请求），性能损失有多严重。或者你会如何衡量这个？有时我发现轮询某些条件以触发 UI 中的更改很有用，例如 CanExecute。
I have a web app with a javascript code base that's growing enough in size to where I've had to start re-evaluating how to best design this to manage the complexity. This has led me to a few questions on JavaScript design patterns:
- Are HTML5 data- or otherwise custom attributes a good idea? Might they create a problem by coupling controller/viewmodel logic to the presentation layer? Does this create potential conflicts with a test-driven development methodology?
- Do data- attributes serve the same purpose as expando properties?
From experience, anecdotal evidence, or otherwise - how useful has the MVVM pattern proven to be in practice? Do you see any limitations with it? One I have found is that there isn't always a straightforward data binding from a javascript object to a UI control. For example, binding a collection to a jQuery plugin/widget. As with WPF/Silverlight, if the control author didn't design the control to support the MVVM pattern, then you may be forced to create workarounds.
How much of a problem is it to do polling in javascript (e.g. window.setInterval)? How bad is the performance penalty if I want to poll 10, 100, or 10,000 javascript objects (no network requests) in typical app. or how would you measure this? Sometimes I've found it useful to poll some condition to trigger a change in the UI, like CanExecute.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论