一些示例代码

var viewModel =
{
…
editBlog: function (blog)
{
  $("#selectView").fadeOut("slow");
  $("#editView").fadeIn("slow");
},
updateBlog: function (blog)
{
  viewModel.commitSelected(blog);
  $("#editView").fadeOut("slow");
},
cancelEdit: function (blog)
{
  $("#editView").fadeOut("slow");
},
commitSelected: function (blog)
{
  for (var property in blog)
  {
   if (blog.hasOwnProperty(property) && blog[property].commit)
    blog[property].commit();
  }
},

newBlog: function ()
{
  this.blogs.push(toKoObservable({
   Title: "New " + this.blogs().length + 1,
   Id: this.blogs().length + 1,
   Post: "Post " + this.blogs().length,
   IsNew: true
  }));
}
}

我正在寻找建议以上代码是正确的做法或可能导致问题的邪恶。如果上面的代码不好，那么告诉我当一个人从淘汰视图模型函数访问DOM时可能会出现什么样的问题。

请指导我的不足之处。

Answer 1

这很糟糕。

通过使用cancelEdit之类的函数，您将创建一个不再完全由您的挖空模型体现的应用程序状态。编辑器是打开还是关闭？通过使用jQuery来调用UI，我们只是丢失了对这些信息的跟踪，因此我们将应用程序状态分散到我们无法再跟踪它们的地方。我们必须使用更多jQuery来查询UI的状态。让这个腐烂继续，很快，一个漂亮，可管理的淘汰应用程序不再表现得非常好，因为无法通过淘汰赛来预测UI变化。

隐藏在UI状态中隐藏应用程序状态的一部分是一件坏事，而这正是用jQuery强迫你做DOM的事情。

更具惯用性的是拥有一个取决于模型状态的UI：

<div data-bind="visible:$data.editorIsVisible">
    <!-- editor stuff -->
</div>

现在方法cancelEdit可以：

var editorIsVisible = ko.observable(true); //this would be somewhere in the bound model
function cancelEdit(){
    editorIsVisible(false); //good, update the model, UI follows automatically
}

如果（例如）visible绑定的“突然性”诱使您使用jQuery，那么应该通过使用新类型的bindingHandler来仔细管理。有关示例，请参阅http://knockoutjs.com/examples/animatedTransitions.html。

简而言之，我的个人意见是jquery不应该与淘汰赛结合使用，当它绝对必要时，它应该以一种与淘汰赛很好地配合使用的方式使用模型，而不是让UI做一些“超过淘汰赛的头脑”。

由于我采用了淘汰方式，我发现jQuery真的退居二线。

Knockout JS：使用Knockout JS时，通过jquery直接访问DOM是好的

一些示例代码

1 个答案: