Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Apr 9, 2011
  1. Merge branch 'bullet'

  2. Separate scales per bullet.

    Rather sharing the x-scale across bullet multiples, compute a separate scale per multiple. This
    gives the user more control over the scale: by setting the range values across multiples (in data),
    the user can precisely control the resulting scales. For transitions, we cache the old scale value
    in a hidden __chart__ attribute. This is a bit of a hack (it might be cleaner to persist it in the
    data of a child element), but it might provide a sticky way for charts to communicate with each
    other in the future, say for performing transitions across chart types.
  3. Remove `parentData`.

    It's equivalent to `parentNode.__data__`, so it's not needed. Technically, this
    is not backwards-compatible, but these two fields on the group object are not
    part of the public API (despite being technically accessible).
  4. @jasondavies

    Push bullet chart state into ticks element data.

    jasondavies authored
    This means chart state (the original x-scale) is no longer bound to the
    chart instance, so a single instance can be reused on multiple elements.
Commits on Apr 8, 2011
  1. Rename var.

  2. @jasondavies
  3. Add another bullet example.

    This example shows how to preserve scales across multiples using a single chart
    instance, as opposed to bullet-multiples which uses distinct chart instances to
    supply separate scales. I still think it'd be better to use a single chart
    instance in both cases, but then I need a different place to hide the scale
  4. @jasondavies

    Merge Mike's changes.

    jasondavies authored
  5. @jasondavies

    Merge Mike's changes.

    jasondavies authored
    Includes hard-coded orientation for simplicity.
  6. Use separate charts for bullet-multiples.

    This way, we get separate scales for the small multiples, which makes sense
    given our data. However, I'm not totally convinced this is the right way to
    implement separate scales, because it's a bit awkward to create separate chart
    instances that look identical. Also, it's unfortunate that the charts are
    stateful; it'd be better to somehow store the scale as data on the nodes, so
    that chart specifications could be more easily reused. Then, there might be a
    method to fix the domain rather than computing the domain per-chart.
  7. Fix bugs in remove & data.

    The remove operator was completely broken in 1.8.6. I will add some tests to
    make sure that doesn't happen again. Also, the data operator was broken if you
    had duplicate keys in your join function; in this case, the duplicate elements
    would not always be removed.
  8. Extract title & subtitle from bullet chart.

    It's nice, but I think it's a bit more flexible to not have it as part of the
    chart specification. This way, people can define titles however they like. It
    might be nice to take a similar approach with reference ticks in the future.
  9. @jasondavies

    Cache chart instances.

    jasondavies authored
  10. @jasondavies
  11. @jasondavies
  12. @jasondavies
  13. @jasondavies
  14. @jasondavies

    Simplify bullet multiples example.

    jasondavies authored
    Thanks Mike!
  15. @jasondavies
  16. @jasondavies

    Add some comments.

    jasondavies authored
  17. @jasondavies
  18. @jasondavies
  19. @jasondavies
  20. @jasondavies

    Merge Mike's changes.

    jasondavies authored
Commits on Apr 7, 2011
  1. Bullet chart transitions.

    We now preserve object constancy for ticks across transitions. By caching a
    reference to the previous x-scale, we can initialize entering objects in the
    correct location, then transition them to the new scale as they fade in. Also,
    we use the `map` operator to convert the data to a standard representation that
    is suitable for the bullet chart, and compute derivate data needed across
  2. @jasondavies
  3. Don't reselect on remove.

    The previous behavior of selecting the parent node was extremely confusing
    because it could result in the parent node being selected multiple times (when
    removing siblings). Even worse, the child data would override the parent data!
    This changes the `remove` operator so that it matches the behavior of the W3C
    API (removeChild), returning the removed nodes.
  4. @jasondavies

    Minor optimisation.

    jasondavies authored
  5. @jasondavies
Something went wrong with that request. Please try again.