refactor: locked polygon points shape#3705
Conversation
npm Snapshot: PublishedGood news!! We've packaged up the latest commit from this PR (815a548) and published it to npm. You Example: pnpm add @khanacademy/perseus@PR3705If you are working in Khan Academy's frontend, you can run the below command. ./dev/tools/bump_perseus_version.ts -t PR3705If you are working in Khan Academy's webapp, you can run the below command. ./dev/tools/bump_perseus_version.js -t PR3705 |
|
Size Change: +184 B (+0.04%) Total Size: 508 kB 📦 View Changed
ℹ️ View Unchanged
|
…ckedPolygonType.points` from `[]Coord` to `LockedPolygonPointType`
…tType to []LockedPolygonPointType
There was a problem hiding this comment.
I think this looks good! Thanks for working on this. I'll also tag @jeremywiebe in case he has any further thoughts on the approach.
We'll need to be very careful deploying this, as we need to give the Content Platform a heads up about the schema change before we do. Otherwise we can break publishing. :) Happy to provide support with deploying if you need any!
| export type LockedPolygonType = { | ||
| type: "polygon"; | ||
| points: Coord[]; | ||
| points: LockedPolygonPointType[]; |
There was a problem hiding this comment.
It might be nice to add a comment here explaining the intention to add more data in the LockedPolygonPointType, but it's not strictly neccessary
There was a problem hiding this comment.
To clarify, I intend on merging the stacked PRs together as one schema change. I will be sure to get the Go schema change deployed first once the target schema is finalized.
jeremywiebe
left a comment
There was a problem hiding this comment.
A few thoughts, but nothing blocking! Thanks Matt!
| {coord: [-8, -7]}, | ||
| {coord: [-8, -3]}, | ||
| {coord: [-4, -3]}, |
There was a problem hiding this comment.
These item-data/ files should never be modified as they represent data imported from production. Instead, create a second file with the new structure(s).
See my comment at the top of this file.
There was a problem hiding this comment.
Ah, thanks for the heads up! I missed the note at the top of the file. Do we need a regression test in this context, or is unit testing the parser enough?
There was a problem hiding this comment.
You should add a new file with this new data format. That way we ensure that our parser remains compatible with all previous known schema versions and supports the new version.
| [-1, 0], | ||
| [1, 0], | ||
| ], | ||
| points: [{coord: [0, 2]}, {coord: [-1, 0]}, {coord: [1, 0]}], |
There was a problem hiding this comment.
nit: I'm not sure if prettier chose this, but the original, multi-line layout reads more easily. No worries if this new inline layout if prettier's choice.
There was a problem hiding this comment.
Prettier doesn't allow:
points: [
{ coord: [1, 1] },
{ coord: [2, 2] },
{ coord: [3, 3] },
],but does allow:
points: [
{
coord: [1, 1],
},
{
coord: [2, 2],
},
{
coord: [3, 3],
},
],which mirrors the labels below, so I'll update it to that.
| expect.objectContaining({ | ||
| type: "polygon", | ||
| points: [...defaultPolygon.points, [0, 0]], | ||
| points: [...defaultPolygon.points, {coord: [0, 0]}], |
There was a problem hiding this comment.
I'm assuming this spread works because defaultPolygon.points has been changed to be an array of these new {coord: [number, number]} format?
There was a problem hiding this comment.
Right! We do that in packages/perseus-core/src/utils/get-default-figure-for-type.ts
| points: squarePolygonPoints | ||
| .slice(1) | ||
| .map((coord) => ({coord})), |
There was a problem hiding this comment.
suggestion: This predates your change, but using the original test data in the assertion is a smell We should inline the values like we do later in this file around lines 1152-1156 (next chunk in this PR)
There was a problem hiding this comment.
Agreed! The assertion has been updated.
| const coords = points.map((point) => point.coord); | ||
| const coordsToPoints = (coords: Coord[]) => | ||
| coords.map((coord) => ({coord})); |
There was a problem hiding this comment.
I haven't looked through all the usages of coords in this area, but I wonder if it'd be cleaner to use the new structure everywhere rather than have to keep dealing with both [number, number] and {x: number, y: number}.
There was a problem hiding this comment.
Agreed! I updated the logic to always derive from the points prop
…ly in locked polygon settings
…ked polygon component
Summary
This is the first PR in a stack to enable per-vertex angle labeling in locked polygons.
LockedPolygonPointTypewith shape{coord: Coord}LockedPolygonType.pointsfrom typeCoord[]toLockedPolygonPointType[]points.coordCoord[]polygon points and normalizing to the new shapeNext steps
LockedPolygonPointTypewith ashowAnglefield that determines whether the angle should be shown for that point (feat: addshowAnglefield toLockedPolygonPointType#3730)LockedPolygonPointTypewith acomputedAnglefield that is populated during parsing with the computed angle measurementTest plan
pnpm jest packages/perseus-core/src/parse-perseus-json/regression-tests/parse-perseus-json-regression.test.ts -u --runInBand --watchman=falsepnpm jest packages/perseus-core/src/parse-perseus-json/perseus-parsers/interactive-graph-widget.test.ts packages/perseus-core/src/utils/get-default-figure-for-type.test.ts packages/perseus-core/src/utils/generators/interactive-graph-widget-generator.test.ts packages/perseus-linter/src/rules/interactive-graph-widget-error.test.ts --runInBand --watchman=false