2020-06-26 02:42:10 +02:00
|
|
|
// Copyright: Ankitects Pty Ltd and contributors
|
|
|
|
// License: GNU AGPL, version 3 or later; http://www.gnu.org/licenses/agpl.html
|
|
|
|
|
|
|
|
/* eslint
|
|
|
|
@typescript-eslint/no-non-null-assertion: "off",
|
|
|
|
@typescript-eslint/no-explicit-any: "off",
|
|
|
|
*/
|
|
|
|
|
refactor protobuf handling for split/import
In order to split backend.proto into a more manageable size, the protobuf
handling needed to be updated. This took more time than I would have
liked, as each language handles protobuf differently:
- The Python Protobuf code ignores "package" directives, and relies
solely on how the files are laid out on disk. While it would have been
nice to keep the generated files in a private subpackage, Protobuf gets
confused if the files are located in a location that does not match
their original .proto layout, so the old approach of storing them in
_backend/ will not work. They now clutter up pylib/anki instead. I'm
rather annoyed by that, but alternatives seem to be having to add an extra
level to the Protobuf path, making the other languages suffer, or trying
to hack around the issue by munging sys.modules.
- Protobufjs fails to expose packages if they don't start with a capital
letter, despite the fact that lowercase packages are the norm in most
languages :-( This required a patch to fix.
- Rust was the easiest, as Prost is relatively straightforward compared
to Google's tools.
The Protobuf files are now stored in /proto/anki, with a separate package
for each file. I've split backend.proto into a few files as a test, but
the majority of that work is still to come.
The Python Protobuf building is a bit of a hack at the moment, hard-coding
"proto" as the top level folder, but it seems to get the job done for now.
Also changed the workspace name, as there seems to be a number of Bazel
repos moving away from the more awkward reverse DNS naming style.
2021-07-10 09:50:18 +02:00
|
|
|
import { Backend } from "lib/proto";
|
2021-03-26 11:23:43 +01:00
|
|
|
|
2021-01-30 01:13:47 +01:00
|
|
|
import {
|
|
|
|
interpolateRdYlGn,
|
|
|
|
select,
|
|
|
|
pointer,
|
|
|
|
scaleLinear,
|
|
|
|
scaleBand,
|
|
|
|
scaleSequential,
|
|
|
|
axisBottom,
|
|
|
|
axisLeft,
|
|
|
|
sum,
|
|
|
|
} from "d3";
|
2020-06-26 02:42:10 +02:00
|
|
|
import { showTooltip, hideTooltip } from "./tooltip";
|
2020-07-17 05:46:06 +02:00
|
|
|
import {
|
|
|
|
GraphBounds,
|
|
|
|
setDataAvailable,
|
|
|
|
GraphRange,
|
|
|
|
millisecondCutoffForRange,
|
2020-11-01 05:26:58 +01:00
|
|
|
} from "./graph-helpers";
|
2021-04-22 19:55:26 +02:00
|
|
|
import * as tr from "lib/i18n";
|
2020-06-26 02:42:10 +02:00
|
|
|
|
|
|
|
type ButtonCounts = [number, number, number, number];
|
|
|
|
|
|
|
|
export interface GraphData {
|
|
|
|
learning: ButtonCounts;
|
|
|
|
young: ButtonCounts;
|
|
|
|
mature: ButtonCounts;
|
|
|
|
}
|
|
|
|
|
refactor protobuf handling for split/import
In order to split backend.proto into a more manageable size, the protobuf
handling needed to be updated. This took more time than I would have
liked, as each language handles protobuf differently:
- The Python Protobuf code ignores "package" directives, and relies
solely on how the files are laid out on disk. While it would have been
nice to keep the generated files in a private subpackage, Protobuf gets
confused if the files are located in a location that does not match
their original .proto layout, so the old approach of storing them in
_backend/ will not work. They now clutter up pylib/anki instead. I'm
rather annoyed by that, but alternatives seem to be having to add an extra
level to the Protobuf path, making the other languages suffer, or trying
to hack around the issue by munging sys.modules.
- Protobufjs fails to expose packages if they don't start with a capital
letter, despite the fact that lowercase packages are the norm in most
languages :-( This required a patch to fix.
- Rust was the easiest, as Prost is relatively straightforward compared
to Google's tools.
The Protobuf files are now stored in /proto/anki, with a separate package
for each file. I've split backend.proto into a few files as a test, but
the majority of that work is still to come.
The Python Protobuf building is a bit of a hack at the moment, hard-coding
"proto" as the top level folder, but it seems to get the job done for now.
Also changed the workspace name, as there seems to be a number of Bazel
repos moving away from the more awkward reverse DNS naming style.
2021-07-10 09:50:18 +02:00
|
|
|
const ReviewKind = Backend.RevlogEntry.ReviewKind;
|
2020-06-26 02:42:10 +02:00
|
|
|
|
refactor protobuf handling for split/import
In order to split backend.proto into a more manageable size, the protobuf
handling needed to be updated. This took more time than I would have
liked, as each language handles protobuf differently:
- The Python Protobuf code ignores "package" directives, and relies
solely on how the files are laid out on disk. While it would have been
nice to keep the generated files in a private subpackage, Protobuf gets
confused if the files are located in a location that does not match
their original .proto layout, so the old approach of storing them in
_backend/ will not work. They now clutter up pylib/anki instead. I'm
rather annoyed by that, but alternatives seem to be having to add an extra
level to the Protobuf path, making the other languages suffer, or trying
to hack around the issue by munging sys.modules.
- Protobufjs fails to expose packages if they don't start with a capital
letter, despite the fact that lowercase packages are the norm in most
languages :-( This required a patch to fix.
- Rust was the easiest, as Prost is relatively straightforward compared
to Google's tools.
The Protobuf files are now stored in /proto/anki, with a separate package
for each file. I've split backend.proto into a few files as a test, but
the majority of that work is still to come.
The Python Protobuf building is a bit of a hack at the moment, hard-coding
"proto" as the top level folder, but it seems to get the job done for now.
Also changed the workspace name, as there seems to be a number of Bazel
repos moving away from the more awkward reverse DNS naming style.
2021-07-10 09:50:18 +02:00
|
|
|
export function gatherData(data: Backend.GraphsResponse, range: GraphRange): GraphData {
|
2020-07-17 05:46:06 +02:00
|
|
|
const cutoff = millisecondCutoffForRange(range, data.nextDayAtSecs);
|
2020-06-26 02:42:10 +02:00
|
|
|
const learning: ButtonCounts = [0, 0, 0, 0];
|
|
|
|
const young: ButtonCounts = [0, 0, 0, 0];
|
|
|
|
const mature: ButtonCounts = [0, 0, 0, 0];
|
|
|
|
|
refactor protobuf handling for split/import
In order to split backend.proto into a more manageable size, the protobuf
handling needed to be updated. This took more time than I would have
liked, as each language handles protobuf differently:
- The Python Protobuf code ignores "package" directives, and relies
solely on how the files are laid out on disk. While it would have been
nice to keep the generated files in a private subpackage, Protobuf gets
confused if the files are located in a location that does not match
their original .proto layout, so the old approach of storing them in
_backend/ will not work. They now clutter up pylib/anki instead. I'm
rather annoyed by that, but alternatives seem to be having to add an extra
level to the Protobuf path, making the other languages suffer, or trying
to hack around the issue by munging sys.modules.
- Protobufjs fails to expose packages if they don't start with a capital
letter, despite the fact that lowercase packages are the norm in most
languages :-( This required a patch to fix.
- Rust was the easiest, as Prost is relatively straightforward compared
to Google's tools.
The Protobuf files are now stored in /proto/anki, with a separate package
for each file. I've split backend.proto into a few files as a test, but
the majority of that work is still to come.
The Python Protobuf building is a bit of a hack at the moment, hard-coding
"proto" as the top level folder, but it seems to get the job done for now.
Also changed the workspace name, as there seems to be a number of Bazel
repos moving away from the more awkward reverse DNS naming style.
2021-07-10 09:50:18 +02:00
|
|
|
for (const review of data.revlog as Backend.RevlogEntry[]) {
|
2020-07-17 05:46:06 +02:00
|
|
|
if (cutoff && (review.id as number) < cutoff) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2020-06-26 02:42:10 +02:00
|
|
|
let buttonNum = review.buttonChosen;
|
|
|
|
if (buttonNum <= 0 || buttonNum > 4) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
let buttons = learning;
|
|
|
|
switch (review.reviewKind) {
|
|
|
|
case ReviewKind.LEARNING:
|
|
|
|
case ReviewKind.RELEARNING:
|
|
|
|
// V1 scheduler only had 3 buttons in learning
|
|
|
|
if (buttonNum === 4 && data.schedulerVersion === 1) {
|
|
|
|
buttonNum = 3;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case ReviewKind.REVIEW:
|
|
|
|
case ReviewKind.EARLY_REVIEW:
|
|
|
|
if (review.lastInterval < 21) {
|
|
|
|
buttons = young;
|
|
|
|
} else {
|
|
|
|
buttons = mature;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
buttons[buttonNum - 1] += 1;
|
|
|
|
}
|
|
|
|
return { learning, young, mature };
|
|
|
|
}
|
|
|
|
|
2020-07-06 08:21:51 +02:00
|
|
|
type GroupKind = "learning" | "young" | "mature";
|
|
|
|
|
2020-06-26 02:42:10 +02:00
|
|
|
interface Datum {
|
2020-07-06 08:21:51 +02:00
|
|
|
buttonNum: number;
|
|
|
|
group: GroupKind;
|
2020-06-26 02:42:10 +02:00
|
|
|
count: number;
|
|
|
|
}
|
|
|
|
|
2020-07-06 08:21:51 +02:00
|
|
|
interface TotalCorrect {
|
|
|
|
total: number;
|
|
|
|
correct: number;
|
|
|
|
percent: string;
|
|
|
|
}
|
|
|
|
|
2020-06-26 02:42:10 +02:00
|
|
|
export function renderButtons(
|
|
|
|
svgElem: SVGElement,
|
|
|
|
bounds: GraphBounds,
|
refactor protobuf handling for split/import
In order to split backend.proto into a more manageable size, the protobuf
handling needed to be updated. This took more time than I would have
liked, as each language handles protobuf differently:
- The Python Protobuf code ignores "package" directives, and relies
solely on how the files are laid out on disk. While it would have been
nice to keep the generated files in a private subpackage, Protobuf gets
confused if the files are located in a location that does not match
their original .proto layout, so the old approach of storing them in
_backend/ will not work. They now clutter up pylib/anki instead. I'm
rather annoyed by that, but alternatives seem to be having to add an extra
level to the Protobuf path, making the other languages suffer, or trying
to hack around the issue by munging sys.modules.
- Protobufjs fails to expose packages if they don't start with a capital
letter, despite the fact that lowercase packages are the norm in most
languages :-( This required a patch to fix.
- Rust was the easiest, as Prost is relatively straightforward compared
to Google's tools.
The Protobuf files are now stored in /proto/anki, with a separate package
for each file. I've split backend.proto into a few files as a test, but
the majority of that work is still to come.
The Python Protobuf building is a bit of a hack at the moment, hard-coding
"proto" as the top level folder, but it seems to get the job done for now.
Also changed the workspace name, as there seems to be a number of Bazel
repos moving away from the more awkward reverse DNS naming style.
2021-07-10 09:50:18 +02:00
|
|
|
origData: Backend.GraphsResponse,
|
2020-07-17 05:46:06 +02:00
|
|
|
range: GraphRange
|
2020-06-26 02:42:10 +02:00
|
|
|
): void {
|
2020-07-17 05:46:06 +02:00
|
|
|
const sourceData = gatherData(origData, range);
|
2020-06-26 02:42:10 +02:00
|
|
|
const data = [
|
|
|
|
...sourceData.learning.map((count: number, idx: number) => {
|
|
|
|
return {
|
2020-07-06 08:21:51 +02:00
|
|
|
buttonNum: idx + 1,
|
2020-06-26 02:42:10 +02:00
|
|
|
group: "learning",
|
|
|
|
count,
|
|
|
|
} as Datum;
|
|
|
|
}),
|
|
|
|
...sourceData.young.map((count: number, idx: number) => {
|
|
|
|
return {
|
2020-07-06 08:21:51 +02:00
|
|
|
buttonNum: idx + 1,
|
2020-06-26 02:42:10 +02:00
|
|
|
group: "young",
|
|
|
|
count,
|
|
|
|
} as Datum;
|
|
|
|
}),
|
|
|
|
...sourceData.mature.map((count: number, idx: number) => {
|
|
|
|
return {
|
2020-07-06 08:21:51 +02:00
|
|
|
buttonNum: idx + 1,
|
2020-06-26 02:42:10 +02:00
|
|
|
group: "mature",
|
|
|
|
count,
|
|
|
|
} as Datum;
|
|
|
|
}),
|
|
|
|
];
|
|
|
|
|
2020-07-06 08:21:51 +02:00
|
|
|
const totalCorrect = (kind: GroupKind): TotalCorrect => {
|
|
|
|
const groupData = data.filter((d) => d.group == kind);
|
|
|
|
const total = sum(groupData, (d) => d.count);
|
|
|
|
const correct = sum(
|
|
|
|
groupData.filter((d) => d.buttonNum > 1),
|
|
|
|
(d) => d.count
|
|
|
|
);
|
|
|
|
const percent = total ? ((correct / total) * 100).toFixed(2) : "0";
|
|
|
|
return { total, correct, percent };
|
|
|
|
};
|
|
|
|
|
2020-06-26 02:42:10 +02:00
|
|
|
const yMax = Math.max(...data.map((d) => d.count));
|
|
|
|
|
|
|
|
const svg = select(svgElem);
|
|
|
|
const trans = svg.transition().duration(600) as any;
|
|
|
|
|
2020-07-06 06:01:49 +02:00
|
|
|
if (!yMax) {
|
|
|
|
setDataAvailable(svg, false);
|
|
|
|
return;
|
|
|
|
} else {
|
|
|
|
setDataAvailable(svg, true);
|
|
|
|
}
|
|
|
|
|
2020-06-26 02:42:10 +02:00
|
|
|
const xGroup = scaleBand()
|
|
|
|
.domain(["learning", "young", "mature"])
|
|
|
|
.range([bounds.marginLeft, bounds.width - bounds.marginRight]);
|
2021-04-02 05:25:38 +02:00
|
|
|
svg.select<SVGGElement>(".x-ticks")
|
|
|
|
.call((selection) =>
|
|
|
|
selection.transition(trans).call(
|
|
|
|
axisBottom(xGroup)
|
|
|
|
.tickFormat(((d: GroupKind) => {
|
|
|
|
let kind: string;
|
|
|
|
switch (d) {
|
|
|
|
case "learning":
|
|
|
|
kind = tr.statisticsCountsLearningCards();
|
|
|
|
break;
|
|
|
|
case "young":
|
|
|
|
kind = tr.statisticsCountsYoungCards();
|
|
|
|
break;
|
|
|
|
case "mature":
|
|
|
|
default:
|
|
|
|
kind = tr.statisticsCountsMatureCards();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return `${kind} \u200e(${totalCorrect(d).percent}%)`;
|
|
|
|
}) as any)
|
|
|
|
.tickSizeOuter(0)
|
|
|
|
)
|
2021-03-21 13:47:52 +01:00
|
|
|
)
|
2021-04-02 05:25:38 +02:00
|
|
|
.attr("direction", "ltr");
|
2020-06-26 02:42:10 +02:00
|
|
|
|
|
|
|
const xButton = scaleBand()
|
|
|
|
.domain(["1", "2", "3", "4"])
|
|
|
|
.range([0, xGroup.bandwidth()])
|
|
|
|
.paddingOuter(1)
|
|
|
|
.paddingInner(0.1);
|
|
|
|
|
|
|
|
const colour = scaleSequential(interpolateRdYlGn).domain([1, 4]);
|
|
|
|
|
|
|
|
// y scale
|
|
|
|
|
|
|
|
const y = scaleLinear()
|
|
|
|
.range([bounds.height - bounds.marginBottom, bounds.marginTop])
|
|
|
|
.domain([0, yMax]);
|
2021-04-02 05:25:38 +02:00
|
|
|
svg.select<SVGGElement>(".y-ticks")
|
|
|
|
.call((selection) =>
|
|
|
|
selection.transition(trans).call(
|
|
|
|
axisLeft(y)
|
|
|
|
.ticks(bounds.height / 50)
|
|
|
|
.tickSizeOuter(0)
|
|
|
|
)
|
2021-03-21 13:47:52 +01:00
|
|
|
)
|
2021-04-02 05:25:38 +02:00
|
|
|
.attr("direction", "ltr");
|
2020-06-26 02:42:10 +02:00
|
|
|
|
|
|
|
// x bars
|
|
|
|
|
|
|
|
const updateBar = (sel: any): any => {
|
|
|
|
return sel
|
|
|
|
.attr("width", xButton.bandwidth())
|
2020-08-05 07:56:21 +02:00
|
|
|
.attr("opacity", 0.8)
|
2020-06-26 02:42:10 +02:00
|
|
|
.transition(trans)
|
2020-07-06 08:21:51 +02:00
|
|
|
.attr(
|
|
|
|
"x",
|
|
|
|
(d: Datum) => xGroup(d.group)! + xButton(d.buttonNum.toString())!
|
|
|
|
)
|
2020-06-26 02:42:10 +02:00
|
|
|
.attr("y", (d: Datum) => y(d.count)!)
|
2020-09-29 14:13:25 +02:00
|
|
|
.attr("height", (d: Datum) => y(0)! - y(d.count)!)
|
2020-07-06 08:21:51 +02:00
|
|
|
.attr("fill", (d: Datum) => colour(d.buttonNum));
|
2020-06-26 02:42:10 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
svg.select("g.bars")
|
|
|
|
.selectAll("rect")
|
|
|
|
.data(data)
|
|
|
|
.join(
|
|
|
|
(enter) =>
|
|
|
|
enter
|
|
|
|
.append("rect")
|
|
|
|
.attr("rx", 1)
|
2020-07-06 08:21:51 +02:00
|
|
|
.attr(
|
|
|
|
"x",
|
|
|
|
(d: Datum) =>
|
|
|
|
xGroup(d.group)! + xButton(d.buttonNum.toString())!
|
|
|
|
)
|
2020-09-29 14:13:25 +02:00
|
|
|
.attr("y", y(0)!)
|
2020-06-26 02:42:10 +02:00
|
|
|
.attr("height", 0)
|
|
|
|
.call(updateBar),
|
|
|
|
(update) => update.call(updateBar),
|
|
|
|
(remove) =>
|
|
|
|
remove.call((remove) =>
|
2020-09-29 14:13:25 +02:00
|
|
|
remove.transition(trans).attr("height", 0).attr("y", y(0)!)
|
2020-06-26 02:42:10 +02:00
|
|
|
)
|
|
|
|
);
|
|
|
|
|
|
|
|
// hover/tooltip
|
2020-06-28 12:52:38 +02:00
|
|
|
|
|
|
|
function tooltipText(d: Datum): string {
|
2021-03-26 11:23:43 +01:00
|
|
|
const button = tr.statisticsAnswerButtonsButtonNumber();
|
|
|
|
const timesPressed = tr.statisticsAnswerButtonsButtonPressed();
|
|
|
|
const correctStr = tr.statisticsHoursCorrect(totalCorrect(d.group));
|
2020-07-06 08:21:51 +02:00
|
|
|
return `${button}: ${d.buttonNum}<br>${timesPressed}: ${d.count}<br>${correctStr}`;
|
2020-06-28 12:52:38 +02:00
|
|
|
}
|
|
|
|
|
2021-03-21 10:58:39 +01:00
|
|
|
svg.select("g.hover-columns")
|
2020-06-26 02:42:10 +02:00
|
|
|
.selectAll("rect")
|
|
|
|
.data(data)
|
|
|
|
.join("rect")
|
2020-07-06 08:21:51 +02:00
|
|
|
.attr("x", (d: Datum) => xGroup(d.group)! + xButton(d.buttonNum.toString())!)
|
2020-09-29 14:13:25 +02:00
|
|
|
.attr("y", () => y(yMax!)!)
|
2020-06-26 02:42:10 +02:00
|
|
|
.attr("width", xButton.bandwidth())
|
2020-09-29 14:13:25 +02:00
|
|
|
.attr("height", () => y(0)! - y(yMax!)!)
|
2021-01-30 01:13:47 +01:00
|
|
|
.on("mousemove", (event: MouseEvent, d: Datum) => {
|
2021-01-30 02:35:33 +01:00
|
|
|
const [x, y] = pointer(event, document.body);
|
2020-06-26 02:42:10 +02:00
|
|
|
showTooltip(tooltipText(d), x, y);
|
|
|
|
})
|
|
|
|
.on("mouseout", hideTooltip);
|
|
|
|
}
|