D3与Backbone / D3与Angular / D3与Ember?

时间:2013-06-11 18:14:39

标签: backbone.js angularjs d3.js

我正在开发一个中等大小的应用程序,其中包含很多D3图表/交互。我想知道是否有人试图使用Backbone,Angular或Ember与D3,如果是这样,哪一个似乎最适合前端MV *框架。该应用程序不会进行大量的CRUD操作,主要是交互式图表和小部件来操作它们。

任何评论都表示赞赏!

7 个答案:

答案 0 :(得分:12)

我们在一个由多个“场景”组成的项目中广泛使用了d3和Backbone。每个场景包含一组不同的图表,用户可以从一个场景导航到另一个场景。这些场景及其内容都需要高度可配置(例如标签颜色和格式,或指示应在给定轴上绘制哪些数据参数)。

D3(理所当然地)没有提供视图管理系统,这是Backbone接管的地方。 Backbone Views充当d3图表的包装器。可以预见,Backbone模型可以作为d3绘图数据的载体。但更有趣的是,我们还发现它们可以很好地控制Backbone Views中包含的d3代码的外观和行为。基本上他们担任view models。由于d3将传递函数作为参数提升到其他函数中,因此这些Backbone Models-as-view-models最终在其中包含了许多函数。

以下是一个简单的例子,但是这样做有很多属性。在这里使用coffeescript,因为它更短(更好)。

首先,我们在内部(例如)路由器的事件处理程序中实例化模型。我们使用将应用于d3选择器的函数填充此模型。

barChartModel = new Backbone.Model
  barColor: (d, i) -> if d.profits < 0 then "red" else "green"
  barLengthVal: (d, i) -> return bar.profits #// profits will be the prop we graph
  onClick: (d, i) ->
    console.log "We are", if d.profits <= 0 then "losing" else "making", "money"
  data: someJsonWeLoaded

我们将此模型传递给新视图:

barChartView = new BarChartView
  el: "#the_bar_chart"
  model: barChartModel

视图可以像这样实现:

class BarChartView extends Backbone.View
  render: ->
    bars = d3.select(@el)
      .selectAll('.bar')
      .data(@model.get 'data') # <---- THIS

    bars.enter()
      .attr('class', 'bar')
      .attr('fill', @model.get 'barColor') # <---- THIS
      .attr('height', (d, i) ->
        @barLengthScale @model.get('barLengthVal')(d, i) # <---- AND THIS
      )
      .on('click', @model.get 'onClick') # <---- INTERACTIVITY TOO

  initialize: ->
    @barLengthScale = d3.scale.linear()
      .domain([-100, 100]) # <---- THIS COULD ALSO COME FROM MODEL
      .range([0, @$el.height()])
    @render()

答案 1 :(得分:10)

我在几个仪表板上使用了D3和Angular,它运行得非常好。我从来没有真正使用过Backbone,而不是D3,所以我无法比较这两者。我选择Angular来补充D3,因为在我看来,最近D3社区在你提到的三个选项中大部分都使用了D3和Angular,所以有很多可用的资源。最近有一本书专门用于将D3和Angular结合使用。我之前也曾使用过Angular,并且知道指令。指令(在Angular中它是一种扩展html标签的方法)非常适合与D3进行网格划分。每个图表都可以成为一个指令,然后使重用图表非常容易,只更改$ scope数据。这些是我发现在将两者结合起来时有用的一些资源:

https://www.youtube.com/watch?v=aqHBLS_6gF8
https://leanpub.com/d3angularjs
http://plnkr.co/edit/WnoCtNPV9azj0oPwv9kM?p=preview
http://vicapow.github.io/angular-d3-talk/slides/demos/a-donut-chart-editor/index.html#/

答案 2 :(得分:7)

我最近就这个主题发表了演讲,以下是一些链接:Video·Code·Slides


我使用类似的方法完成了一些小型项目,但最近开始探索Ember + D3。我还没有做太多,但我认为Ember有很多东西可以简化构建这些类型的应用程序。想到的一些事情:

  • Computed properties :您经常会显示聚合,因此使用计算属性切片数据意味着您只需在数据发生变化时调用图表的更新功能,你很高兴。不再担心将事件发送到每个视图,这些视图会在数据的某个特定部分发生变化时发生变化。此外,这些可能是您的控制器上的属性,而不是在特定的图表或视图中计算,这将使重用更容易。

  • 存储状态:我很难找到在Backbone中存储状态的最佳方法。我开始试图通过事件来协调一切,但最终还是有了一个单独的状态模型,它充当了整个系统的大脑。

    我没有太多地使用Backbone的路由器,但Ember的路由器+关注状态使得这个设计挑战到目前为止对我来说更容易。如果您在系统内构建,可以单击过滤器和控件,一切正常。在Backbone中可能会做同样的事情,但是有一些东西可以说是为了减少你的认知负担。你也可以明确地使用StateManager对象 - 这里可能有一些非常有趣的解决方案,但我还没有探索过它们。

同样,我对这个组合的经验很浅,但如果我的直觉是正确的,那么在Ember的约定中建立可视化会有很多好处。

如果您还没有遇到过此问题,请Square put up an article简要介绍一下使用Ember + D3构建交互式信息中心的经验。

