feat: let the host set the sheet background and badge the address field - #11
feat: let the host set the sheet background and badge the address field#11romchornyi wants to merge 3 commits into
Conversation
The fill was hardcoded to `primaryBackground` in five places, and the presentation background — the one that covers the home-indicator inset — was only applied when a `cornerRadius` happened to be passed. A host that wanted anything else had two bad options: restyle its own content and live with a pale strip along the bottom edge, or pass a corner radius it did not want purely for the side effect. `background` is now a parameter on `BottomSheet`, on the `selfSizing` factory and on `selfSizingSheet(…)`, defaulting to what it was. The presentation fill applies on iOS 16.4+ regardless of corner radius, so the strip matches whatever the sheet is filled with. Why the strip exists at all: the natural-height path deliberately measures without the bottom safe area, and `presentationDetents([.height])` adds that inset back — so it lies outside the sheet's own stack and needs the presentation background to be covered.
The label row was a bare Text, so a host with something to say about the address it decoded — which chain it turned out to belong to — had nowhere to put it and had to draw its own label row above the field, printing the label twice. An optional accessory sits opposite the label. It is deliberately not inside the field: the controls in there act on the address (paste, scan, clear), while this describes it. Generic over the accessory with an EmptyView convenience initializer, the same shape NavigationBar uses, so existing callers are untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A generic type cannot hold static stored properties, so the nested Layout enum stopped compiling the moment the view gained its accessory parameter. SwiftPM accepted it; Xcode did not, which is where it surfaced. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
📝 WalkthroughWalkthrough
ChangesUI component enhancements
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Caller
participant BottomSheet
participant SelfSizingSheet
participant Presentation
Caller->>BottomSheet: Provide background color
BottomSheet->>SelfSizingSheet: Propagate background
SelfSizingSheet->>Presentation: Apply presentation background
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
Sources/DashUIKit/Components/BottomSheet.swift (1)
190-210: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winRestrict the presentation-background guarantee to iOS 16.4 and later.
presentationDetentssupports iOS 16.0, butpresentationBackgroundsupports iOS 16.4 and later. On iOS 16.0–16.3,selfSizingSheetdoes not fill the presentation’s bottom safe-area strip. Update the source documentation and the two statements indocs/navigation-and-containers.md, or add a UIKit fallback. The existing no-op path below iOS 16 satisfies the iOS 14 fallback requirement.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Sources/DashUIKit/Components/BottomSheet.swift` around lines 190 - 210, Restrict the presentation-background guarantee to iOS 16.4 and later: update the selfSizingSheet documentation in Sources/DashUIKit/Components/BottomSheet.swift and both affected statements in docs/navigation-and-containers.md at lines 98 and 112-116 to state that iOS 16.0–16.3 do not fill the bottom safe-area strip, while preserving the existing no-op behavior below iOS 16; no direct code change is required in the shown modifier branch unless adding a UIKit fallback instead.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Sources/DashUIKit/Components/AddressFieldView.swift`:
- Around line 341-365: Wrap the iOS 17/macOS 14 `#Preview("Label accessory")`
declaration in `#if DEBUG` and `#endif`, preserving the existing preview
implementation unchanged.
- Around line 352-353: Replace the direct Image(systemName:) badge icon in
AddressFieldView with an appropriate DashIconSource, then render that source
using Image(dash: source) while preserving the existing size and weight styling.
- Around line 343-356: Localize the preview’s user-facing strings in
AddressFieldView by wrapping “Address,” “Dash address,” and “Transparent
address” with NSLocalizedString using bundle: .module and appropriate comments;
add matching entries to the module’s localization resources.
- Around line 31-32: Restore compatibility in AddressFieldView by isolating the
`@FocusState-dependent` behavior and text-field branches behind iOS 15/macOS 12
availability, and provide an equivalent iOS 14/macOS 11 fallback. Then update
AddressFieldView and its compatibility initializer availability to iOS 14/macOS
11 while preserving focus behavior on newer platforms.
In `@Sources/DashUIKit/Components/BottomSheet.swift`:
- Around line 179-188: The selfSizingSheet modifier’s default background must
match the enclosing BottomSheet background. Update the BottomSheet and
selfSizingSheet flow to propagate and reuse the configured sheet color via the
existing environment mechanism, or require the modifier caller to provide it
explicitly; remove the incorrect independent .dash.primaryBackground default and
preserve matching content and presentation colors.
- Around line 305-326: Wrap the `#Preview` declaration for “BottomSheet Custom
Background” in `#if` DEBUG and a matching `#endif`, preserving its existing iOS
17/macOS 14 availability and preview content.
- Around line 190-206: Update the macOS path in the availability-gated modifier
flow around SelfSizingSheetModifier so presentationBackground(background) is
applied on macOS 13.3 and later. Keep the existing iOS-specific corner-radius
handling intact, and ensure older macOS versions continue using the fallback
behavior.
---
Outside diff comments:
In `@Sources/DashUIKit/Components/BottomSheet.swift`:
- Around line 190-210: Restrict the presentation-background guarantee to iOS
16.4 and later: update the selfSizingSheet documentation in
Sources/DashUIKit/Components/BottomSheet.swift and both affected statements in
docs/navigation-and-containers.md at lines 98 and 112-116 to state that iOS
16.0–16.3 do not fill the bottom safe-area strip, while preserving the existing
no-op behavior below iOS 16; no direct code change is required in the shown
modifier branch unless adding a UIKit fallback instead.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 53993a54-173b-43e7-968e-c6816a0d573d
📒 Files selected for processing (3)
Sources/DashUIKit/Components/AddressFieldView.swiftSources/DashUIKit/Components/BottomSheet.swiftdocs/navigation-and-containers.md
| @available(iOS 15, macOS 12, *) | ||
| public struct AddressFieldView: View { | ||
|
|
||
| private enum Layout { | ||
| static let hSpacing: CGFloat = 20 | ||
| static let lPadding: CGFloat = 20 | ||
| static let tPadding: CGFloat = 10 | ||
| static let iconSize: CGFloat = 17 | ||
| static let cornerRadius: CGFloat = 16 | ||
| static let actionTapArea: CGFloat = 40 | ||
| } | ||
| public struct AddressFieldView<Accessory: View>: View { |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
# Inspect iOS-specific APIs that must be isolated or replaced for the iOS 14 path.
rg -n -C 3 '`@available`\(iOS|`@FocusState`|`#available`\(iOS|textInputAutocapitalization|disableAutocorrection' \
Sources/DashUIKit/Components/AddressFieldView.swift
# Inspect declared deployment targets when project metadata is present.
for file in $(fd -HI -t f '^(Package\.swift|project\.pbxproj|.*\.podspec)$' . || true); do
rg -n -C 2 'iOS|IPHONEOS_DEPLOYMENT_TARGET|platforms|macOS' "$file" || true
doneRepository: dashpay/DashUIKit
Length of output: 3522
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
# Map and inspect the component and nearby availability-sensitive declarations.
ast-grep outline Sources/DashUIKit/Components/AddressFieldView.swift
sed -n '1,210p' Sources/DashUIKit/Components/AddressFieldView.swift
sed -n '240,370p' Sources/DashUIKit/Components/AddressFieldView.swift
# Check the package deployment declaration and related availability patterns.
rg -n -C 3 'platforms:|\.iOS\(|\.macOS\(|`@FocusState`|focused\(' Package.swift Sources/DashUIKitRepository: dashpay/DashUIKit
Length of output: 14889
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
import re
path = Path("Sources/DashUIKit/Components/AddressFieldView.swift")
text = path.read_text()
public_annotations = re.findall(
r'`@available`\(([^)]*)\)\s*(?:public\s+)?(?:struct|extension)\s+AddressFieldView',
text,
)
focus_declarations = re.findall(r'^\s*`@FocusState`\b.*$', text, re.MULTILINE)
focus_uses = re.findall(r'\.focused\(\$isTextFieldFocused\)', text)
package = Path("Package.swift").read_text()
print("public AddressFieldView availability:")
for annotation in public_annotations:
print(annotation)
print("FocusState declarations:", len(focus_declarations))
print("focused uses:", len(focus_uses))
print("package iOS 14:", bool(re.search(r'\.iOS\(\.v14\)', package)))
print("focus-dependent computed properties:")
for line_no, line in enumerate(text.splitlines(), 1):
if "isTextFieldFocused" in line or "isFocusedState" in line:
print(f"{line_no}: {line.strip()}")
PYRepository: dashpay/DashUIKit
Length of output: 768
Restore iOS 14 and macOS 11 support for the public API.
Package.swift declares iOS 14 support, but AddressFieldView and its compatibility initializer require iOS 15 and macOS 12. The type also uses @FocusState in its focus-dependent state and both text-field branches. Isolate this behavior and provide an iOS 14 fallback before changing the public declarations to @available(iOS 14, macOS 11, *).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Sources/DashUIKit/Components/AddressFieldView.swift` around lines 31 - 32,
Restore compatibility in AddressFieldView by isolating the `@FocusState-dependent`
behavior and text-field branches behind iOS 15/macOS 12 availability, and
provide an equivalent iOS 14/macOS 11 fallback. Then update AddressFieldView and
its compatibility initializer availability to iOS 14/macOS 11 while preserving
focus behavior on newer platforms.
Source: Coding guidelines
| @available(iOS 17, macOS 14, *) | ||
| #Preview("Label accessory") { | ||
| AddressFieldView( | ||
| text: .constant("yV1D1ivvSUyKPJnbFmzSTVh1MyZ3JbeVkY"), | ||
| label: "Address", | ||
| placeholder: "Dash address", | ||
| hasError: false | ||
| ) { | ||
| // What the host puts here is its own: a badge naming the kind of | ||
| // address that was entered, decided by the host's own decoder. | ||
| HStack(spacing: 4) { | ||
| Image(systemName: "d.circle.fill") | ||
| .font(.system(size: 10, weight: .semibold)) | ||
| Text("Transparent address") | ||
| .dashFont(.caption2) | ||
| } | ||
| .foregroundStyle(Color.dash.blueText) | ||
| .padding(.horizontal, 8) | ||
| .padding(.vertical, 3) | ||
| .background(Color.dash.blueAlpha10) | ||
| .clipShape(Capsule()) | ||
| } | ||
| .padding() | ||
| .background(Color.dash.primaryBackground) | ||
| } |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Guard the iOS 17 preview with #if DEBUG.
The new #Preview uses an iOS 17-only declaration without the required debug guard. Wrap Lines 341-365 in #if DEBUG and #endif.
As per coding guidelines, preview-only code may require iOS 17 only when guarded by #if DEBUG.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Sources/DashUIKit/Components/AddressFieldView.swift` around lines 341 - 365,
Wrap the iOS 17/macOS 14 `#Preview("Label accessory")` declaration in `#if
DEBUG` and `#endif`, preserving the existing preview implementation unchanged.
Source: Coding guidelines
| AddressFieldView( | ||
| text: .constant("yV1D1ivvSUyKPJnbFmzSTVh1MyZ3JbeVkY"), | ||
| label: "Address", | ||
| placeholder: "Dash address", | ||
| hasError: false | ||
| ) { | ||
| // What the host puts here is its own: a badge naming the kind of | ||
| // address that was entered, decided by the host's own decoder. | ||
| HStack(spacing: 4) { | ||
| Image(systemName: "d.circle.fill") | ||
| .font(.system(size: 10, weight: .semibold)) | ||
| Text("Transparent address") | ||
| .dashFont(.caption2) | ||
| } |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Localize the preview strings.
"Address", "Dash address", and "Transparent address" are user-facing strings. Use NSLocalizedString(_, bundle: .module, comment:) for each string and add the corresponding localized entries.
Proposed change
- label: "Address",
- placeholder: "Dash address",
+ label: NSLocalizedString("Address", bundle: .module, comment: "DashUIKit"),
+ placeholder: NSLocalizedString("Dash address", bundle: .module, comment: "DashUIKit"),
...
- Text("Transparent address")
+ Text(NSLocalizedString("Transparent address", bundle: .module, comment: "DashUIKit"))As per coding guidelines, localize all user-facing strings with NSLocalizedString(_, bundle: .module, comment:).
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| AddressFieldView( | |
| text: .constant("yV1D1ivvSUyKPJnbFmzSTVh1MyZ3JbeVkY"), | |
| label: "Address", | |
| placeholder: "Dash address", | |
| hasError: false | |
| ) { | |
| // What the host puts here is its own: a badge naming the kind of | |
| // address that was entered, decided by the host's own decoder. | |
| HStack(spacing: 4) { | |
| Image(systemName: "d.circle.fill") | |
| .font(.system(size: 10, weight: .semibold)) | |
| Text("Transparent address") | |
| .dashFont(.caption2) | |
| } | |
| AddressFieldView( | |
| text: .constant("yV1D1ivvSUyKPJnbFmzSTVh1MyZ3JbeVk"), | |
| label: NSLocalizedString("Address", bundle: .module, comment: "DashUIKit"), | |
| placeholder: NSLocalizedString("Dash address", bundle: .module, comment: "DashUIKit"), | |
| hasError: false | |
| ) { | |
| // What the host puts here is its own: a badge naming the kind of | |
| // address that was entered, decided by the host's own decoder. | |
| HStack(spacing: 4) { | |
| Image(systemName: "d.circle.fill") | |
| .font(.system(size: 10, weight: .semibold)) | |
| Text(NSLocalizedString("Transparent address", bundle: .module, comment: "DashUIKit")) | |
| .dashFont(.caption2) | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Sources/DashUIKit/Components/AddressFieldView.swift` around lines 343 - 356,
Localize the preview’s user-facing strings in AddressFieldView by wrapping
“Address,” “Dash address,” and “Transparent address” with NSLocalizedString
using bundle: .module and appropriate comments; add matching entries to the
module’s localization resources.
Source: Coding guidelines
| Image(systemName: "d.circle.fill") | ||
| .font(.system(size: 10, weight: .semibold)) |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Use a DashIconSource for the badge icon.
Image(systemName:) bypasses the DashUIKit icon source contract. Select or add an appropriate DashIconSource, then render it with Image(dash: source).
As per coding guidelines, represent icons with DashIconSource and render them using Image(dash: source).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Sources/DashUIKit/Components/AddressFieldView.swift` around lines 352 - 353,
Replace the direct Image(systemName:) badge icon in AddressFieldView with an
appropriate DashIconSource, then render that source using Image(dash: source)
while preserving the existing size and weight styling.
Source: Coding guidelines
| /// - background: Fill for the sheet and its presentation, so the bottom | ||
| /// safe-area strip matches the content. Defaults to the sheet's own. | ||
| /// - cornerRadius: Optional corner radius applied via `presentationCornerRadius` on | ||
| /// iOS 16.4..<26 (iOS 26+ keeps the system corner styling). When provided, the sheet | ||
| /// background is also filled so the bottom safe-area strip matches the content. | ||
| /// iOS 16.4..<26 (iOS 26+ keeps the system corner styling). | ||
| @ViewBuilder | ||
| func selfSizingSheet( | ||
| fallback: CGFloat = 0, | ||
| maxHeightFraction: CGFloat = 0.95, | ||
| background: Color = .dash.primaryBackground, | ||
| cornerRadius: CGFloat? = nil |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
Make the direct modifier default match the wrapped sheet.
selfSizingSheet(background:) defaults to .dash.primaryBackground independently of BottomSheet.background. A direct composition with a custom BottomSheet(background:) and .selfSizingSheet() therefore uses different colors for the content and presentation. The bottom inset can show the primary background again.
Propagate the sheet color through an environment value, or remove “Defaults to the sheet’s own” and require direct modifier calls to pass the same color.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Sources/DashUIKit/Components/BottomSheet.swift` around lines 179 - 188, The
selfSizingSheet modifier’s default background must match the enclosing
BottomSheet background. Update the BottomSheet and selfSizingSheet flow to
propagate and reuse the configured sheet color via the existing environment
mechanism, or require the modifier caller to provide it explicitly; remove the
incorrect independent .dash.primaryBackground default and preserve matching
content and presentation colors.
| if #available(iOS 16.0, macOS 13.0, *) { | ||
| let modified = modifier(SelfSizingSheetModifier(fallback: fallback, maxHeightFraction: maxHeightFraction)) | ||
| #if os(iOS) | ||
| if #available(iOS 16.4, *), let cornerRadius { | ||
| if #unavailable(iOS 26.0) { | ||
| // iOS 16.4..<26: apply the custom corner radius + fill the sheet background. | ||
| if #available(iOS 16.4, *) { | ||
| // The background is filled whatever the corner radius: the | ||
| // measured height excludes the home-indicator inset that | ||
| // `.presentationDetents([.height])` adds back, so that strip | ||
| // sits outside the sheet's own `VStack` and shows the system | ||
| // background unless this fills it. | ||
| if #unavailable(iOS 26.0), let cornerRadius { | ||
| modified | ||
| .presentationCornerRadius(cornerRadius) | ||
| .presentationBackground(Color.dash.primaryBackground) | ||
| .presentationBackground(background) | ||
| } else { | ||
| // iOS 26+: keep the system corner styling, just fill the background. | ||
| // iOS 26+ keeps the system corner styling. | ||
| modified | ||
| .presentationBackground(Color.dash.primaryBackground) | ||
| .presentationBackground(background) |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file="Sources/DashUIKit/Components/BottomSheet.swift"
rg -n -C 6 'presentationBackground|`#if` os\(iOS\)|macOS 13\.0|`@available`\(iOS 14' "$file"Repository: dashpay/DashUIKit
Length of output: 4155
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- BottomSheet.swift ---'
sed -n '130,240p' Sources/DashUIKit/Components/BottomSheet.swift
printf '%s\n' '--- Package manifests and platform declarations ---'
fd -i -t f 'Package.swift|.*\.podspec|.*\.yml|.*\.yaml' . -x sh -c 'printf "\n--- %s ---\n" "$1"; rg -n -C 3 "platform|macOS|iOS|swift-tools-version" "$1"' sh {}
printf '%s\n' '--- selfSizingSheet usages ---'
rg -n -C 3 'selfSizingSheet|BottomSheet\.selfSizing|BottomSheet\(' Sources Tests 2>/dev/null || trueRepository: dashpay/DashUIKit
Length of output: 12451
🌐 Web query:
SwiftUI presentationBackground macOS availability macOS 13 documentation
💡 Result:
The presentationBackground(:) modifier in SwiftUI is available on macOS starting with macOS 13.3 [1][2]. It allows you to customize the background of modal presentations such as sheets, popovers, and full-screen covers [3][4]. Key details regarding this modifier include: Availability: It was introduced in iOS 16.4 and macOS 13.3 [1][2]. Functionality: The modifier applies a ShapeStyle (such as a color, gradient, or material) to the background of an enclosing presentation [5][3]. A secondary version, presentationBackground(alignment:content:), allows for more complex, custom view backgrounds [6][3]. Platform Behavior: Unlike the standard background(:) modifier, presentationBackground(_:) automatically fills the entire presentation area and supports translucency, allowing underlying views to show through when using appropriate styles [5][7][4]. When using this modifier, ensure that nested container views like List or Form have their default backgrounds disabled (e.g., using.scrollContentBackground(.hidden)) if you wish for your custom presentation background to be visible [3].
Citations:
- 1: shaps80/SwiftUIBackports@495dae9
- 2: https://sendbird.com/docs/chat/uikit/v3/swiftui/ref/documentation/sendbirdswiftui/messagethreadview/presentationbackground(_:)
- 3: https://nilcoalescing.com/blog/ModalPresentationBackgroundAndColorSchemeInSwiftUI
- 4: https://swift.mackarous.com/posts/2024/09/modifiers-presentation-background
- 5: https://apple-docs.everest.mt/docs/swiftui/view/presentationbackground(_:)/
- 6: https://apple-docs.everest.mt/docs/swiftui/view/presentationbackground(alignment:content:)/
- 7: https://developer.apple.com/forums/thread/737470
Apply the presentation background on macOS 13.3 and later.
presentationBackground is available on macOS 13.3+, but the #if os(iOS) branch excludes macOS. The background parameter therefore has no effect on macOS presentations. Add a macOS 13.3 availability branch or narrow the API documentation.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Sources/DashUIKit/Components/BottomSheet.swift` around lines 190 - 206,
Update the macOS path in the availability-gated modifier flow around
SelfSizingSheetModifier so presentationBackground(background) is applied on
macOS 13.3 and later. Keep the existing iOS-specific corner-radius handling
intact, and ensure older macOS versions continue using the fallback behavior.
Source: Coding guidelines
|
|
||
| @available(iOS 17, macOS 14, *) | ||
| #Preview("BottomSheet Custom Background") { | ||
| BottomSheet( | ||
| title: "Bottom Sheet", | ||
| showBackButton: .constant(false), | ||
| fillsHeight: false, | ||
| background: .dash.secondaryBackground | ||
| ) { | ||
| VStack(alignment: .leading, spacing: 12) { | ||
| Text("Cards on a tinted sheet") | ||
| .dashFont(.calloutMedium) | ||
| .foregroundColor(.dash.primaryText) | ||
|
|
||
| Text("The host picks the fill; cards drawn on top keep their own.") | ||
| .dashFont(.body) | ||
| .foregroundColor(.dash.secondaryText) | ||
| .modifier(MenuViewModifier()) | ||
| } | ||
| .padding() | ||
| } | ||
| } |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file="Sources/DashUIKit/Components/BottomSheet.swift"
rg -n -B 8 -A 4 '`#Preview`|`#if` DEBUG|`#endif`' "$file"Repository: dashpay/DashUIKit
Length of output: 2543
Guard all #Preview declarations with #if DEBUG and #endif. These previews use iOS 17 and macOS 14 availability while BottomSheet supports iOS 14 and macOS 11.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Sources/DashUIKit/Components/BottomSheet.swift` around lines 305 - 326, Wrap
the `#Preview` declaration for “BottomSheet Custom Background” in `#if` DEBUG and a
matching `#endif`, preserving its existing iOS 17/macOS 14 availability and
preview content.
Source: Coding guidelines
2 participants
Issue being fixed or feature implemented
Two components could not be adapted by their hosts without forking them.
BottomSheethard-codedColor.dash.primaryBackgroundin three places, so asheet that belongs on a different surface had no way to say so. Restyling only
the content is not enough: the background is also what the presentation detent
paints behind the home-indicator inset, so a host that overrode its own content
still got a strip of the original colour along the bottom edge.
AddressFieldViewhad nowhere to put anything beside its label. The consumerin dashwallet-ios needs a badge there naming what an entered address decoded to
— a property of the field, not an action on it.
What was done?
BottomSheettakes abackground: Color, defaulting to.dash.primaryBackgroundso every existing call site renders exactly asbefore. It is applied to the sheet body, to both content branches, and to the
presentation background, so the bottom-edge strip cannot reappear.
AddressFieldViewbecame generic over anAccessoryview placed opposite thelabel, with a
Spacerbetween them. Callers that want none keep the shape theyalready had: a constrained extension on
Accessory == EmptyViewsupplies theold initializer verbatim, so no existing call site changes.
Its
Layoutconstants moved out of the type to file scope. A generic typecannot hold static stored properties — worth knowing that SwiftPM compiled the
nested version anyway and only Xcode rejected it, so
swift buildalone doesnot prove this file.
How Has This Been Tested?
swift buildclean, plus a fulldashpaybuild in dashwallet-ios pinned tothis branch — that consumer is the one exercising both new parameters, and it
is the build that catches what SwiftPM misses. Exercised on the simulator: the
address step with the destination badge, and the sheets that pass a background.
Existing call sites were not touched, and both defaults reproduce the previous
rendering.
Breaking Changes
None at call sites — both additions are defaulted, and the
EmptyViewextension keeps
AddressFieldView's original initializer.Worth flagging for anyone writing the type name explicitly:
AddressFieldViewis now generic, so an explicit annotation needs a parameter
(
AddressFieldView<EmptyView>). Inferred usage is unaffected.Checklist:
Summary by CodeRabbit
New Features
Documentation