-
Notifications
You must be signed in to change notification settings - Fork 187
refactor(app,labware-library): Migrate some more components to positionMode="passThrough"
#20302
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
Conversation
mjhuff
left a 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.
Super, thank you!
No further changes needed for this one. This labware thumbnail was already using getLabwareViewBox(), so passThrough was correct.
This one is tricky for a few reasons. 1. We're hard-coding an SVG viewbox that's a bit bigger than a deck slot, and expecting the labware to show up roughly in the middle of it when we plop it in. 2. We're rendering not only a labware, but also a pipette that's supposed to go show up over the labware's wells. So the pipette component needs to be in the same coordinate system as the labware component. I think this was actually buggy before. The labware offset itself by `cornerOffsetFromSlot` (because it had `positioningMode="offsetInSlot"`), but the pipette didn't match that. Therefore: 1. We need `<CenterLabwareInSlot>`, even though we're not rendering a deck slot. 2. We need the `<CenterLabwareInSlot>` to wrap the labware component *and* the pipette component, not just the labware component.
This one is a pretty straightforward labware thumbnail. Formerly, we were making the labware offset itself (`positioningMode="offsetInSlot"`), then manually predicting where it ended up using `getSchema2CornerOffsetFromSlot()`. Now we don't let the labware offset itself (`positioningMode="passThrough"`), and we directly get the thumbnail viewbox with `getLabwareViewBox()`.
This code was already using a `useLayoutEffect()` to automatically compute an SVG viewbox that enclosed the labware, so it never really mattered how the labware was translated in 2D space. The viewbox would automatically translate to follow it, no matter what. So we can just flip `offsetInSlot` to `passThrough` here without needing to change anything else.
d6994ca to
17a098c
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## edge #20302 +/- ##
==========================================
- Coverage 25.58% 25.58% -0.01%
==========================================
Files 3640 3640
Lines 303120 303129 +9
Branches 42327 42327
==========================================
Hits 77552 77552
- Misses 225544 225553 +9
Partials 24 24
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
Overview
Continued efforts to migrate away from
positioningMode="offsetInSlot"/"offsetToSlot", where<LabwareRender>and<Module>have some built-in SVG transforms, topositioningMode="passThrough", where they don't. This goes towards EXEC-1278. See the documentation on<LabwareRender>and<Module>for more background onpositioningMode.After this PR, it looks like the only things left that are using
positioningMode="offsetInSlot"/"offsetToSlot"are in protocol-designer.This depends on PR #20285 and will need to merge after it.
Test Plan and Hands on Testing
The
JogToWell/LPCLabwareJogRenderchanges are the ones that worried me the most, and I've checked those in the desktop app.Changelog
Update various call sites of
<LabwareRender>to usepositioningMode="passThrough". This involves understanding what each call site was trying to do and making adjustments to its stack of SVG transforms, if necessary.Review requests
See the individual commit messages for notes on each call site.
Risk assessment
Low risk, given the test plan above, I think. But there's a chance this will cause labware or modules to be rendered in the wrong position.