-
Notifications
You must be signed in to change notification settings - Fork 352
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
provide keypad for expression story #442
Conversation
🦋 Changeset detectedLatest commit: 511b0d2 The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Size Change: 0 B Total Size: 652 kB ℹ️ View Unchanged
|
npm Snapshot: Published🎉 Good news!! We've packaged up the latest commit from this PR (c4805c6) and published it to npm. You Example: yarn add @khanacademy/perseus@PR442 |
<KeypadContext.Consumer> | ||
{({keypadElement, setRenderer, scrollableElement}) => { | ||
return ( | ||
<ItemRendererWithDebugUI |
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 switched to ItemRendererWithDebugUI because ItemRenderer has keypadElement={this.keypadElement()}
when rendering Renderer whereas RendererWithDebugUI does not - which was causing errors when trying to open the keypad.
I imagine I could have added it to RendererWithDebugUI, but I'm not totally sure I understand why we have both ItemRendererWithDebugUI and RendererWithDebugUI. Figured it was best to let sleeping dogs lie.
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.
The two "RendererWithDebugUI" helpers render different components. In Perseus, we have ItemRenderer
and Renderer
. The former is high-level and accepts a bigger blob of JSON, the Renderer
is our core, lower-level component that renders a single PerseusRenderer
object (the thing that looks like {content: string, widgets: {}, images: {}}
.
@@ -4,60 +4,11 @@ import {View} from "@khanacademy/wonder-blocks-core"; | |||
import {StyleSheet} from "aphrodite"; | |||
import * as React from "react"; | |||
|
|||
import {ItemRenderer} from "../../index.js"; |
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.
Originally I split this logic out so both on-screen-keypad.stories.jsx
and expression.stories.jsx
could use the same keypad provider. However (IMO) on-screen-keypad.stories.jsx
was really just a very specific expression story, so I ended up just strengthening up expression.stories.jsx
and getting rid of on-screen-keypad.stories.jsx
.
Keeping this split out logic separate though, because (I think) we want the keypad in lots of components. Also I didn't want to clutter expression.stories.jsx
.
const createItemJson = ( | ||
widgetOptions: PerseusExpressionWidgetOptions, | ||
version: Version, | ||
): Item => { | ||
): PerseusItem => { |
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.
Using the real PerseusItem type instead of the fake Item. That required adding a few fields to the object.
GeraldRequired Reviewers
Don't want to be involved in this pull request? Comment |
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.
Cool. Glad you feel you're starting to understand all this Math Input stuff... it's still very much a mystery to me! :)
<KeypadContext.Consumer> | ||
{({keypadElement, setRenderer, scrollableElement}) => { | ||
return ( | ||
<ItemRendererWithDebugUI |
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.
The two "RendererWithDebugUI" helpers render different components. In Perseus, we have ItemRenderer
and Renderer
. The former is high-level and accepts a bigger blob of JSON, the Renderer
is our core, lower-level component that renders a single PerseusRenderer
object (the thing that looks like {content: string, widgets: {}, images: {}}
.
Summary:
I think I'm starting to understand the mobile web keypad:
math-input/src/components/keypad-container.js
)Then we shuffle it all around chaotically. Something like:
Why all the hoop jumping? Still don't know why. Seems like MathInput could just render the input and the keypad without the need for Context, but I'm sure there was a good reason.
ANYWAY
This explains why I wasn't able to see the Keypad on the Expression widget in Storybook: it wasn't using Context. This PR creates a shared component for providing context (with the on-screen-keypad story, which might be obsolete now).
Unfortunately all this indirection kills my dream of having MathInput manage how we render the keypad; I think it's going to have to happen in Perseus unless we really want to overhaul things.
Screen.Recording.2023-03-27.at.4.31.13.PM.mov