-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better series indexing #34
Comments
Can you reference them by their feature name which is already injected in? For example: http://visible.io/charts/column/multi-dimension.html You get each series wrapped inside their feature name |
Oh the issue is not that there are duplicate classes, it's that there is no way to target a series by it's index without knowing what type of feature it is. The benefit of this is to allow for a consistent color progression on charts that share a stylesheet but display data differently. i.e. The first series is always red the second is always blue the third is always green, irrespective of the type of series. |
Got it ok, thank you for the explanation; let me think this one over. It seems like a solvable problem. |
@yanofsky would applying an index of the render order help so: <g class="chartArea">
<g class="bars"><g class="series0 value">...</g>
<g class="lines"><g class="series0 value">...</g>
</g> would become: <g class="chartArea">
<g class="bars" data-render-index='0'><g class="series0 value">...</g>
<g class="lines" data-render-index='1'><g class="series0 value">...</g>
</g> |
The index needs to be applied to the series's <g class="chartArea">
<g class="bars>
<g class="series0 value render0">...</g>
<g class="series1 value render2">...</g>
</g>
<g class="lines" data-render-index='1'>
<g class="series0 value render1">...</g>
<g class="series1 value render3">...</g>
</g>
</g> The way you have described above would also be inconsistent with the way D4 indicates series index and item index, right? |
ok how about this, what if I add a generic css class for <g class="chartArea">
<g class="bars feature">
<g class="series series0 value render0">...</g>
<g class="series series1 value render2">...</g>
</g>
<g class="lines feature" data-render-index='1'>
<g class="series series0 value render1">...</g>
<g class="series series1 value render3">...</g>
</g>
</g> then you could guarantee the same colors per series regardless of the returned data index using CSS like this: first series is always red: .feature .series:nth-of-type(1)
{
border:5px solid red;
} second series is always blue: .feature .series:nth-of-type(2)
{
border:5px solid blue;
} Would something like that work for you? |
did you intend to leave the renderX class in the example above? wouldn't The intention is to able select in order |
@yanofsky sorry no i didn't mean to leave the idea was that using CSS you could select the first element within a feature for example. This would mean that you could get consistent color across features if the series order is consistent. Does that make sense? I am trying to keep the series themselves unaware of the larger ordering within the data array. Their responsibility i believe is to order based on the data they are provided only. Otherwise I believe there is a violation in the separation of concerns. |
Thats probably true. Like I said in the first post, this can be achieved in afterRender, so not a big deal, if you don't want to roll into D4 |
@yanofsky ok will add the generic "feature" and "series" classes to each feature this way you can still style things with CSS and without the need of an afterRender call. I'll update an example on the demo site as well. |
When you use
beforeRender
to filter data and plot different features in the same chart, the classes applied to the series containers are linked to the index in relation to the filtered data not in the original data.For instance both the bars and the line are classed
series0
in this http://visible.io/charts/column/multi-dimension.htmlWe've been binding an index to the data and accessing it in the
afterRender
which is less than idealThe text was updated successfully, but these errors were encountered: