Add Grouped Bar Graph #65
Loading…
Reference in New Issue
No description provided.
Delete Branch "a258wang-double-bar-graph"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #2
Notes:
laziesteasiest way to implement it.Staging doesn't seem to be reflecting the latest commit. 🤔
Hmmm... staging issue is very strange .... 🤔
Nice work!!
Its unfortunate that a lot of code is repeated for the horizontal and vertical, but there is not much we can do about this, lets merge this so we can get closer to finishing! We can always refactor for later iterations of the class profile. I flagged some confusing parts for me when reading, if we comment the confusing parts a bit more to clear things up a bit it would help for future people who might want to refactor these components.
(Also, what was the reason that we need both a horizontal and a vertical one again? I would think just one would have been enough.)
@ -0,0 +11,4 @@
.barText {
visibility: hidden;
font-family: "Inconsolata", monospace;
Do we need to manually set the font here? Do the fonts set in
_app.css
not apply? It's unforntunate if we do, since incase we ever need to change the font in the future, it will require changing all these too :(Yes, unfortunately it looks like we need to specify the font or else visx will default to Arial or some other font that we don't want. I'll create a ticket to factor out the font-family into a CSS variable that we can use throughout the site for cases like this.
@ -0,0 +427,4 @@
{data.map((d, idx) => {
const barName = `${getCategory(d)}-${idx}`;
const barWidth = categoryScale.bandwidth();
const backgroundBarWidth = barWidth / (1 - barPadding);
What if
barPadding=1
or barPadding > 1? I think we should put a comment above where we defined barPadding:Same comment applies to the component above as well.
@ -0,0 +435,4 @@
x={0}
y={
// eslint-disable-next-line @typescript-eslint/no-non-null-assertion
categoryScale(getCategory(d))! -
is it possible for this to actually fail due to bad user data or is the ts compiler just being dumb?
The way the code is written, this shouldn't ever be null. The TS compiler is smart, but not smart enough to detect this.
We should probably consider disabling the ESLint no-non-null-assertion rule since I don't think our team has a tendency to abuse non-null assertions.
@ -0,0 +564,4 @@
isHorizontal?: boolean;
}
function HoverableBar(props: HoverableBarProps) {
Nice, smart to factor this component out!
@ -0,0 +593,4 @@
width={bar.width}
height={bar.height}
fill={isHovered && hoverFillColor ? hoverFillColor : bar.color}
filter={isHovered ? `url(#glow-${colorId})` : undefined}
could we leave a quick comment here explaining what the
url(#glow-${colorId})
is?@ -0,0 +597,4 @@
/>
<Text
className={styles.barText}
x={isHorizontal ? bar.width - 12 : bar.x + bar.width / 2}
Pretty confusing for me, for example why the magic number - 12 here? I think it would be better if that was extracted into a constant, which would shed some light on to why we need to - 12.
a0be0f993f
toab5161d977
More like a just in case, I guess lol.