Ответ 1

Мы использовали d3 с Backbone довольно широко в проекте, который состоял из нескольких "сцен". Каждая сцена содержала множество разных графиков, и пользователь мог перемещаться с одной сцены на другую. Эти сцены и их содержимое должны быть полностью настраиваемыми (например, цвета ярлыков и форматирование или указание, какие параметры данных должны отображаться на заданной оси).

D3 (по праву) не предоставляет систему управления представлением, в которой задействована Backbone. Backbone Views были обертки для диаграмм d3. Как и ожидалось, Backbone Models служили носителями данных, построенных на d3. Но более интересно, мы также обнаружили, что они хорошо служили средством контроля внешнего вида и поведения кода d3, содержащегося в Backbone Views; в основном они служили просматривать модели. Поскольку 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()

Ответ 2

Я использовал 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#/

Ответ 3

Недавно я поговорил на эту тему, вот несколько ссылок: Видео Код Slides

Я сделал несколько небольших проектов, используя аналогичные методы для встречи, но недавно начал изучать Ember + D3. Я еще ничего не сделал, но я думаю, что у Ember есть что предложить, что упростит создание таких приложений. Некоторые вещи, которые приходят на ум:

• Вычислимые свойства: вы часто будете отображать агрегаты, поэтому нарезка ваших данных с помощью вычисляемых свойств означает, что вам просто нужно вызвать функцию обновления диаграммы всякий раз, когда данные меняются, и вам хорошо идти. Больше не нужно беспокоиться о отправке события в каждое представление, которое изменится при изменении одной конкретной части ваших данных. Кроме того, они, вероятно, будут свойствами на ваших контроллерах, вместо того, чтобы вычисляться в определенной диаграмме или представлении, что значительно облегчит повторное использование.

• Сохранение состояния. Мне было трудно найти оптимальный способ хранения состояния в Backbone. Я начал пытаться координировать все через события, но в конце концов приземлился на наличие отдельной модели государства, которая действовала как мозг всей системы.

  Я не очень часто использовал маршрутизатор Backbone, но Ember router + focus on state сделал эту задачу дизайна более простой для меня до сих пор. Если вы построите систему, вы можете щелкнуть по своим фильтрам и элементам управления, и все будет работать. Возможно, можно сделать то же самое в Backbone, но есть кое-что, что можно сказать о серьезном уменьшении вашей когнитивной нагрузки. Вы также можете явно использовать объект StateManager - здесь могут быть некоторые действительно интересные решения, хотя я еще не изучил их.

Опять же, мой опыт работы с этим комбо неглубокий, но если мой инстинкт прав, у нас будут большие выгоды от создания визуализации в соглашениях Ember.

Если вы еще не сталкивались с этим, Square выставил статью, кратко освещая их опыт создания интерактивной панели с помощью Ember + D3.

Держите нас в курсе вашего прогресса + любые идеи, с которыми вы сталкиваетесь, и удачи!

Ответ 4

Моя группа использовала и angular и магистраль с d3, и нам нравятся оба по разным причинам.

Магистральные

Магистраль немного менее самоуверенная относительно того, как вы создаете свое приложение, что приятно, если вам нужно настроить способ обработки данных для производительности. Обычно вы объединяете d3 с представлением о магистрали.

Одной из проблем работы с Backbone является управление памятью для сложных представлений, но используя marionette помогает с этим. Кроме того, агрегатор событий Marionette (и особенно с использованием запроса-ответа) подходит для централизованных источников данных для согласованных представлений, если вы хотите использовать что-то вроде crossfilter или lunr.

Angular

Angular более структурирован, и он позволяет быстро создавать интересные функции. Он имеет крутую кривую обучения, но теперь я понял, что понимаю angular (используя его для разработки приложения за последние 4 недели), я обнаружил, что могу выполнять многие из тех же вещей Я могу в позвоночнике, не прибегая к чему-то слишком хакерскому.

