-
Notifications
You must be signed in to change notification settings - Fork 350
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
[DRAFT] New Perseus Preview component #1304
base: main
Are you sure you want to change the base?
Conversation
Size Change: +1.26 kB (+0.15%) Total Size: 857 kB
ℹ️ View Unchanged
|
Very cool, thank you for working on this! In this approach of rendering |
Yes, linting, good call! I've added that to the PR description as something we'd need to figure out! |
554b1d9
to
19fe692
Compare
520bf66
to
39e40f1
Compare
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 (143f88c) and published it to npm. You Example: yarn add @khanacademy/perseus@PR1304 If you are working in Khan Academy's webapp, you can run: ./dev/tools/bump_perseus_version.sh -t PR1304 |
f200ffd
to
6a2f498
Compare
…le class names on wrapping View
…method which loses the this binding)
6a2f498
to
74816d7
Compare
…using preview tab
be253d4
to
a80c35b
Compare
Summary:
Today, the Perseus editor preview component uses a complex
<iframe />
based system that depends on a live website providing the iframe source. This makes it challenging to mimic the preview system in Storybook and has its own set of issues in production.Added to that, the mechanism to communicate between the Perseus Editor and the preview frame is not at all easy to understand and is split between this repo (Khan/perseus) and our main webapp repo. This makes maintaining the preview system tricky and error prone (basically, we don't touch it!)
This PR introduces a new preview component that simply renders the
ServerItemRenderer
using the current PerseusItem. This eliminates all of the cross-frame communication that was needed and seems to work just as good as the iframe system.A few notes before we commit to this:
We need preview components that support hints and articles (either we make the preview component more flexible or render different preview components where they're needed - I think I'd lean towards the latter as I don't think there's a need to have One Master Preview Component To Rule Them All™️ )
The
expression
widget when simulating mobile can display the math keypad, but it doesn't automatically dismiss when the field is blurred. In testing, Nisha and I found that this is actually semi-broken in production anyways so this wouldn't be a regression.The old iframe preview system uses a helper tool from the HammerJS library, which is vendored in, to simulate touches when previewing for Phone and Tablet. This isn't possible with a non-iframe preview system because that library "mutates" the global env, so we'd have to reload the page to switch between preview devices. I think a way forward might be to change the math keypad to support Pointer Events instead of being so touch-centric.
Linting: I haven't figured out exactly how this all works, but there is a
LinterContextProps
prop on some top-level editor components that seems involved. Also, thesimple-markdown
package is the place where we actually render the<Lint />
component that surfaces lint errors beside the preview. It seems liketriggerPreviewUpdate()
call in theEditorPage
is related (here). You can see an example of a linter error and how it's shown in the screenshot below.Linting is somewhat working! :) @mpolyak
Issue: LEMS-1809
Test plan:
yarn start
Navigate to the
Editor Page
story and add any widgets. The preview should update in near realtime as you edit the content and widget configs.