rep*_*cus 16 backbone.js d3.js angularjs
我正在开发一个中等大小的应用程序,其中包含很多D3图表/交互.我想知道是否有人试图使用Backbone,Angular或Ember与D3,如果是这样,哪一个似乎最适合前端MV*框架.该应用程序不会进行大量的CRUD操作,主要是交互式图表和小部件来操作它们.
任何评论赞赏!
mee*_*mit 12
我们在一个由多个"场景"组成的项目中广泛使用了d3和Backbone.每个场景包含一组不同的图表,用户可以从一个场景导航到另一个场景.这些场景及其内容都需要高度可配置(例如标签颜色和格式,或指示应在给定轴上绘制哪些数据参数).
D3(理所当然地)没有提供视图管理系统,这是Backbone接管的地方.Backbone Views充当d3图表的包装器.可以预见,Backbone模型可以作为d3绘图数据的载体.但更有趣的是,我们还发现它们可以很好地控制Backbone Views中包含的d3代码的外观和行为.基本上他们作为视图模型.由于d3将传递函数作为参数提升到其他函数中,因此这些Backbone Models-as-view模型最终在其中包含许多函数.
以下是一个简单的例子,但是这样做有很多属性.在这里使用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()
Dan*_*l F 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-通话/幻灯片/演示/ A-甜甜圈图表编辑器/ index.html的#/
我最近就这个话题发了言,这里有一些链接:视频 · 代码 · 幻灯片
我已经用类似的方法做了一些较小的项目来实现,但最近开始探索Ember + D3.我还没有做太多,但我认为Ember有很多东西可以简化构建这些类型的应用程序.想到的一些事情:
计算属性:您经常会显示聚合,因此使用计算属性对数据进行切片意味着只需在数据发生变化时调用图表的更新功能,就可以了.不再担心将事件发送到每个视图,这些视图会在数据的某个特定部分发生变化时发生变化.此外,这些可能是您的控制器上的属性,而不是在特定的图表或视图中计算,这将使重用更容易.
存储状态:我很难确定在Backbone中存储状态的最佳方法.我开始试图通过事件来协调一切,但最终还是有了一个单独的状态模型,它充当了整个系统的大脑.
我没有太多地使用Backbone的路由器,但Ember的路由器+关注状态使得这个设计挑战到目前为止对我来说更容易.如果您在系统内构建,可以单击过滤器和控件,一切正常.在Backbone中可能会做同样的事情,但是有一些东西可以说是为了减少你的认知负担.您还可以显式使用StateManager对象 - 这里可能有一些非常有趣的解决方案,但我还没有探索过它们.
同样,我对这个组合的经验很浅,但如果我的直觉是正确的,那么在Ember的约定中建立可视化将会有很多收获.
如果您还没有遇到过这个问题,Square会简要介绍一下他们使用Ember + D3构建交互式仪表板的经验.
让我们及时了解您的进度+您遇到的任何见解,祝您好运!
我的小组使用角度和骨干与d3,我们喜欢两个原因不同.
Backbone对于构建应用程序的方式不那么自以为是,如果您需要自定义数据处理性能的方式,那么这很好.您通常将d3与骨干视图集成在一起.
使用Backbone的一个挑战是复杂视图的内存管理,但使用牵线木偶 有助于此.如果您想使用crossfilter或lunr之类的东西,Marionette的事件聚合器(特别是使用请求 - 响应)非常适合协调视图的集中数据源.
Angular更加结构化,它允许您非常快速地构建很酷的功能.它有一个陡峭的学习曲线,但我现在发现我正在理解角度(使用它来开发过去~4周的应用程序),我发现我可以完成许多相同的事情,我可以在骨干中没有诉诸任何过于强硬的东西.
与主干木偶中的请求 - 响应对象一样,使用角度服务可以快速构建复杂视图.您需要避免对$ scope数据使用angular的脏检查来进行复杂的数据可视化,以防止您的应用程序陷入困境,因此您编写的以角度处理数据的代码最终会看起来很像您的代码会写在骨干上.
我已经抵抗了角度的"魔力"了一段时间,但是我开始被你可以实现的开发速度所取代,因为所有内置指令,范围检查和其他好东西.Angular仍允许您在其内部进行搜索,以便在需要时加快代码速度.这种"挖掘"可能比在主干中花费更多的时间(因为代码库更复杂),但我发现在这个阶段丢失的时间通常会被节省的时间收回,避免常见的错误,如视图代码中的内存泄漏和编写样板文件像视图渲染和数据绑定的代码.