让我们及时了解您的进度+您遇到的任何见解,祝您好运!

答案 3 :(得分:6)

我的小组使用了角度和骨干与d3,我们喜欢这两种原因。

骨干

Backbone对构建应用程序的方式不太了解,如果您需要自定义数据处理性能的方式,那么这很好。您通常将d3与骨干视图集成在一起。

使用Backbone的一个挑战是memory management for complex views,但使用marionette helps with that。如果您想使用using request-responsecrossfilter之类的内容,Marionette的事件聚合器(特别是lunr)非常适合协调视图的集中数据源。

Angular更加结构化,它允许您非常快速地构建很酷的功能。它有一个陡峭的学习曲线,但我现在发现我理解角度(使用它来开发过去~4周的应用程序),我发现我可以完成很多我可以在脊梁上做同样的事情而不诉诸任何过于苛刻的事情。

与主干木偶中的请求 - 响应对象一样,使用角度服务可以快速构建复杂视图。您需要避免对$ scope数据使用有角度的脏检查来进行复杂的数据可视化,以防止您的应用程序陷入困境,因此您编写的以角度处理数据的代码最终将会结束很像你在骨干中写的代码。

我曾抵制过棱角分明的&#34;魔法&#34;有一段时间了,但由于所有内置指令,范围检查和其他好处,我开始被你可以实现的开发速度所取代。 Angular仍允许您在其内部进行搜索,以便在需要时加快代码速度。这个&#34;挖掘&#34;可能需要比骨干更多的时间(因为代码库更复杂),但是我发现在这个阶段丢失的时间通常会被节省的时间收回,避免了视图代码中的内存泄漏等常见错误,并编写样板代码如查看渲染和数据绑定。

总结

  • 如果您需要广泛的控制和自定义,Backbone是一个不错的选择
  • 如果您真的喜欢数据绑定,Angular非常出色
  • 如果除了Square uses (used?) it之外没有其他原因,Ember也可能会很好,而且Mike Bostocks在Square工作。
  • 在任何框架中,&#34; hard&#34;如果你把它们写得很好(即将数据转换为服务和put a clean simple interface around your view code),你的应用程序的数据密集部分可能看起来很相似。

答案 4 :(得分:4)

上的

D3

我在Angular上使用D3已有一年了,我喜欢两者的组合。 Angular使用指令来创建新的和可重用的HTML元素。当您拥有此知识时,您可以在Angular指令中封装D3可视化,而无需在控制器或其他位置使用D3。之后,您可以在应用程序的任何位置重复使用该指令来可视化您的数据。在多个Angular开发人员的团队中工作时,团队的其他成员不需要了解D3,因为您的D3代码仅存在于指令中。

Angular中的指令为您提供了一种灵活的数据处理方式。您可以选择您的数据是否仍然存在于您的指令中(然后您将具有静态可重用的可视化),或者您将数据绑定到Angular应用程序中的控制器(然后您将具有动态可重用的可视化)。后者可以通过在指令

中设置范围来实现

scope: { data: '=' /* bi-directional binding */ }

在控制器中设置数据

$scope.data = [23,44,22];

并加入HTML元素实例

<div your-new-d3-element data="data"></div>

多数民众赞成!

此外,您可以在指令中使用观察程序来监视控制器中的数据更改。 Angular中可重用的d3指令的一个很好的例子给出了这个例子:http://bl.ocks.org/biovisualize/5372077

此外,您可以在本文中找到一个关于Angular设置的简单D3:http://goo.gl/hNS8k1 在本网站上,您可以找到有关如何在Angular应用程序中使用d3-plugins(如fisheye插件)或如何在Angular中实现更复杂的d3可视化的更多介绍。

答案 5 :(得分:3)

我使用 Backbone + d3 Angular + d3 一点点。

Backbone遇到内存泄漏问题,如果你使用主干,你应该准确垃圾收集。但是如前所述,marionet或者chaplin可以轻松解决这个问题。如果您想拥有轻快的应用程序,我建议您将反应引擎用于视图和骨干模型以满足其他需求。

对于Angular,它具有更严格的结构。但是,我相信它与Backbone的逻辑几乎相同。 Angular关注架构和所需的一切只需通过refs编写代码,它将是可维护的。与骨干不同,结构是您的选择。

我建议您比较路由,绑定,模型以选择正确的框架,但不是视图。

我总是选择骨干+ smth,经常是React。因为它灵活且易于管理应用程序视图。 F.E.当我们发现反应时,我们从骨干移动到反应,以解决我们的mremory泄漏问题。然而,应用程序有大约50个视图,具有不同的数据可视化工具和许多控件。我们在两个月内逐步移动了观点。 角度相同的努力很难做同样的事情。

答案 6 :(得分:1)

Angular.js上的

D3

我认为这些类型的问题确实没有正确的答案IMO,就像询问某人是否应该选择斯巴鲁或丰田一样,当他们需要做的就是从b :)无论如何,目前使用AngularJS和D3,到目前为止一切都很好:)如果您选择使用AngularJS,那么有一个很好的AngularJS directive for D3 and NVD3

另外,请查看此优秀的post on combining D3 with AngularJS

快乐探索!