I'm using the d3 axis component but I want to tweak a few things after it is drawn. Specifically I would like to rotate the text labels by adding a transform to the text elements and also setting the text-anchor attribute from "middle" to "end".
The problem I'm hitting is that the text-anchor attribute seems to be set asynchronously by the d3 code as part of the transition. When I set the value to "end" in my code it subsequently gets set back to "middle" when the transition runs.
If I wait until transition end before making my change it's going to look choppy. What I'm wondering is if there is a way to insert myself into the process of drawing and transitioning the axis such that my text-anchor value will be used instead of the default one?
I believe this constitutes a bug in the axis component, so I've created a pull request to update label attributes immediately rather than as part of the axis transition. The text element's text-anchor attribute can't be interpolated, so there's no reason to defer the update to the transition, and setting it immediately makes it easy for you to fix it using post-selection.
An alternate fix would be to extend the axis component to support different styles of tick labeling. This way, you wouldn't need to use post-selection, so there's no conflict with the axis transition.
This seems something that can't be overridden from the API. A simple but hacky solution would be setting it in your stylesheet...
.x.axis text {
text-anchor: end !important;
}
Related
We need to make it move like here.example The code is complex there, I can't figure it out.
I wrote the code my code, but I don’t understand how to make the tooltip move horizontally not behind the mouse, but near the nearest horizontal mark (as in the example)
It is not yet clear where the text above the bold text in the tooltip comes from. How to remove it so that it looks like in the picture?
How do I make the title of the tooltip match the label on the X-axis?
There are many ways to accomplish this. The way I typically do this is to create a series of SVG elements -- such as circles or rects -- using the same scale and data as the paths.
You can make these objects visible or invisible. Either way, you can attach mouseenter, mouseleave events to each to render and populate the tooltip.
I am trying to adapt Bo Ericsson's D3 realTimeChartMulti example to a particular use, and I need to add a gridline where each category appears. I have not been able to figure out how to do that using his code.
https://bl.ocks.org/boeric/6a83de20f780b42fadb9
Does anyone have any idea how to do it? Everything I've tried (manipulating the D3 y axis to add ticks(5) would be the simplest alternative, as a start) causes the display to stop rendering altogether.
The simplest way to add a gridline is setting the innerTickSize() method (tickSizeInner in v4/5), which in your case would be:
yAxis = d3.svg.axis().orient("left").innerTickSize(-width);
Then, you can style it the way you want in the CSS by selecting a line with the y and axis classes (here I'm using a dashed line). Alternatively, you can apply the style straight to the group selection (append the axis first, and then append the circles).
Finally, you can see that the circles are behind the gridline, which is not a very elegant design. You can change that by changing the order of the appended elements.
Here is the forked code: http://bl.ocks.org/GerardoFurtado/2eaffbb3437acb62f66a7b6cb85bf435/3042a5357cbc703dcf102c733b7b5772b82d744c
I am trying to modify Bullet Charts example of dimple.js with each bullet chart being in a child-svg of the parent-svg. Purpose of having individual svg for each bullet chart is to make their management (show/hide/remove) easier. Also, this makes the recursive definition of a chart complete - That is, a chart is contained by an svg.
The fiddle for the modified version is here....
As you can see, from 2nd chart onwards, on mouse hover, tool tips go out of place!!! Please note that, for child-svg, I've set the style overflow: visible without which tool-tips were not visible at all.
Want to know if I am missing anything in handling the attributes of child-svg elements or is it a bug in dimple.js. Also, please let me know if you know of any workaround.
Thanks.
One of the first questions I have is why do you want child svg elements? What are you trying to accomplish?
The only difference I see in your code and the example is the height / width swap at the top and the sub svg + bounds.
Keep in mind that the origin changes with each sub-svg. This might be why you are having trouble with the tool-tips. Maybe you have that worked into your add-bullet calls.
I think nagu has the right approach here if you really want separate svg elements.
I'm using Segment Plot to show multiple lines on the chart. How can I make these lines have arrows on their ends?
You can do this with some SVG + DOM hacking. You can define a "marker element" that can be placed at the beginning, middle or end of a line (see http://tutorials.jenkov.com/svg/marker-element.html for details on markers).
This means manipulating the SVG generated by Plottable. To get the underlying DOM elements, you need to get hold of the d3 "selection" representing each line.
Add a marker definition to the <svg> element where you are rendering the plot. I am pretty sure plottable won't overwrite entities already inside, but if it does you can always add it after rendering the plot.
Use Segment#entities to get all "PlotEntity" objects from the plot (http://plottablejs.org/docs/classes/plottable.plots.segment.html#entities).
Use the PlotEntity#selection property (http://plottablejs.org/docs/interfaces/plottable.plots.plotentity.html#selection) to get the set of DOM elements representing each segment.
The "Selection" interface is just a d3 selection (https://github.com/mbostock/d3/wiki/Selections). You can then add the appropriate "marker-end" attribute to each element, which should give you the arrow heads you want.
On the off-chance these lines are vertical, I have a super easy hack. Use .symbol() to create a scatter plot where the points are either up or down arrows, and place them at the ends of the segments.
Otherwise, you may have to draw the arrows yourself. You can get the pixel locations of the ends of the segments like this:
locX = xScale.invert(endpointXValue)
locY = yScale.invert(endpointYValue)
And then you could append an arrow shape to the foreground (see the crosshair container in this example)
I'm creating an example illustrating a layout with resizeable cells using the D3 drag behaviour and CSS {display: table} styles. It works fine for dragging horizontally, but not vertically. For vertical resizing, d3.event.y is providing values that do not make sense to me.
Here is a fiddle showing the working horizontal drag and the broken vertical drag. Take a look at the console output while dragging to see that the values returned by d3.event match the values returned by d3.mouse() for the horizontal drag, but they diverge for the vertical drag.
I can fix the behaviour by using the d3.mouse() y-coordinate instead of the d3.event y-coordinate. To see this, comment out the "DOESN'T WORK" line and uncomment the "WORKS" line. However, I don't understand why I need to do this, and it seems less general in that I have to assume a mouse input instead of using the more generic d3.event.
Is this a bug, or am I failing to understand something here?
Note that this question seems to be hitting the same issue, but using HTML tables instead of CSS tables. I thought it would be helpful to document that this problem is occurring in both contexts.
Also note that commenting out the two lines that actually do the vertical resizing, commented with "RESIZE CELLS", makes the d3.event work correctly. Of course, the table doesn't get resized then. This suggests that it is something about the act of resizing the divs that is leading d3.event astray.
Alright, I think I've figured out the issue. If you look at the code for drag behavior, you'll notice in dragstart that the value used to calculate the mouse offset is based off this.parentNode. In short, it uses this.parentNode as a reference point, and assumes that it's going to be stable for the duration of the drag. You're modifying the parent nodes during the drag, so its reference point gets, to put it technically, pretty borked. In this case, using d3.mouse is your best bet, since d3.event.y is only going to be reliable as long as the parent node stays in place.
The reason this only happens in the y direction for you is that the x position of all the rows, which are the parent nodes here, stay constant, whereas the y component changes during the drag.
The relevant code sections:
parent = that.parentNode,
function moved() {
var position1 = position(parent, dragId), dx, dy;
//...
dispatch({
type: "drag",
x: position1[0] + dragOffset[0],
y: position1[1] + dragOffset[1],
dx: dx,
dy: dy
});