Как и объект запроса-ответа в марионетке с базой данных, использование служб angular позволяет быстро создавать сложные представления. Вам нужно будет избежать использования angular грязной проверки данных $scope для сложных визуализаций данных, чтобы ваше приложение не увязло, поэтому код, который вы пишете для работы с вашими данными в angular, в конечном итоге будет выглядеть много как код, который вы должны писать в позвоночнике.

Я некоторое время сопротивлялся angular "магии", но я начинаю выигрывать благодаря скорости развития, которую вы можете достичь из-за всех встроенных директив, проверки области и других полезных свойств. angular по-прежнему позволяет вам сориентироваться во внутренних деталях, чтобы ускорить ваш код, когда это необходимо. Это "копание" может занять больше времени, чем в магистрали (потому что база кода более сложна), но я обнаружил, что потерянное время на этой фазе обычно окупается за счет экономии времени, избегая общих ошибок, таких как утечка памяти в виде кода и написания шаблона код, как просмотр изображений и привязка данных.

В заключение

• Backbone - хороший выбор, если вам необходим обширный контроль и настройка
• Angular отлично, если вам действительно нравится привязка данных
• Эмбер, вероятно, тоже прекрасен, если не по какой-либо другой причине, чем Square использует (используется?) это, а Майк Бостокс работал на Square.
• В любой ситуации "жесткие" части данных, интенсивно потребляющие данные, вероятно, будут выглядеть одинаково, если вы их хорошо напишете (т.е. получите преобразование данных в сервисы и поместите простой интерфейс вокруг вашего кода просмотра)

Ответ 5

D3 на Angular

Я использую D3 на Angular с одного года, и мне нравится комбинация обоих. Angular использует директивы для создания новых и многоразовых элементов HTML. Когда у вас есть этот knowlegde, вы можете инкапсулировать визуализацию D3 в директиве Angular, не имея 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>.

Вот оно!

Кроме того, вы можете использовать watcher в своей директиве для просмотра изменений данных в вашем контроллере. Хороший пример многоразовых директив d3 в Angular дает следующий пример: http://bl.ocks.org/biovisualize/5372077

Кроме того, вы можете найти простой способ D3 в Angular в этой статье: http://goo.gl/hNS8k1 На этом сайте вы найдете дополнительные сведения о том, как использовать d3-плагины, такие как плагин fisheye, в вашем приложении Angular или как реализовать более сложные визуализации d3 в Angular.

Ответ 6

Я работал с Backbone + d3 и немного Angular + d3.

Магистраль страдает от проблемы с утечкой памяти, и если вы используете магистраль, вы должны быть точными с сборкой мусора. Однако, как упоминалось ранее, марионет или чаплин могут легко решить эту проблему. Если вы хотите иметь легкое и быстрое приложение, я рекомендую вам использовать реактивный движок для просмотра и базовых моделей для других нужд.

Что касается Angular, он имеет более строгую структуру. Однако я считаю, что это будет почти та же логика, что и Backbone. Angular заботится о архитектуре и всем, что нужно, просто писать код по refs, и это будет основной. В отличие от основы, где структура - это ваш вариант.

Я рекомендую вам сравнить маршрутизацию, привязки, модели, чтобы выбрать правильную структуру, но не просматривать.

Я всегда выбираю хребет + что-то, часто реагирую. Потому что это гибкий и простой в управлении вид приложения. F.E. когда мы обнаружили реакцию, мы перешли от позвоночника, чтобы отреагировать на устранение проблем с протеканием mremory. Однако в приложении было около 50 просмотров с различными инструментами визуализации данных со многими элементами управления. И мы переместили взгляды шаг за шагом через два месяца. Трудно сделать то же самое с такими же усилиями в angular.

Ответ 7

D3 на Angular.js

Я думаю, что эти типы вопросов на самом деле не имеют правильного ответа ИМО, он как бы спрашивает кого-то, должны ли они выбирать Subaru или Toyota, когда все, что им нужно сделать, это получить от a до b:) Во всяком случае, используя AngularJS и D3 на данный момент, настолько хороши:) Существует красивая директива AngularJS для D3 и NVD3, если вы решите пойти с AngularJS.

Кроме того, проверьте это превосходное сообщение при объединении D3 с AngularJS.

Счастливое изучение!