-
Notifications
You must be signed in to change notification settings - Fork 280
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
feat: DraggablePoint
in solids
#1485
Conversation
± Registry diff
📊 PerformanceKeyNote that each bar component rounds up to the nearest 100ms, so each full bar is an overestimate by up to 400ms.
If a row has only one bar instead of four, that means it's not a trio and the bar just shows the total time spent for that example, again rounded up to the nearest 100ms. Data
|
Deploying penrose with Cloudflare Pages
|
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.
LGTM! I didn't review the code in too too much detail though, so let me know if there are any specific parts you want me to take a look at.
Description
Resolves #issue.
This PR adds a
DraggablePoint
component to@penrose/solids
, which is inspired by Movable points in Mafs.Implementation strategy and design decisions
DraggablePoint.tsx
and use it ineigenvalues.tsx
rose
now that it's introduced by refactor: integrate Rose #1636.Checklist
Examples and how to reproduce them
Run
nx run solids:dev
to see the eigenvalue example. All draggable points use `DraggablePoint".Open questions
DraggablePoint
will need a ref to the outer SVG to compute the right transforms. I think usually people use contexts to pass these things around.transform
is technically not needed ifx
andy
are in the SVG screen space. It's only needed becauseDraggablePoint
updatesx
andy
after dragging. Should we expose them as callbacks instead?