-
Notifications
You must be signed in to change notification settings - Fork 350
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
Enable parsePerseusItem to handle all published Perseus content #2082
base: main
Are you sure you want to change the base?
Conversation
npm Snapshot: NOT PublishedOh noes!! We couldn't publish an npm snapshot for you because |
]; | ||
// If `coords` is null, the graph will not be gradable. All answers | ||
// will be scored as invalid. | ||
coords: null | [vertex: Coord, secondPoint: Coord]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no way to default coords sensibly if it's missing, since it represents the correct answer. The widget renders fine with null coords, but scoring threw an exception. I've fixed the exception by returning a score of "invalid" if correct.coords is null (see score-grapher.ts below).
Size Change: +80 B (+0.01%) Total Size: 1.27 MB
ℹ️ View Unchanged
|
[-5, 5], | ||
[5, 5], | ||
] as [[number, number], [number, number]], | ||
), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I previously thought we could default coords
here, but thought better of it. This default isn't appropriate if the graph's X and Y ranges aren't the defaults ([-10, 10]).
@@ -17,7 +17,14 @@ import type {Parser} from "../parser-types"; | |||
export const parseMeasurerWidget: Parser<MeasurerWidget> = parseWidget( | |||
constant("measurer"), | |||
object({ | |||
image: parsePerseusImageBackground, | |||
// The default value for image comes from measurer.tsx. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding these comments in! I think they'll be really helpful going forward.
@@ -34,6 +34,29 @@ describe("parseWidgetsMap", () => { | |||
expect(result).toEqual(anyFailure); | |||
}); | |||
|
|||
it("rejects a key with ID 0", () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We usually refer to this value as the widget Id and not the "key". I think it's a useful differentiation because it avoids being conflated with a React component key.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the parts of a widget ID called, then? If the widget ID is something like radio 1
, what is the radio
part called and what is the 1
part called?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm just going to call it the "widget number".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
radio
is the widget type (in some places its referred to as the widget name).
radio 1
is the widget id and I've been working hard to avoid folks thinking of them as being "made up" of a type and number, but rather that we push for them to be opaque identifiers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, well, they're definitely not treated as opaque currently, because if the number is 0 the entire page crashes. I've tried to avoid referring directly to the number in the tests and variable names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, we do parse these widget ids in places, but I feel it's a thing we should avoid and remove when we can. Interpreting IDs as informative structures has bit me many times in the past when needs cause us to change the ID in some way. We hit this during Goliath when we assumed that KAIDs were of a specific format (legacy IDs weren't of that format).
it was unused, and it was null in some data which caused parse errors.
…ished content and upgrade old versions to the current format.
da0ce42
to
1fe6e42
Compare
This PR fixes the remaining cases where the parser couldn't handle some data in
our content corpus -- notably, in articles and international content. After this
PR is merged, we will be able to use the parser in Webapp!
Note that running the exhaustive test tool still produces some failures.
However, I suspect the failing content isn't published, because it either
doesn't render (crashes the page) or can't be scored (throws an exception when
you click the "check answer" button). We'll find out when we start logging
parser errors in production whether I'm right about this.
The remaining errors are:
Issue: LEMS-2582
Test plan:
yarn test