-
Notifications
You must be signed in to change notification settings - Fork 4k
Refactor monitor dragging #5795
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
base: develop
Are you sure you want to change the base?
Refactor monitor dragging #5795
Conversation
| [styles.dragging]: props.dragging | ||
| })} | ||
| style={{ | ||
| transform: `translate(${props.x}px, ${props.y}px)` |
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.
Will it cause any performance issues to re-render this component for every frame we're dragging?
|
Going to take another look at this to see if I can stop the inner monitor component from rerendering once per drag event |
|
@adroitwhiz Would you want to keep working on this? We're thinking about closing it unless you think all the issues are resolved. |
|
It's basically done--the only issue is that the monitor component re-renders once per drag event (which I believe is at most once per frame). I'll rebase this, see if I can fix that, and update you on this by next Monday. |
88c0ca5 to
7764387
Compare
|
The re-rendering once per drag event happens because the monitor's coordinates are now stored as part of the component state, and dragging monitors updates those coordinates immediately. I don't think there's a clean way to stop it from happening--the monitor's coordinates should be part of its state. I think it's perfectly fine to re-render the monitor once per frame whilst dragging--a Scratch project which changes a monitor value once per tick does basically the same thing anyway (albeit at 30 FPS). |
Resolves
Proposed Changes
This PR reimplements the dragging behavior previously done in react-draggable, but takes stage scale into account.
It also changes the monitors to always position themselves using CSS transforms and never setting the
toporleftposition--those will affect text wrapping while CSS transforms will not, resulting in wrapping differences between monitors positioned withtop/leftand monitors positioned with a CSS transform. This is what led to #5782.Also, it explicitly defines a text color for monitor labels-- this text color style was previously missing, and it caused monitor labels to appear differently-colored on a standalone GUI instance than the main website.
Reason for Changes
These changes resolve the bugs linked above.
I'm including them all in one PR to make bug hunts easier
Test Coverage
Tested manually
Browser Coverage
Check the OS/browser combinations tested (At least 2)
Linux
Mac
Windows
Chromebook
iPad
Android Tablet