Add missing new Icon parameters to BitDateRangePicker (#12197)#12198
Merged
msynk merged 4 commits intobitfoundation:developfrom Mar 20, 2026
Merged
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughAdds per-control icon customization to BitDateRangePicker: 22 icon/iconName parameter pairs, template changes to compute icon CSS classes via BitIconInfo, demo examples showing external icons, and extensive unit tests asserting rendered icon classes. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Tip CodeRabbit can enforce grammar and style rules using `languagetool`.Configure the |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR addresses #12197 by adding the missing BitIconInfo? Icon / string? IconName-style parameters to BitDateRangePicker so consumers can use external icon libraries for navigation, clear/close, and time-picker icons, aligning the component with other Bit.BlazorUI inputs.
Changes:
- Added new icon + icon-name parameters to
BitDateRangePickerand wired them into the rendered markup viaBitIconInfo.From(...).GetCssClasses(). - Expanded the demo page and sample snippets to show using the new icon parameters (FontAwesome + Bootstrap icons).
- Added bUnit tests validating icon-name and
BitIconInfobehaviors for the new parameters.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| src/BlazorUI/Tests/Bit.BlazorUI.Tests/Components/Inputs/DateRangePicker/BitDateRangePickerTests.cs | Adds tests for the new icon parameters (including some currently ignored tests). |
| src/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/Pages/Components/Inputs/DateRangePicker/BitDateRangePickerDemo.razor.samples.cs | Updates code samples to demonstrate new icon parameters. |
| src/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/Pages/Components/Inputs/DateRangePicker/BitDateRangePickerDemo.razor.cs | Extends the demo’s parameter documentation list with the new icon parameters. |
| src/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/Pages/Components/Inputs/DateRangePicker/BitDateRangePickerDemo.razor | Adds runnable demo examples for custom navigation/time-picker icons. |
| src/BlazorUI/Bit.BlazorUI/Components/Inputs/DateRangePicker/BitDateRangePicker.razor.cs | Introduces the new [Parameter] properties for the missing icon customization points. |
| src/BlazorUI/Bit.BlazorUI/Components/Inputs/DateRangePicker/BitDateRangePicker.razor | Applies the new parameters to the rendered <i> elements via computed icon CSS class variables. |
...azorUI/Tests/Bit.BlazorUI.Tests/Components/Inputs/DateRangePicker/BitDateRangePickerTests.cs
Show resolved
Hide resolved
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@src/BlazorUI/Bit.BlazorUI/Components/Inputs/DateRangePicker/BitDateRangePicker.razor.cs`:
- Around line 659-665: The XML summary for the ShowTimePickerAsOverlay parameter
incorrectly says "Show month picker…" — update the triple-slash summary above
the ShowTimePickerAsOverlay property in BitDateRangePicker.razor.cs to
accurately describe its purpose (e.g., "Show time picker on top of date range
picker when visible.") and make the same wording correction in the demo
parameter table where ShowTimePickerAsOverlay is documented so the public docs
match the property behavior; reference the ShowTimePickerAsOverlay property and
ensure any CallOnSet(OnSetParameters) attribute usages remain unchanged.
In
`@src/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/Pages/Components/Inputs/DateRangePicker/BitDateRangePickerDemo.razor`:
- Around line 299-304: The demo uses ShowTimePickerIcon and HideTimePickerIcon
but they only render in overlay mode; update the BitDateRangePicker instance in
BitDateRangePickerDemo to enable overlay by adding ShowTimePickerAsOverlay
(true) alongside ShowTimePicker, and make the matching change in
BitDateRangePickerDemo.razor.samples.cs so the sample data includes
ShowTimePickerAsOverlay as well; this ensures the ShowTimePickerIcon and
HideTimePickerIcon parameters are actually exercised in both the razor component
and its sample file.
In
`@src/BlazorUI/Tests/Bit.BlazorUI.Tests/Components/Inputs/DateRangePicker/BitDateRangePickerTests.cs`:
- Around line 692-776: Remove the [Ignore] attributes on the four tests and
adjust each RenderComponent<BitDateRangePicker> call to render the picker in
overlay mode and then open the overlay so the show/hide time-picker buttons are
actually rendered; specifically, in the
BitDateRangePickerShowTimePickerIconNameTest,
BitDateRangePickerShowTimePickerIconTest,
BitDateRangePickerHideTimePickerIconNameTest and
BitDateRangePickerHideTimePickerIconTest add the component parameter that
enables overlay rendering (e.g., the component's overlay-mode parameter such as
IsOverlay/UseOverlay/OpenOnFocus—whichever the BitDateRangePicker exposes) and
simulate opening the overlay (e.g., click the toggle element or call the
component method that opens the overlay) before querying for the "i" elements so
the ShowTimePickerIcon/HideTimePickerIcon assertions run against rendered
buttons.
- Around line 314-336: The test BitDateRangePickerNextMonthNavIconNameTest
currently only asserts the base icon class and misses the rotation helper used
as a fallback in BitDateRangePicker.razor; update the test so when iconName is
null (the default icon case) it also asserts that the rendered icon's ClassList
contains the rotation helper "bit-ico-r180" (in addition to "bit-icon--Up"), and
apply the same change to the other Next* and *Increase* default-icon tests
(e.g., NextYearNavIconNameTest / IncreaseMonthNavIconName tests) so they verify
both the base icon class (NextMonthNavIconName / NextYearNavIconName / Increase*
props) and the rotation helper class when relying on the component's default.
🪄 Autofix (Beta)
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: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 1819806a-9adb-4fb4-bc4d-5a232a2e8a08
📒 Files selected for processing (6)
src/BlazorUI/Bit.BlazorUI/Components/Inputs/DateRangePicker/BitDateRangePicker.razorsrc/BlazorUI/Bit.BlazorUI/Components/Inputs/DateRangePicker/BitDateRangePicker.razor.cssrc/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/Pages/Components/Inputs/DateRangePicker/BitDateRangePickerDemo.razorsrc/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/Pages/Components/Inputs/DateRangePicker/BitDateRangePickerDemo.razor.cssrc/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/Pages/Components/Inputs/DateRangePicker/BitDateRangePickerDemo.razor.samples.cssrc/BlazorUI/Tests/Bit.BlazorUI.Tests/Components/Inputs/DateRangePicker/BitDateRangePickerTests.cs
src/BlazorUI/Bit.BlazorUI/Components/Inputs/DateRangePicker/BitDateRangePicker.razor.cs
Show resolved
Hide resolved
...azorUI.Demo.Client.Core/Pages/Components/Inputs/DateRangePicker/BitDateRangePickerDemo.razor
Show resolved
Hide resolved
...azorUI/Tests/Bit.BlazorUI.Tests/Components/Inputs/DateRangePicker/BitDateRangePickerTests.cs
Show resolved
Hide resolved
...azorUI/Tests/Bit.BlazorUI.Tests/Components/Inputs/DateRangePicker/BitDateRangePickerTests.cs
Show resolved
Hide resolved
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
src/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/Pages/Components/Inputs/DateRangePicker/BitDateRangePickerDemo.razor.cs:684
- The demo parameter table lists
StylesasBitDateRangePickerClassStylesbut its default value isnulland the component parameter is nullable (BitDateRangePickerClassStyles?). This is inconsistent/misleading for consumers; update the displayed type to include?(or adjust default/parameter type for consistency).
Name = "Styles",
Type = "BitDateRangePickerClassStyles",
DefaultValue = "null",
Description = "Custom CSS styles for different parts of the BitDateRangePicker.",
Href = "#daterangepicker-class-styles",
LinkType = LinkType.Link
Member
Author
|
@coderabbitai re-review |
|
✅ Actions performedFull review triggered. |
src/BlazorUI/Bit.BlazorUI/Components/Inputs/DateRangePicker/BitDateRangePicker.razor
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
src/BlazorUI/Tests/Bit.BlazorUI.Tests/Components/Inputs/DateRangePicker/BitDateRangePickerTests.cs (2)
314-336:⚠️ Potential issue | 🟡 MinorAssert the rotation helper in the default “next” and “increase” cases.
The fallback classes for these paths are compound defaults in
BitDateRangePicker.razor(for exampleUp bit-ico-r180andChevronDownSmall bit-ico-r180). Thenullrows here only assert the base icon class, so these tests still pass if the rotation helper disappears and the arrow points the wrong way.Also applies to: 535-557, 639-664, 782-805, 872-895, 962-985, 1056-1075
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/BlazorUI/Tests/Bit.BlazorUI.Tests/Components/Inputs/DateRangePicker/BitDateRangePickerTests.cs` around lines 314 - 336, The test BitDateRangePickerNextMonthNavIconNameTest only asserts the base icon class for the null fallback and therefore misses verifying the rotation helper (e.g. "bit-ico-r180") that is part of the compound default in BitDateRangePicker.razor; update this test (and the other similar tests at the listed locations) to assert both the base icon class and the expected rotation helper when iconName is null by checking icon.ClassList contains both expectedClass and the rotation class (e.g., "bit-ico-r180"), while leaving the branch that supplies NextMonthNavIconName unchanged.
692-780:⚠️ Potential issue | 🟡 MinorThese show/hide icon tests are still excluded from CI.
[Ignore]drops the only coverage forShowTimePickerIconandHideTimePickerIcon. This should be fixable now by rendering the picker in a deterministic overlay state and tagging the relevant buttons/icons throughClassesinstead of scanning every<i>element.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/BlazorUI/Tests/Bit.BlazorUI.Tests/Components/Inputs/DateRangePicker/BitDateRangePickerTests.cs` around lines 692 - 780, Remove the [Ignore] attributes from the four tests (BitDateRangePickerShowTimePickerIconNameTest, BitDateRangePickerShowTimePickerIconTest, BitDateRangePickerHideTimePickerIconNameTest, BitDateRangePickerHideTimePickerIconTest), render the BitDateRangePicker in a deterministic "overlay open" state instead of relying on loose JSInterop (e.g., supply the parameter or perform the action that opens the picker during RenderComponent so the time-picker buttons are present), and change the element lookup to target a specific CSS hook you add via the component parameters (use Classes or a dedicated data-attribute on the ShowTimePicker/HideTimePicker button/icon) rather than scanning all <i> elements; then assert presence of the expected classes on the targeted element.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@src/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/Pages/Components/Inputs/DateRangePicker/BitDateRangePickerDemo.razor`:
- Around line 299-313: The ClearButtonIcon isn't visible because ShowClearButton
only appears when the picker has a selected range; update the BitDateRangePicker
instance to seed Value with a non-empty date range so the clear button renders
on initial display and do the same in BitDateRangePickerDemo.razor.samples.cs
(ensure you set the Value property to a populated range that covers Start and
End so ClearButtonIcon is exercised while keeping ShowClearButton unchanged).
---
Duplicate comments:
In
`@src/BlazorUI/Tests/Bit.BlazorUI.Tests/Components/Inputs/DateRangePicker/BitDateRangePickerTests.cs`:
- Around line 314-336: The test BitDateRangePickerNextMonthNavIconNameTest only
asserts the base icon class for the null fallback and therefore misses verifying
the rotation helper (e.g. "bit-ico-r180") that is part of the compound default
in BitDateRangePicker.razor; update this test (and the other similar tests at
the listed locations) to assert both the base icon class and the expected
rotation helper when iconName is null by checking icon.ClassList contains both
expectedClass and the rotation class (e.g., "bit-ico-r180"), while leaving the
branch that supplies NextMonthNavIconName unchanged.
- Around line 692-780: Remove the [Ignore] attributes from the four tests
(BitDateRangePickerShowTimePickerIconNameTest,
BitDateRangePickerShowTimePickerIconTest,
BitDateRangePickerHideTimePickerIconNameTest,
BitDateRangePickerHideTimePickerIconTest), render the BitDateRangePicker in a
deterministic "overlay open" state instead of relying on loose JSInterop (e.g.,
supply the parameter or perform the action that opens the picker during
RenderComponent so the time-picker buttons are present), and change the element
lookup to target a specific CSS hook you add via the component parameters (use
Classes or a dedicated data-attribute on the ShowTimePicker/HideTimePicker
button/icon) rather than scanning all <i> elements; then assert presence of the
expected classes on the targeted element.
🪄 Autofix (Beta)
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: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 9cf92349-ba81-4127-ae46-ae8f4b82ed01
📒 Files selected for processing (6)
src/BlazorUI/Bit.BlazorUI/Components/Inputs/DateRangePicker/BitDateRangePicker.razorsrc/BlazorUI/Bit.BlazorUI/Components/Inputs/DateRangePicker/BitDateRangePicker.razor.cssrc/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/Pages/Components/Inputs/DateRangePicker/BitDateRangePickerDemo.razorsrc/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/Pages/Components/Inputs/DateRangePicker/BitDateRangePickerDemo.razor.cssrc/BlazorUI/Demo/Client/Bit.BlazorUI.Demo.Client.Core/Pages/Components/Inputs/DateRangePicker/BitDateRangePickerDemo.razor.samples.cssrc/BlazorUI/Tests/Bit.BlazorUI.Tests/Components/Inputs/DateRangePicker/BitDateRangePickerTests.cs
...azorUI.Demo.Client.Core/Pages/Components/Inputs/DateRangePicker/BitDateRangePickerDemo.razor
Show resolved
Hide resolved
src/BlazorUI/Bit.BlazorUI/Components/Inputs/DateRangePicker/BitDateRangePicker.razor
Outdated
Show resolved
Hide resolved
src/BlazorUI/Bit.BlazorUI/Components/Inputs/DateRangePicker/BitDateRangePicker.scss
Show resolved
Hide resolved
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
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.
closes #12197
Summary by CodeRabbit
New Features
Documentation
Tests