Skip to content
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

Number Line: Extract validation out of scoring #1901

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

Myranae
Copy link
Contributor

@Myranae Myranae commented Nov 21, 2024

Summary:

To complete server-side scoring, we are separating out validation logic from scoring logic. This PR separates that logic and associated tests for the number line widget.

Issue: LEMS-2608

Test plan:

  • Confirm checks pass
  • Confirm widget still works as expected
  • Confirm changing the flow of validation and scoring does not affect user experience

Rename state to userInput
Rename rubric to scoringData
Rename rubric type
Add check for null return on validation pass
Remove test helpers
Rename rubric to scoringData
Update scoringData type to union with ValidationData
@Myranae Myranae self-assigned this Nov 21, 2024
Copy link
Contributor

npm Snapshot: Published

Good news!! We've packaged up the latest commit from this PR (47f4c3f) and published it to npm. You
can install it using the tag PR1901.

Example:

yarn add @khanacademy/perseus@PR1901

If you are working in Khan Academy's webapp, you can run:

./dev/tools/bump_perseus_version.sh -t PR1901

Copy link
Contributor

Size Change: +128 B (+0.01%)

Total Size: 1.29 MB

Filename Size Change
packages/perseus/dist/es/index.js 425 kB +128 B (+0.03%)
ℹ️ View Unchanged
Filename Size
packages/kas/dist/es/index.js 39 kB
packages/keypad-context/dist/es/index.js 760 B
packages/kmath/dist/es/index.js 4.27 kB
packages/math-input/dist/es/index.js 77.9 kB
packages/math-input/dist/es/strings.js 1.79 kB
packages/perseus-core/dist/es/index.js 1.48 kB
packages/perseus-editor/dist/es/index.js 698 kB
packages/perseus-linter/dist/es/index.js 22.2 kB
packages/perseus/dist/es/strings.js 3.57 kB
packages/pure-markdown/dist/es/index.js 3.66 kB
packages/simple-markdown/dist/es/index.js 12.5 kB

compressed-size-action

Comment on lines -26 to -27
// TODO: I don't think isTickCrtl is a thing anymore
if (state.isTickCrtl && outsideAllowedRange) {
Copy link
Contributor Author

@Myranae Myranae Nov 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing when exercises allow users to set their own interval, then this check was necessary in case they put in an invalid number of divisions.

I checked the number line editor, and it still has a checkbox for isTickCrtl and the json still has the field (though it defaults to not being there). I tried removing state.isTickCrtl from line 27 and all the tests still pass. It doesn't look like it is referenced anywhere other than tests and this line here. Wouldn't this always be false if isTickCrtl is not in use? Maybe this validation check hasn't been working?

Or maybe this check is not necessary if we are no longer allowing the user to set their own tick interval. It is possible to turn this to true in the editor, so I think we should only remove it if that checkbox ever gets removed, just in case it has been set to true in the past or in case anyone sets it to true in the future.

I don't think this property should be on userInput though. Should we move it to validationData? Should there be any tests making sure things work with or without this value?

Comment on lines -41 to -47
if (state.numLinePosition === start && state.rel === startRel) {
// We're where we started.
return {
type: "invalid",
message: null,
};
}
Copy link
Contributor Author

@Myranae Myranae Nov 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's necessary to do this check after checking if the user got it right. If the user tries to check their answer and they have not moved the dot, then it should probably be invalid. This might not be the case if the first tick could possibly be the right answer. Might be good to check with content before landing this change since this validation check gets moved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant