16

私は、多くの D3 チャート/インタラクションを含む中規模のアプリケーションに取り組んでいます。D3 で Backbone、Angular、または Ember を使用しようとした人がいるかどうか疑問に思っています。もしそうなら、どれがフロントエンド MV* フレームワークに最適だと思われますか? アプリケーションは、多くの CRUD 操作を行うわけではありません。主にインタラクティブなチャートとウィジェットを操作するためです。

コメントをお待ちしております。

4

7 に答える 7

12

複数の「シーン」で構成されるプロジェクトで、d3 と Backbone をかなり広範囲に使用しました。各シーンには一連の異なるチャートが含まれており、ユーザーはあるシーンから別のシーンに移動できます。これらのシーンとそのコンテンツはすべて、高度に構成可能である必要がありました (たとえば、ラベルの色と書式設定、または特定の軸にプロットするデータ パラメータの指定など)。

D3 は (当然のことながら) ビュー管理システムを提供していません。これは Backbone が引き継いだ場所です。バックボーン ビューは、d3 チャートのラッパーとして機能しました。予想通り、バックボーン モデルは d3 プロットされたデータのキャリアとして機能しました。しかし、さらに興味深いことに、バックボーン ビューに含まれる d3 コードの外観と動作を制御する手段としても機能することがわかりました。基本的に、それらはビュー モデルとして機能しました。d3 は関数を引数として他の関数に渡すことを促進するため、これらの Backbone Models-as-view-model はそれらの中に多くの関数を保持することになりました。

以下は単純な例ですが、数十のプロパティでこれを行っていることを想像してください。ここでは、短い (そして優れている) ため、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()
于 2013-06-12T05:07:07.033 に答える
7

私は最近、まさにこのトピックについて講演を行いました。ここにいくつかのリンクがあります:ビデオ·コード·スライド

私は、meetamit と同様の方法を使用して小規模なプロジェクトをいくつか行ってきましたが、最近、Ember + D3 の調査を開始しました。私はまだ多くのことを行っていませんが、Ember には、このような種類のアプリの作成を簡素化できる機能がたくさんあると思います。頭に浮かぶいくつかのこと：

  • 計算されたプロパティ: 集計を表示することが多いため、計算されたプロパティを使用してデータをスライスすると、データが変更されるたびにグラフの更新関数を呼び出すだけで済みます。データの特定の部分が変更されたときに変更されるすべてのビューにイベントを送信することを心配する必要はもうありません。さらに、これらはおそらく、特定のチャートやビュー内で計算されるのではなく、コントローラーのプロパティになるため、再利用がはるかに簡単になります。

  • 状態の保存: バックボーンに状態を保存する最善の方法を見つけるのに苦労しました。最初はイベントを介してすべてを調整しようとしましたが、最終的には、システム全体の頭脳として機能する個別の状態モデルを持つことになりました。

    私は Backbone のルーターをあまり使用しませんでしたが、Ember のルーター + 状態へのフォーカスにより、これまでのところ、この設計上の課題が簡単になりました。システム内で構築する場合は、フィルターとコントロールをクリックするだけで、すべてが機能します。バックボーンでもまったく同じことができるかもしれませんが、認知負荷を大幅に軽減するために何か言いたいことがあります. StateManagerオブジェクトを明示的に使用することもできます。まだ調べていませんが、ここには非常に興味深い解決策があるかもしれません。

繰り返しますが、この組み合わせに関する私の経験は浅いですが、私の直感が正しければ、Ember の規則内でビジュアライゼーションを構築することで多くの利益が得られるでしょう。

まだこれに出くわしていない場合は、 Square が、Ember + D3 を使用してインタラクティブなダッシュボードを構築した経験を簡単に説明する記事を掲載しました。

あなたの進捗状況とあなたが見つけた洞察を最新の状態に保ち、幸運を祈ります!

于 2013-07-23T03:56:34.707 に答える
6

私のグループは d3 で angular と backbone の両方を使用しており、さまざまな理由で両方を気に入っています。

背骨

Backbone は、アプリケーションの構築方法についてあまりこだわりがありません。これは、パフォーマンスのためにデータの処理方法をカスタマイズする必要がある場合に便利です。通常、d3 をバックボーン ビューと統合します。

Backbone を使用する際の課題の 1 つは、複雑なビューのメモリ管理ですが、マリオネット を使用すると、その問題を解決できます。また、Marionette のイベント アグリゲーター (特にrequest-response を使用) は、 crossfilterやlunrなどを使用する場合、調整されたビューの集中型データ ソースに適しています。

角度

Angular はより構造化されており、優れた機能を非常に迅速に構築できます。急な学習曲線がありますが、Angular を理解していることがわかりました (アプリケーションの開発に過去 4 週間使用しました)。ハック的なものに頼ることなくバックボーンに。

バックボーン マリオネットのリクエスト/レスポンス オブジェクトと同様に、Angular サービスを使用すると、複雑なビューをすばやく構築できます。アプリケーションが動かなくなるのを防ぐために、複雑なデータの視覚化のために $scope データに対する angular のダーティ チェックを使用しないようにする必要があります。バックボーンに書き込みます。

しばらくの間、angular の「魔法」に抵抗していましたが、組み込みのディレクティブ、スコープ チェック、およびその他の優れた機能のおかげで達成できる開発のスピードに打ちのめされ始めています。Angular では、必要に応じてコードを高速化するために内部をいじることができます。この「掘り下げ」にはバックボーンよりも時間がかかる場合があります (コード ベースがより複雑なため) が、このフェーズで失われた時間は通常、ビュー コードでのメモリ リークやボイラープレートの作成などの一般的なバグを回避して節約された時間によって取り戻されることがわかりました。ビューのレンダリングやデータ バインディングなどのコード。

要約すれば

  • 広範な制御とカスタマイズが必要な場合は、バックボーンが適しています
  • データ バインディングが本当に好きなら、Angular は優れています
  • Square以外の理由で Ember を使用する (使用した?)場合は、Ember もおそらく問題なく、Mike Bostocks は Square で働いていました。
  • どのフレームワークでも、アプリの「ハード」なデータ集約部分は、適切に記述すればおそらく似たようなものになるでしょう (つまり、データ変換をサービスに取得し、ビュー コードの周りにクリーンでシンプルなインターフェイスを配置します) 。
于 2014-04-21T14:16:20.030 に答える
1

Angular.js 上の D3

これらのタイプの質問には、実際には正しい答えがないと思います.IMO、それは、スバルとトヨタのどちらを選択する必要があるかを誰かに尋ねるようなものです.現時点では、これまでのところとても良いです:) AngularJSを使用することを選択した場合、D3 および NVD3 用の優れた AngularJS ディレクティブがあります。

また、 D3 と AngularJS の組み合わせに関するこの優れた投稿もチェックしてください。

楽しい探検！

于 2015-01-20T09:21:33.487 に答える