fix(blade-svelte): BottomSheet snaps to exact snapPoint fraction - #3942
Open
rohankokane-dev wants to merge 1 commit into
Open
fix(blade-svelte): BottomSheet snaps to exact snapPoint fraction#3942rohankokane-dev wants to merge 1 commit into
rohankokane-dev wants to merge 1 commit into
Conversation
setPositionY clamped the sheet height to content height via computeMaxContent, so a sheet opened with snapPoints like [0.85, ...] hugged its (often short) body content and settled far below the requested 85% of the viewport. Consumers worked around this by forcing a min-height on body content to inflate the measured content height and defeat the clamp (e.g. checkout's #main-stack-container overlay). Remove the clamp so positionY maps directly to the requested snap fraction on open, drag-snapback, and settle. The sheet now honors the snapPoint share of the viewport regardless of content height. Tradeoff: this diverges from React parity (React still caps positionY to content height). Short-content sheets using multi-stop snapPoints may now show empty space below their content. This is the intended global default per product decision. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Contributor
|
🤖 Slash AI Review has been triggered. View execution logs |
Collaborator
🛡️ Coverage ReportSummaryFull Coverage Details |
![rzp-slash[bot]](https://avatars.githubusercontent.com/u/7713209?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
✨ Agentic PR Review ✨
UI Review
✅ 5 passed
Passing checks (5)
Usage
import { BottomSheet } from '@razorpay/blade-svelte/components';
<BottomSheet snapPoints={[0.85]} isOpen={true} onDismiss={() => {}}>
{#snippet children()}
<BottomSheetBody>
{#snippet children()}
<p>Body content goes here.</p>
{/snippet}
</BottomSheetBody>
{/snippet}
</BottomSheet>| @@ -31,7 +31,7 @@ | |||
| import { setBottomSheetContext } from './bottomSheetContext'; | |||
Contributor
There was a problem hiding this comment.
🟠 [MAJOR] · code-quality-critique · confidence: 9/10
Problem: Missing changeset: this PR changes user-facing BottomSheet snap-point behavior (bug fix / logic change) but no changeset file was added in .changeset/
Suggestion: Add a changeset file (e.g. .changeset/blade-svelte-bottomsheet-snap-fix.md) with a patch bump for @razorpay/blade-svelte describing the snap-point fix
| @@ -31,7 +31,7 @@ | |||
| import { setBottomSheetContext } from './bottomSheetContext'; | |||
Contributor
There was a problem hiding this comment.
🙏🏻 [NEEDS CLARIFICATION] · api-decision-critique · confidence: 5/10
Removing computeMaxContent clamping from setPositionY silently changes the runtime behavior of the existing snapPoints prop: sheets whose body content is shorter than the requested snap fraction will now extend to the full viewport fraction instead of hugging content. While this aligns with snapPoints' documented contract ('Each value is a fraction of the viewport height'), it is a behavioral breaking change for consumers who relied on the implicit clamping (or used the min-height workaround for the opposite reason). The PR body acknowledges divergence from React parity, but no migration note or opt-in prop is proposed. Should this ship as a silent default change, or would introducing an explicit opt-in prop (e.g. snapToContent?: boolean defaulting to false) better preserve backward compatibility, make the React/Svelte divergence controllable, and give React a path to adopt the same knob later?
rzp-slash
Bot
added
the
Human Help Needed 🧑🏻💻
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
setPositionY clamped the sheet height to content height via computeMaxContent, so a sheet opened with snapPoints like [0.85, ...] hugged its (often short) body content and settled far below the requested 85% of the viewport. Consumers worked around this by forcing a min-height on body content to inflate the measured content height and defeat the clamp (e.g. checkout's #main-stack-container overlay).
Remove the clamp so positionY maps directly to the requested snap fraction on open, drag-snapback, and settle. The sheet now honors the snapPoint share of the viewport regardless of content height.
Tradeoff: this diverges from React parity (React still caps positionY to content height). Short-content sheets using multi-stop snapPoints may now show empty space below their content. This is the intended global default per product decision.
Description
Changes
Additional Information
Component Checklist