-
Notifications
You must be signed in to change notification settings - Fork 351
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
Migrate expression widget to latest version in PerseusItem parser #1908
Conversation
GeraldRequired Reviewers
Don't want to be involved in this pull request? Comment |
npm Snapshot: PublishedGood news!! We've packaged up the latest commit from this PR (44fc32c) and published it to npm. You Example: yarn add @khanacademy/perseus@PR1908 If you are working in Khan Academy's webapp, you can run: ./dev/tools/bump_perseus_version.sh -t PR1908 |
Size Change: +261 B (+0.02%) Total Size: 1.29 MB
ℹ️ View Unchanged
|
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.
Nice. I like how this PR is starting to work out the upgrade/migration ideas.
} | ||
|
||
export const parseExpressionWidget: Parser<ExpressionWidget> = | ||
union(pipeParsers(parseExpressionWidgetV0).then(migrateV0ToLatest).parser) |
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.
So this will attempt to parse using the v0 and migration parsers and fall back to the parseExpressionWidgetLatest
if that fails, right?
This might be extremely over-the-top optimization, but I wonder if we should order these in the opposite order given we'll more likely get a latest version set of options rather than v0 options? 🤔
d6697a2
to
b0ed10b
Compare
f85fe16
to
0e29951
Compare
This demonstrates how we can upgrade/migrate widget options in the parsing
code, obviating the need for
propUpgrades
.The fact that
version
is an object makes this really annoying becauseTypeScript can't discriminate unions based on nested properties like
version.major
. Given that constraint, I think the approach I came up with isreasonable, but I'm certainly open to feedback on how to improve it.
Issue: LEMS-2582
Test plan:
yarn test