Create helper to build public widget options for orderer

[Myranae]

Summary:

Adds a function that takes orderer's full widget options and filters out answer data. It also adds this function to the widget's widget export and adds a test confirming the function does as expected.

Issue: LEMS-2763

Test plan:

• Confirm all checks pass
• Confirm orderer still works as expected

[github-actions]

npm Snapshot: Published

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

Example:

yarn add @khanacademy/perseus@PR2137

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

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

[github-actions]

Size Change: +166 B (+0.01%)

Total Size: 1.48 MB

Filename	Size	Change
packages/perseus-core/dist/es/index.js	28.6 kB	+136 B (+0.48%)
packages/perseus/dist/es/index.js	396 kB	+30 B (+0.01%)

ℹ️ 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	86.8 kB
packages/math-input/dist/es/index.js	77.6 kB
packages/math-input/dist/es/strings.js	1.79 kB
packages/perseus-editor/dist/es/index.js	689 kB
packages/perseus-linter/dist/es/index.js	22.2 kB
packages/perseus-score/dist/es/index.js	113 kB
packages/perseus/dist/es/strings.js	5.37 kB
packages/pure-markdown/dist/es/index.js	3.66 kB
packages/simple-markdown/dist/es/index.js	12.5 kB

_{compressed-size-action}

[Myranae]

Removed correctOptions (answers) and otherOptions (options with answer excluded).

For contrast, here are the regular widget options:

export type PerseusOrdererWidgetOptions = {
    // All of the options available to the user. Place the cards in the correct order. The same card can be used more than once in the answer but will only be displayed once at the top of a stack of identical cards.
    options: ReadonlyArray<PerseusRenderer>;
    // The correct order of the options
    correctOptions: ReadonlyArray<PerseusRenderer>;
    // Cards that are not part of the answer
    otherOptions: ReadonlyArray<PerseusRenderer>;
    // "normal" for text options.  "auto" for image options.
    height: "normal" | "auto";
    // Use the "horizontal" layout for short text and small images. The "vertical" layout is best for longer text (e.g. proofs).
    layout: "horizontal" | "vertical";
};

[benchristel]

LGTM!

[jeremywiebe]

Nice. One thing I was thinking as I read through this. We will almost certainly need to call this in a server environment and so I think a better place to build out these helpers is in @khanacademy/perseus-core. Otherwise, shortly after we build these all we'll be moving them anyways. :)

[jeremywiebe]

I'm not sure if this was discussed elsewhere, but it might be useful to build these types off of the main widget options type. This will help keep it clear that this type is a subset of the full widget options.

Suggested change

	height: "normal" | "auto";
	layout: "horizontal" | "vertical";
	height: PerseusOrdererWidgetOptions["height"];
	layout: PerseusOrdererWidgetOptions["layout"];

[Myranae]

Updated :)

[jeremywiebe]

I have a sense that we should "deep copy" these public variants. As this is, the .options array will be the same one between the original widget options and this public one we're returning. Likely never an issue, but making a copy feels safer.

@benchristel do you have thoughts?

Suggested change

	options: options.options,
	options: [...options.options],

[benchristel]

The reason to make a copy is to guard against possible bugs if the array gets mutated later, right?

React's philosophy is that data should never be mutated in place. AFAICT, our code generally follows that guideline, whether it interacts with React or not. As it should!

IMO, we should copy data only at the point where we need to make a change to it. Copying elsewhere reduces clarity and harms performance without a concrete benefit. So I'd prefer not copying here.

...unless you know of a place where we're mutating the data produced by this function?

[Myranae]

Ben, didn't you mention that with Categorizer I think we update the values field based on user input? Would that be an instance of modifying these options? I think the main goal of these public widget options is just to render the clientside widgets, but if the object gets modified to track user input, copying might be needed.

[jeremywiebe]

I can't see these functions ever being used directly with React. They'll be used in an editing environment and the publish pipeline most so the issue of mutation after copy doesn't matter here.

So let's avoid copying.

[Myranae]

Sounds good! I'll leave it as it is then :) Thanks!