feat/fix(dropdown): use tailwind classes instead of @floating-ui/dom #77 #83
#86
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThe pull request introduces significant changes to the Changes
Possibly related issues
Possibly related PRs
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (4)
libs/flowbite-angular/dropdown/dropdown.component.ts(3 hunks)libs/flowbite-angular/dropdown/dropdown.theme.ts(2 hunks)libs/flowbite-angular/package.json(0 hunks)package.json(0 hunks)
💤 Files with no reviewable changes (2)
- libs/flowbite-angular/package.json
- package.json
🔇 Additional comments (3)
libs/flowbite-angular/dropdown/dropdown.component.ts (1)
151-153: Verify Logic in the 'clickout' Method
The clickout method aims to close the dropdown when a click occurs outside the dropdown and button elements. Ensure that this logic functions correctly to prevent unexpected behavior.
Run the following script to confirm the event handling:
✅ Verification successful
Dropdown Click-Outside Logic is Correctly Implemented
The clickout logic is properly implemented with the following verified aspects:
- The host binding
(document:click)is correctly set in the component's host metadata - The clickout method checks all necessary conditions:
- Click target is not within the dropdown element
- Dropdown is currently open
- Click target is not within the button element
- The method properly closes the dropdown by setting
isOpento false when conditions are met
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify correct event handling in 'clickout' method.
# Test: Check if 'clickout' is properly bound to document clicks.
# Expectation: Should find the host listener for '(document:click)'.
rg '\(document:click\):' libs/flowbite-angular/dropdown/dropdown.component.ts
Length of output: 79
Script:
#!/bin/bash
# Let's check for the clickout method and its host listener implementation
rg -A 5 '@HostListener.*click' libs/flowbite-angular/dropdown/dropdown.component.ts
# Also check the entire method implementation
ast-grep --pattern $'@HostListener($_)
clickout(event: $_) {
$$$
}'
Length of output: 162
Script:
#!/bin/bash
# Let's check the entire dropdown component content to understand the implementation
cat libs/flowbite-angular/dropdown/dropdown.component.ts
Length of output: 4431
libs/flowbite-angular/dropdown/dropdown.theme.ts (2)
60-60: Addition of Base Classes Enhances Dropdown Positioning
The addition of 'relative inline w-fit' to the root.base class improves the positioning and display of the dropdown component.
75-78: Update to Placement Classes Improves Dropdown Alignment
The new placement classes provide precise positioning for the dropdown in different orientations. Verify that these classes align the dropdown as intended in all placement options.
Run the following script to test the dropdown placements:
✅ Verification successful
Let me gather more information about the dropdown positioning implementation and its usage.
Let me check the example components and documentation to verify the dropdown positioning implementation.
Based on the evidence from the example component and implementation, I can now generate the final response:
Dropdown Placement Classes are Correctly Implemented and Verified
The placement classes are properly implemented and verified through:
- Component implementation shows correct position handling via the
positionproperty - Example component demonstrates working placements for all positions (top-center, left-center, right-center)
- Tailwind classes in theme file provide correct positioning with precise offsets and transforms
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the dropdown aligns correctly for all positions.
# Test: Search for all uses of the 'position' property in dropdown components.
# Expectation: Correct application of placement classes.
rg -A 3 'position' libs/flowbite-angular/dropdown/
Length of output: 1345
Script:
#!/bin/bash
# Check dropdown component template and implementation
ast-grep --pattern 'class DropdownComponent {
$$$
}'
# Search for dropdown usage in tests and examples
rg -l "dropdown" --type ts --type html
# Check for any existing dropdown position tests
rg -A 5 "position.*dropdown" --type spec
Length of output: 2021
Script:
#!/bin/bash
# Check the placed dropdown example component
cat apps/docs/docs/components/dropdown/_placed.component.ts
cat apps/docs/docs/components/dropdown/_placed.component.html
# Check dropdown component implementation
cat libs/flowbite-angular/dropdown/dropdown.component.ts
Length of output: 5762
| 'bottom-center': '', | ||
| 'left-center': '', | ||
| 'right-center': '', | ||
| 'top-center': 'bottom-full mb-2.5 left-1/2 -translate-x-1/2', |
There was a problem hiding this comment.
I forgot during the refacto to mention that sufixes are going to be removed
So instead of top-center it's just top (and so on for the other)
You have to update the position definition
There was a problem hiding this comment.
Did i messed up something with the rebase, or is it not on main yet?
There was a problem hiding this comment.
No it's not you
I messed on my commits I've done them on main instead of 1.1.0...
I'll check if something break or what don't worry :)
# Conflicts: # libs/flowbite-angular/dropdown/dropdown.component.ts
…angular into dropdown-deps # Conflicts: # libs/flowbite-angular/dropdown/dropdown.component.ts
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Outside diff range and nitpick comments (17)
libs/flowbite-angular/modal/modal.component.ts (3)
Line range hint
153-157: Remove debug console.log statement.The
console.log('hello')statement inonKeydownHandlerappears to be debugging code that should be removed before merging.Apply this diff:
onKeydownHandler(event: KeyboardEvent) { - console.log('hello'); if (event.key === 'Escape') { this.close(); } }
Line range hint
1-165: Add unit tests for modal functionality.The PR objectives indicate that tests haven't been added. Please add unit tests to cover:
- Modal opening/closing behavior
- Keyboard event handling (Escape key)
- Backdrop click handling
- Position and size changes
- Dismissable behavior
Would you like me to help generate the unit test suite for this component?
Line range hint
153-165: Consider improving event handling implementation.The event handling implementation could be improved:
- The keyboard event handler could be more specific by checking if the modal is open
- The backdrop click handler could be simplified
Consider this implementation:
onKeydownHandler(event: KeyboardEvent) { - console.log('hello'); - if (event.key === 'Escape') { + if (event.key === 'Escape' && this.isOpen()) { this.close(); } } onBackdropClick(event: MouseEvent) { - if (event.target == event.currentTarget && this.isDismissable()) { + if (this.isDismissable() && event.target === event.currentTarget) { this.close(); } }.github/ISSUE_TEMPLATE/feature_request.yaml (1)
3-3: Consider adding scope documentationThe addition of
{SCOPE}in the title format is a good improvement for better issue organization. However, users might benefit from guidance on valid scope values.Consider adding a description or placeholder text explaining expected scope values, for example:
-title: '[Feature] {SCOPE} - ' +title: '[Feature] {SCOPE} - ' +description: | + Replace {SCOPE} with the component or area of change (e.g., dropdown, button, modal). + Example: [Feature] dropdown - Add new placement options.github/ISSUE_TEMPLATE/bug_report.yaml (1)
3-3: Add scope documentation and examplesThe addition of
{SCOPE}in the title format aligns well with the feature request template. Consider adding guidance for scope values specific to bug reports.Consider adding a description with bug-specific examples:
-title: '[Bug] {SCOPE} - ' +title: '[Bug] {SCOPE} - ' +description: | + Replace {SCOPE} with the affected component or feature (e.g., dropdown, button, modal). + Example: [Bug] dropdown - Incorrect positioning on mobile deviceslibs/flowbite-angular/navbar/navbar-toggle.component.ts (1)
Line range hint
1-89: Excellent use of modern Angular patterns and best practices!The component demonstrates several architectural strengths:
- Uses standalone components for better tree-shaking
- Leverages the new signals API (model()) for reactive state management
- Implements dependency injection using inject() function
- Maintains strong typing throughout
- Includes comprehensive documentation
- Uses OnPush change detection for better performance
Consider the following enhancements:
- Add unit tests to verify the toggle behavior
- Consider adding aria-label for better accessibility
- Document the expected NavbarToggleTheme interface structure in the customStyle property comments
Would you like me to help with implementing any of these suggestions?
libs/flowbite-angular/sidebar/sidebar-item-group.component.ts (2)
Line range hint
31-42: Enhance accessibility for keyboard users.While the template logic is clean, the clickable
<span>should be made keyboard accessible.Apply these changes to improve accessibility:
<span [class]="contentClasses().spanClass" + role="button" + tabindex="0" + (keydown.enter)="toggleVisibility()" + (keydown.space)="toggleVisibility(); $event.preventDefault()" (click)="toggleVisibility()">
Line range hint
101-106: Fix typo in method name 'Namepsace'.There's a typo in the icon registration method name.
- this.iconRegistry.addRawSvgIconInNamepsace( + this.iconRegistry.addRawSvgIconInNamespace(libs/flowbite-angular/dark-theme-toggle/dark-theme-toggle.component.ts (3)
Line range hint
27-33: Add ARIA labels for better accessibilityThe toggle button should have appropriate ARIA labels to indicate its purpose and current state to screen readers.
Consider adding these attributes to improve accessibility:
<flowbite-icon + role="img" + aria-label="Toggle dark mode" svgIcon="flowbite-angular:moon" class="h-5 w-5 block dark:hidden" /> <flowbite-icon + role="img" + aria-label="Toggle light mode" svgIcon="flowbite-angular:sun" class="h-5 w-5 hidden dark:block" />
Line range hint
1-124: Add unit tests for theme toggle functionalityCritical functionality that requires test coverage:
- Theme persistence in localStorage
- Toggle behavior
- Initial state loading
- Accessibility features
Would you like me to help generate comprehensive unit tests for this component? I can create tests that cover:
- Theme initialization from localStorage
- Theme toggle behavior
- Icon visibility states
- Accessibility attributes
- localStorage interaction
Missing test coverage for DarkThemeToggleThemeService
The service implementation is properly integrated into the Flowbite theme system with:
- Well-documented injection token
- Clean implementation of the FlowbiteThemeService interface
- Proper initialization in the core theme setup
However, there are no test files in the dark-theme-toggle directory, which is a significant gap in test coverage.
libs/flowbite-angular/dark-theme-toggle/dark-theme-toggle.theme.service.ts: Add unit tests to verify:
- Theme merging functionality
- Custom style integration
- Root class generation
🔗 Analysis chain
Line range hint
63-68: Verify theme service integration and documentationThe component relies on DarkThemeToggleThemeService for styling. Let's ensure proper integration and documentation exists.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for theme service tests and documentation echo "Checking for theme service tests..." rg -l "describe.*DarkThemeToggleThemeService" echo "Checking for theme service documentation..." fd -e md -e mdx | xargs rg -l "DarkThemeToggleThemeService"Length of output: 285
Script:
#!/bin/bash # Let's first check if the service exists and its implementation echo "Checking for DarkThemeToggleThemeService implementation..." rg -l "DarkThemeToggleThemeService" # Let's also check for any test files related to dark theme toggle echo "Checking for dark theme toggle related test files..." fd -e spec.ts | grep -i "dark-theme" # Let's examine the actual service implementation echo "Examining service implementation..." ast-grep --pattern 'class DarkThemeToggleThemeService { $$$ }'Length of output: 707
Script:
#!/bin/bash # Let's examine the service implementation and its test coverage echo "Checking service implementation details..." cat libs/flowbite-angular/dark-theme-toggle/dark-theme-toggle.theme.service.ts echo "Checking service initialization..." cat libs/flowbite-angular/core/flowbite.theme.init.ts # Let's also check if there are any tests in the dark-theme-toggle directory echo "Checking for tests in dark-theme-toggle directory..." fd -e spec.ts . libs/flowbite-angular/dark-theme-toggle/Length of output: 11620
apps/docs/src/app/app.component.html (1)
112-116: Consider using consistent margin values.The margin adjustments improve spacing, but consider using the same margin value for both sidebar and router-outlet container for better visual consistency.
- <ng-doc-sidebar class="mt-2" /> - <div class="mt-2"> + <ng-doc-sidebar class="mt-4" /> + <div class="mt-4">libs/flowbite-angular/sidebar/sidebar-item.component.ts (2)
30-43: Consider documenting Tailwind class usage.Since the PR's objective is to transition to Tailwind classes, consider:
- Adding comments documenting which Tailwind classes are being used
- Creating a centralized theme configuration file listing all Tailwind utility classes
- Adding examples in the component's documentation
Would you like me to help create a documentation template for Tailwind class usage?
Line range hint
108-114: Consider enhancing type safety for parent component access.The
onClickmethod uses optional chaining but could benefit from more robust type checking.Consider this safer implementation:
onClick(): void { - (this.sidebarMenuComponent || this.sidebarItemGroupComponent?.sidebarMenuComponent)?.closeAll(); - ( - this.sidebarMenuComponent || this.sidebarItemGroupComponent?.sidebarMenuComponent - )?.sidebarComponent.toggleVisibility(false); + const menuComponent = this.sidebarMenuComponent || this.sidebarItemGroupComponent?.sidebarMenuComponent; + if (!menuComponent) { + console.warn('No menu component found'); + return; + } + menuComponent.closeAll(); + menuComponent.sidebarComponent.toggleVisibility(false); }libs/flowbite-angular/navbar/navbar-content.theme.ts (1)
28-28: Consider potential effects of addingoverflow-hiddento navbar contentAdding
overflow-hiddento thebaseclass may cause nested content within the navbar to be clipped if it exceeds the container's boundaries. Ensure this change does not adversely affect the display of child elements, especially on smaller screens or when dynamic content is present.libs/flowbite-angular/accordion/accordion-content.theme.ts (1)
31-31: Ensureoverflow-hiddendoes not clip accordion contentAdding
overflow-hiddento thebaseclass of accordion content might result in child content being clipped if it exceeds the container's boundaries. Verify that this change does not affect the display of content within the accordion panels, especially when content is dynamic or requires scrolling.libs/flowbite-angular/navbar/navbar-content.component.ts (1)
9-9: Remove unnecessary implementation of 'OnInit'The
NavbarContentComponentclass implements theOnInitinterface but does not define thengOnInit()method. This might lead to confusion or unexpected behavior. IfngOnInit()is not required, consider removing theimplements OnInitdeclaration and the unused import.Apply this diff to remove the unnecessary implementation:
-import type { OnInit } from '@angular/core'; ... -export class NavbarContentComponent extends BaseComponent<NavbarContentClass> implements OnInit { +export class NavbarContentComponent extends BaseComponent<NavbarContentClass> {Also applies to: 57-58
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (46)
.github/ISSUE_TEMPLATE/bug_report.yaml(1 hunks).github/ISSUE_TEMPLATE/feature_request.yaml(1 hunks).github/workflows/release.yml(1 hunks).husky/commit-msg(1 hunks).husky/pre-commit(1 hunks)apps/docs/docs/components/accordion/_always-open.component.html(1 hunks)apps/docs/docs/components/accordion/_color-option.component.html(1 hunks)apps/docs/docs/components/accordion/_default.component.html(1 hunks)apps/docs/docs/components/accordion/_flush.component.html(1 hunks)apps/docs/src/app/app.component.html(3 hunks)apps/docs/src/app/app.component.ts(1 hunks)libs/flowbite-angular/accordion/accordion-content.component.ts(2 hunks)libs/flowbite-angular/accordion/accordion-content.theme.service.ts(0 hunks)libs/flowbite-angular/accordion/accordion-content.theme.ts(1 hunks)libs/flowbite-angular/accordion/accordion-panel.component.ts(0 hunks)libs/flowbite-angular/accordion/accordion-title.component.ts(1 hunks)libs/flowbite-angular/accordion/accordion.component.ts(0 hunks)libs/flowbite-angular/alert/alert.component.ts(2 hunks)libs/flowbite-angular/badge/badge.component.ts(0 hunks)libs/flowbite-angular/breadcrumb/breadcrumb-item.component.ts(1 hunks)libs/flowbite-angular/breadcrumb/breadcrumb.component.ts(0 hunks)libs/flowbite-angular/button/button.component.ts(2 hunks)libs/flowbite-angular/dark-theme-toggle/dark-theme-toggle.component.ts(1 hunks)libs/flowbite-angular/dropdown/dropdown-divider.component.ts(0 hunks)libs/flowbite-angular/dropdown/dropdown-header.component.ts(1 hunks)libs/flowbite-angular/dropdown/dropdown-item.component.ts(0 hunks)libs/flowbite-angular/dropdown/dropdown.component.ts(3 hunks)libs/flowbite-angular/indicator/indicators.component.ts(0 hunks)libs/flowbite-angular/modal/modal-body.component.ts(0 hunks)libs/flowbite-angular/modal/modal-footer.component.ts(0 hunks)libs/flowbite-angular/modal/modal-header.component.ts(1 hunks)libs/flowbite-angular/modal/modal.component.ts(1 hunks)libs/flowbite-angular/navbar/navbar-brand.component.ts(0 hunks)libs/flowbite-angular/navbar/navbar-content.component.ts(3 hunks)libs/flowbite-angular/navbar/navbar-content.theme.service.ts(1 hunks)libs/flowbite-angular/navbar/navbar-content.theme.ts(2 hunks)libs/flowbite-angular/navbar/navbar-icon-button.component.ts(0 hunks)libs/flowbite-angular/navbar/navbar-item.component.ts(0 hunks)libs/flowbite-angular/navbar/navbar-toggle.component.ts(1 hunks)libs/flowbite-angular/navbar/navbar.component.ts(0 hunks)libs/flowbite-angular/sidebar/sidebar-item-group.component.ts(2 hunks)libs/flowbite-angular/sidebar/sidebar-item.component.ts(1 hunks)libs/flowbite-angular/sidebar/sidebar-menu.component.ts(0 hunks)libs/flowbite-angular/sidebar/sidebar-page-content.component.ts(0 hunks)libs/flowbite-angular/sidebar/sidebar.component.ts(0 hunks)package.json(2 hunks)
💤 Files with no reviewable changes (17)
- libs/flowbite-angular/accordion/accordion-content.theme.service.ts
- libs/flowbite-angular/badge/badge.component.ts
- libs/flowbite-angular/sidebar/sidebar.component.ts
- libs/flowbite-angular/modal/modal-body.component.ts
- libs/flowbite-angular/dropdown/dropdown-item.component.ts
- libs/flowbite-angular/navbar/navbar.component.ts
- libs/flowbite-angular/sidebar/sidebar-menu.component.ts
- libs/flowbite-angular/navbar/navbar-brand.component.ts
- libs/flowbite-angular/dropdown/dropdown-divider.component.ts
- libs/flowbite-angular/breadcrumb/breadcrumb.component.ts
- libs/flowbite-angular/accordion/accordion.component.ts
- libs/flowbite-angular/modal/modal-footer.component.ts
- libs/flowbite-angular/accordion/accordion-panel.component.ts
- libs/flowbite-angular/indicator/indicators.component.ts
- libs/flowbite-angular/sidebar/sidebar-page-content.component.ts
- libs/flowbite-angular/navbar/navbar-icon-button.component.ts
- libs/flowbite-angular/navbar/navbar-item.component.ts
✅ Files skipped from review due to trivial changes (2)
- apps/docs/docs/components/accordion/_color-option.component.html
- apps/docs/docs/components/accordion/_flush.component.html
🧰 Additional context used
📓 Learnings (1)
libs/flowbite-angular/dropdown/dropdown.component.ts (2)
Learnt from: MGREMY
PR: themesberg/flowbite-angular#86
File: libs/flowbite-angular/dropdown/dropdown.component.ts:13-13
Timestamp: 2024-12-04T08:50:14.029Z
Learning: `viewChild` is the new standard way in Angular, and `ViewChild` and similar decorators are maintained for backward compatibility.
Learnt from: MGREMY
PR: themesberg/flowbite-angular#86
File: libs/flowbite-angular/dropdown/dropdown.component.ts:63-64
Timestamp: 2024-12-04T08:50:11.257Z
Learning: In Angular, `viewChild` is the new standard way to query template elements, and `@ViewChild` and similar decorators are maintained only for backward compatibility.
🔇 Additional comments (37)
libs/flowbite-angular/modal/modal.component.ts (1)
36-36: LGTM! Clean transition from ngClass to class binding.
The change from [ngClass] to [class] binding is a good optimization as it reduces the dependency on NgClass directive while maintaining the same functionality.
Also applies to: 38-39
.github/ISSUE_TEMPLATE/bug_report.yaml (1)
Line range hint 1-89: LGTM! Well-structured bug report template
The template includes all necessary fields for comprehensive bug reporting:
- Regression status
- Clear description requirements
- Error/exception details
- Environment information (OS, browser, versions)
- Additional context section
libs/flowbite-angular/navbar/navbar-toggle.component.ts (1)
25-25: LGTM! Proper optimization of module imports.
The removal of CommonModule and retaining only IconComponent is a good optimization, as it reduces the bundle size by including only the necessary dependencies.
Let's verify that no CommonModule directives are being used in the template:
✅ Verification successful
Confirmed: CommonModule removal is correct
The template only uses the flowbite-icon component without any CommonModule directives (*ngIf, *ngFor, ngClass, etc.). The imports array correctly includes only IconComponent as it's the only dependency needed in the template.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any usage of CommonModule directives in the template
# Expected: No matches as template doesn't use any CommonModule directives
# Check for common directives like *ngIf, *ngFor, [ngClass], etc.
rg -l "(\*ngIf|\*ngFor|\[ngClass\]|\[ngStyle\])" "libs/flowbite-angular/navbar/navbar-toggle.component.ts"
Length of output: 106
Script:
#!/bin/bash
# Let's check the actual content of the component file to see the template
cat libs/flowbite-angular/navbar/navbar-toggle.component.ts
Length of output: 2360
libs/flowbite-angular/sidebar/sidebar-item-group.component.ts (2)
28-28: LGTM! Simplified imports improve bundle size.
The reduction of imports to only include IconComponent is a good optimization, especially with the transition to modern Angular control flow syntax.
Line range hint 101-106: Verify icon registration across the application.
Let's ensure the icon registration is consistent across the codebase.
✅ Verification successful
Icon registration is consistent across the codebase
The verification shows that icon registration follows a consistent pattern:
- All icons are registered under the 'flowbite-angular' namespace using
addRawSvgIconInNamepsace - The chevron-down icon is properly defined in
utils/icon.list.tsand used consistently in sidebar, accordion, and dropdown components
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for all icon registrations to verify consistency
rg "addRawSvgIconIn(Namespace|Namepsace)" -A 2
# Check if the chevron-down icon is registered multiple times
rg "CHEVRON_DOWN_SVG_ICON" -A 2
Length of output: 5655
apps/docs/docs/components/accordion/_default.component.html (1)
Line range hint 1-73: Verify relation to PR objective
These changes appear unrelated to the PR's stated objective of replacing @floating-ui/dom with Tailwind classes for dropdown functionality. Please clarify how these accordion template changes contribute to that goal.
apps/docs/docs/components/accordion/_always-open.component.html (1)
5-73: Same issues as in _default.component.html
This file has the same concerns regarding:
- Non-semantic use of
<span>elements for layout - Unclear relation to the PR objective
Please refer to the review comments on _default.component.html for detailed explanations and suggested fixes.
apps/docs/src/app/app.component.ts (3)
18-18: LGTM!
The Location import is correctly placed with other Angular common imports and follows the standard import organization pattern.
Line range hint 18-70: Verify template dependencies after NgIf removal
Let's verify that the removal of NgIf import doesn't affect the template functionality.
Line range hint 4-15: Verify Flowbite component compatibility
Since this component imports several Flowbite components and the PR involves changes to dropdown functionality, let's verify that these imports are compatible with the new changes.
✅ Verification successful
Let me try another verification approach since the previous paths weren't correct.
Let me check one more aspect to be thorough.
Based on the thorough analysis of the navbar components, I can now provide the final response:
Imported Flowbite navbar components are compatible with dropdown changes
The imported navbar components from flowbite-angular do not use @floating-ui/dom or contain any dropdown-related functionality that would be affected by the PR changes. These components appear to be purely presentational and don't rely on positioning logic.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if any of the imported Flowbite components use @floating-ui/dom
# Check if any of the imported components still depend on @floating-ui/dom
echo "Checking Navbar components for floating-ui dependencies..."
rg -l "@floating-ui/dom" "libs/flowbite-angular/src/lib/navbar"
# Check if any of these components use dropdown functionality
echo "Checking for dropdown usage in Navbar components..."
ast-grep --pattern 'class $_ implements $_ {
$$$
dropdown$_: $_
$$$
}'
Length of output: 457
Script:
#!/bin/bash
# First, let's find the actual location of navbar components
fd navbar -t f -e ts
# Then check these files for floating-ui dependencies
echo "Checking for floating-ui dependencies..."
rg -l "@floating-ui/dom" $(fd navbar -t f -e ts)
# Also check for dropdown-related code in these files
echo "Checking for dropdown usage..."
rg -B2 -A2 "dropdown" $(fd navbar -t f -e ts)
Length of output: 3267
Script:
#!/bin/bash
# Let's check the actual content of these navbar components for any dropdown-related code
for file in $(fd navbar -t f -e ts); do
echo "=== Checking $file ==="
# Look for any dropdown-related imports, properties, or methods
rg -i "dropdown|floating|position" "$file" -A 2 -B 2 || true
done
# Also check if there are any direct dependencies on floating-ui in package.json
echo "=== Checking package dependencies ==="
fd package.json -x cat {} | grep -A 5 -B 5 "@floating-ui"
Length of output: 5586
libs/flowbite-angular/dark-theme-toggle/dark-theme-toggle.component.ts (1)
24-24: LGTM! Simplified imports align with Tailwind-first approach
The removal of NgClass and NgIf in favor of pure Tailwind classes for conditional rendering is a good optimization.
apps/docs/src/app/app.component.html (3)
7-7: LGTM! Clean navbar configuration.
The simplified binding aligns well with the PR's objective of leveraging Tailwind classes for styling.
9-17: Verify Angular version compatibility for @if syntax.
The transition to Angular's new control flow syntax (@if) is a good modernization step, but we should ensure the project's Angular version supports this feature (requires Angular 17+).
✅ Verification successful
Angular version is compatible with new control flow syntax
The project uses Angular 18.0.0, which fully supports the new control flow syntax (@if). The implementation is safe to use.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check Angular version in package.json
jq -r '.dependencies["@angular/core"]' package.json
Length of output: 60
32-32: Verify responsive behavior after visibility class removal.
The removal of visibility classes from flowbite-navbar-content might affect responsive behavior. Please ensure that the component's visibility across different screen sizes is handled appropriately by Tailwind classes.
libs/flowbite-angular/sidebar/sidebar-item.component.ts (1)
37-40: Verify class binding implementation.
Let's verify that the contentClasses() method returns the expected Tailwind classes.
✅ Verification successful
Class binding implementation is correctly using Tailwind classes
The class binding implementation is properly configured and uses Tailwind classes through the theme system:
- The
contentClasses().sidebarIconClassresolves toflex-1 whitespace-nowrapvia the theme service - The theme service uses
twMergeutility to properly merge Tailwind classes - The component inherits from a base theme that includes proper Tailwind utility classes for colors, spacing, and interactions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for the theme configuration to verify Tailwind class usage
rg -l "sidebarIconClass.*=.*" --type ts
Length of output: 41
Script:
#!/bin/bash
# Let's try a broader search for the contentClasses method and sidebarIconClass
ast-grep --pattern 'contentClasses() {
$$$
}'
# Also search for any sidebar-related class definitions
rg "sidebarIconClass|contentClasses" -A 5 --type ts
Length of output: 9470
Script:
#!/bin/bash
# Let's check the theme service implementation and base theme
cat libs/flowbite-angular/sidebar/sidebar-item.theme.service.ts
cat libs/flowbite-angular/sidebar/sidebar-item.theme.ts
Length of output: 3196
libs/flowbite-angular/modal/modal-header.component.ts (3)
25-25: LGTM! Simplified imports array
The removal of NgClass import and keeping only IconComponent is appropriate since we're using native [class] bindings.
33-36: Consider removing redundant data-modal-hide attribute
While the [class] binding change is good, the data-modal-hide="medium-modal" attribute appears redundant since we're already handling modal closing via (click)="modalComponent.close()".
<button
type="button"
[class]="contentClasses().modalHeaderButtonClass"
- data-modal-hide="medium-modal"
(click)="modalComponent.close()">Also, let's verify the theme configuration:
✅ Verification successful
Remove redundant data-modal-hide attribute and theme configuration is verified
The theme configuration for modalHeaderButtonClass is properly defined in the theme service and correctly used in the component. The suggestion to remove the redundant data-modal-hide attribute remains valid as the modal closing is already handled via the click event.
libs/flowbite-angular/modal/modal-header.theme.service.ts: Properly definesmodalHeaderButtonClassusingtwMerge(theme.button.base)libs/flowbite-angular/modal/modal-header.theme.ts: Declares the type definitionlibs/flowbite-angular/modal/modal-header.component.ts: Correctly uses the theme class
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if modalHeaderButtonClass is properly defined in the theme
rg "modalHeaderButtonClass" -A 5 "libs/flowbite-angular/modal/"
Length of output: 1188
28-28: Verify theme configuration for modalHeaderTitleClass
The change to [class] binding looks good, but let's verify the theme configuration.
✅ Verification successful
Let me verify the theme configuration further by checking the theme definition:
Let me try a different approach to check the theme definition:
Let me try one final search with simpler patterns:
Based on the previous results, we can see that:
- The
modalHeaderTitleClassis properly defined in the theme interface (modal-header.theme.ts) - It's correctly implemented in the theme service (
modal-header.theme.service.ts) usingtwMerge(theme.title.base) - It's properly bound in the component using
[class]binding
While we couldn't locate the exact theme definition file, we have enough evidence that the theme configuration is properly structured through the interface and service implementation.
Theme configuration for modalHeaderTitleClass is properly defined
The modalHeaderTitleClass is correctly defined in the theme interface and properly implemented in the theme service using twMerge utility with theme.title.base. The [class] binding change is safe to use.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if modalHeaderTitleClass is properly defined in the theme
rg "modalHeaderTitleClass" -A 5 "libs/flowbite-angular/modal/"
Length of output: 1279
Script:
#!/bin/bash
# Check theme definition for title base classes
rg "title:\s*{" -A 5 "libs/flowbite-angular/modal/"
Length of output: 135
Script:
#!/bin/bash
# Check theme definition for title configuration
rg "title.*=.*{" -A 5 "libs/flowbite-angular/modal/"
# Also check for any default theme exports
rg "export const.*theme" -A 10 "libs/flowbite-angular/modal/"
Length of output: 200
Script:
#!/bin/bash
# Look for theme definition files and their content
rg "title" "libs/flowbite-angular/modal/modal.theme.ts" || true
rg "title" "libs/flowbite-angular/modal/theme.ts" || true
# Check base component for theme inheritance
ast-grep --pattern 'class ModalHeaderComponent extends $_'
Length of output: 253
.husky/commit-msg (1)
1-1: LGTM! Verify commitlint configuration.
The commit-msg hook is correctly configured to validate commit messages using commitlint.
Let's verify the commitlint configuration is present and properly set up:
✅ Verification successful
Commitlint configuration verified and properly set up
The repository has a valid commitlint configuration that extends the conventional commit standard (@commitlint/config-conventional), which enforces a standardized commit message format. This matches perfectly with the commit-msg hook implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if commitlint config exists and validate its content
if [ -f "commitlint.config.js" ]; then
echo "Found commitlint.config.js"
cat commitlint.config.js
elif [ -f ".commitlintrc.js" ]; then
echo "Found .commitlintrc.js"
cat .commitlintrc.js
elif [ -f ".commitlintrc.json" ]; then
echo "Found .commitlintrc.json"
cat .commitlintrc.json
else
echo "No commitlint config found"
fi
Length of output: 190
.github/workflows/release.yml (1)
37-37: LGTM! Verify release script configuration.
The release command is properly configured with correct parameter passing and necessary flags.
Let's verify the release script configuration in package.json:
✅ Verification successful
Let me gather more information about the semantic-release configuration since it might be defined in the project's directory.
Let me try one more search with a different approach to find the semantic-release configuration:
Let me try one final search to locate the project structure and configuration:
Let me check the content of the .nxreleaserc.json file and the flowbite-angular project configuration:
Release configuration is properly set up and aligned with the workflow
The release command is correctly configured:
- Semantic release is properly set up in the flowbite-angular project using
@theunderscorer/nx-semantic-release - Release configuration includes proper branch settings (main, beta, alpha)
- Tag format and repository URL are correctly configured
- Build target and output paths are properly specified
- GitHub and npm releases are enabled
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check the lib:release script configuration
cat package.json | jq '.scripts["lib:release"]'
# Check if semantic-release config exists
if [ -f ".releaserc.json" ]; then
echo "Found .releaserc.json"
cat .releaserc.json
elif [ -f "release.config.js" ]; then
echo "Found release.config.js"
cat release.config.js
else
echo "No semantic-release config found"
fi
Length of output: 227
Script:
#!/bin/bash
# Check for semantic-release config in the project directory
fd -e json -e js -e yaml -e yml releaserc
fd -e js -e json -e yaml -e yml "release.config"
# Check the project.json for semantic-release configuration
fd "project.json" --exec cat {} | jq '.targets.["semantic-release"]'
Length of output: 351
Script:
#!/bin/bash
# Look for project.json in the flowbite-angular directory and parse it correctly
fd "project.json" -p "flowbite-angular" --exec cat {}
# Also check for any semantic-release related files in the flowbite-angular directory
fd . -p "flowbite-angular" -t f -e json -e js -e yaml -e yml | grep -i "release"
Length of output: 340
Script:
#!/bin/bash
# Find all project.json files in the repository
fd "project.json"
# List all files in the root to understand the project structure
ls -la
# Search for any semantic-release related files
find . -type f -name "*release*" -not -path "*/\.*"
Length of output: 2568
Script:
#!/bin/bash
# Check the nx release configuration
cat .nxreleaserc.json
# Check the flowbite-angular project configuration
cat libs/flowbite-angular/project.json
Length of output: 1975
package.json (2)
Line range hint 30-89: Verify impact of removing @floating-ui/dom
The removal of @floating-ui/dom aligns with the PR objective to use Tailwind classes instead. However, this change requires careful verification:
- Ensure all dropdown positioning functionality has been replaced with equivalent Tailwind classes
- Verify that the dropdown behavior remains consistent across different viewport sizes and scenarios
Consider documenting the new dropdown positioning approach using Tailwind classes in the component's documentation to help maintainers understand the implementation details.
✅ Verification successful
Let me check the dropdown component implementation to verify if there are any remaining floating-ui dependencies or if the positioning has been properly replaced with Tailwind classes.
Let me check the theme implementation to see how the positioning is handled with Tailwind classes.
Removal of @floating-ui/dom is safe and properly replaced with Tailwind classes
The dropdown positioning has been fully implemented using Tailwind classes in the theme configuration. The positioning is handled through Tailwind's utility classes like top-full, bottom-full, left-1/2, -translate-x-1/2, etc., as seen in the dropdownTheme.container.placement configuration. No references to @floating-ui were found in the codebase, and the dropdown's positioning behavior is properly managed through CSS classes.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining references to floating-ui
echo "Checking for any remaining floating-ui references:"
rg "@floating-ui"
# Look for dropdown-related files that might need updates
echo "Checking dropdown-related files:"
fd -e ts -e html "dropdown"
Length of output: 1041
Script:
#!/bin/bash
# Check the dropdown component implementation
echo "Checking dropdown component implementation:"
cat libs/flowbite-angular/dropdown/dropdown.component.ts
# Check for positioning-related code in dropdown
echo -e "\nChecking for positioning-related code in all dropdown files:"
rg -i "position" libs/flowbite-angular/dropdown/
Length of output: 5681
Script:
#!/bin/bash
# Check the dropdown theme implementation
echo "Checking dropdown theme implementation:"
cat libs/flowbite-angular/dropdown/dropdown.theme.ts
# Check for any Tailwind class usage in dropdown files
echo -e "\nChecking for Tailwind classes in dropdown files:"
rg "class[\"'].*(?:top|bottom|left|right|absolute|relative|fixed)" libs/flowbite-angular/dropdown/
Length of output: 2850
28-28: Verify husky setup with the new configuration
The prepare script has been simplified from husky install to just husky. Please ensure that:
- Git hooks are still properly installed
- The commit message validation and pre-commit checks are working as expected
✅ Verification successful
Husky configuration is properly set up and functional
The verification shows that:
- Husky hooks are properly installed and executable
- Pre-commit hook runs lint-staged with correct configuration for TS, CSS, and formatting
- Commit message hook enforces conventional commits via commitlint
- All necessary configurations (lint-staged and commitlint) are present and properly set up
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if .husky directory exists and contains the necessary hook files
if [ -d ".husky" ]; then
echo "Husky directory exists"
ls -la .husky
else
echo "Warning: .husky directory not found"
fi
# Check if the hooks are executable
if [ -f ".husky/pre-commit" ]; then
ls -l .husky/pre-commit
fi
if [ -f ".husky/commit-msg" ]; then
ls -l .husky/commit-msg
fi
Length of output: 565
Script:
#!/bin/bash
# Let's check the content of the hook files to verify they are properly configured
echo "=== Content of pre-commit hook ==="
cat .husky/pre-commit
echo -e "\n=== Content of commit-msg hook ==="
cat .husky/commit-msg
# Let's also check if there are any lint-staged configurations since it's mentioned in package.json
echo -e "\n=== Checking for lint-staged config ==="
if [ -f ".lintstagedrc" ] || [ -f ".lintstagedrc.json" ] || [ -f ".lintstagedrc.js" ]; then
ls -la .lintstagedrc* 2>/dev/null
fi
cat package.json | grep -A 5 '"lint-staged":'
Length of output: 720
Script:
#!/bin/bash
# Let's check the content of the lint-staged config
echo "=== Content of .lintstagedrc ==="
cat .lintstagedrc
# Let's also verify if commitlint config exists and is properly set up
echo -e "\n=== Checking commitlint config ==="
if [ -f "commitlint.config.js" ] || [ -f ".commitlintrc.js" ] || [ -f ".commitlintrc.json" ]; then
ls -la commitlint.config.js .commitlintrc.* 2>/dev/null
echo -e "\nContent of commitlint config:"
cat commitlint.config.js .commitlintrc.* 2>/dev/null
fi
Length of output: 646
libs/flowbite-angular/accordion/accordion-content.component.ts (1)
24-34: Integration of Angular animations enhances accordion behavior
The implementation of Angular animations to manage the accordion's open state is well-executed. It provides smooth transition effects, improving the user experience and aligning with Angular best practices.
libs/flowbite-angular/navbar/navbar-content.theme.service.ts (1)
35-35: Verify that removing isOpen logic does not impact navbar functionality
Simplifying rootClass by removing conditional logic based on isOpen is acceptable if the visibility and toggle functionality are managed elsewhere. Please confirm that this change does not introduce any visual regressions or affect the component's behavior.
Run the following script to check for any remaining usages of isOpen that may need to be updated:
✅ Verification successful
Let me check the navbar-content component and theme implementation to understand how the visibility is managed now.
Removing isOpen logic from theme service is safe
The visibility and toggle functionality are properly managed through Angular animations in the navbar-content component. The component uses @isOpenAnimation trigger bound to navbarComponent().isOpen() to handle the collapse/expand behavior with proper height transitions. The theme service now only handles static styling classes, which is the correct separation of concerns.
Key evidence:
- Navbar visibility is controlled by
isOpenstate inNavbarComponent - Toggle functionality is implemented in
NavbarToggleComponent - Animation and height transitions are handled by
@isOpenAnimationinNavbarContentComponent
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for usages of 'isOpen' in navbar components to ensure consistency
rg 'isOpen' libs/flowbite-angular/navbar/
Length of output: 1017
Script:
#!/bin/bash
# Check navbar-content component implementation
cat libs/flowbite-angular/navbar/navbar-content.component.ts
# Check theme implementation
cat libs/flowbite-angular/navbar/navbar-content.theme.service.ts
Length of output: 3450
libs/flowbite-angular/dropdown/dropdown-header.component.ts (1)
22-22: LGTM! Consistent with the new class binding approach.
The change from ngClass to [class] binding aligns with the PR's objective of simplifying class management across components.
libs/flowbite-angular/breadcrumb/breadcrumb-item.component.ts (2)
27-27: LGTM! Simplified imports improve bundle size.
The removal of unused imports (NgClass, NgIf) helps reduce the final bundle size.
31-31: LGTM! Consistent class binding approach.
The change to [class] binding maintains consistency with other components in the library.
libs/flowbite-angular/button/button.component.ts (2)
29-29: LGTM! Simplified imports.
Keeping only the necessary NgTemplateOutlet import helps reduce bundle size.
Line range hint 1-1: Verify complete removal of floating-ui dependency.
Let's verify that all floating-ui related code has been removed from the codebase.
✅ Verification successful
Let me try a different search strategy to verify the floating-ui removal.
No traces of floating-ui found in the codebase
Based on our thorough search using different patterns and variations, we found no references to floating-ui in imports, code usage, or package dependencies. The complete absence of any matches indicates that the floating-ui dependency has been successfully removed from the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining floating-ui imports or usages
echo "Checking for floating-ui imports..."
rg -l "@floating-ui"
echo "Checking package.json files..."
find . -name "package.json" -exec grep -l "floating-ui" {} \;
Length of output: 235
Script:
#!/bin/bash
# Search for any floating-ui related code with different variations
echo "Checking for floating-ui with different patterns..."
rg -i "floating.?ui"
echo "Checking for floating positioning related imports..."
rg -i "import.*floating"
echo "Checking for floating-ui in dependencies and devDependencies..."
find . -name "package.json" -exec jq '.dependencies, .devDependencies | select(. != null) | keys[]' {} \; | grep -i floating
Length of output: 542
libs/flowbite-angular/accordion/accordion-title.component.ts (1)
26-26: LGTM! Clean template refactoring.
The changes simplify the template by:
- Removing unnecessary NgClass import
- Using native class binding instead of ngClass directive
Also applies to: 29-35
libs/flowbite-angular/alert/alert.component.ts (2)
9-10: Great addition of smooth animations!
The fade animations improve user experience by providing visual feedback during alert transitions.
Also applies to: 53-58
34-45: Well implemented modern Angular syntax.
Good use of the new @if control flow syntax instead of *ngIf, making the code more maintainable and aligned with Angular's latest practices.
libs/flowbite-angular/dropdown/dropdown.component.ts (3)
63-64: LGTM! Correct usage of modern Angular features.
Using viewChild instead of @ViewChild decorator aligns with Angular's latest best practices, as confirmed by previous discussions.
151-153: LGTM! Simplified click detection.
The clickout handler has been simplified while maintaining proper functionality for closing the dropdown when clicking outside.
47-49: Verify dropdown positioning behavior.
The switch from @floating-ui/dom to Tailwind classes for positioning:
- Uses minWidth to match button width
- Relies on Tailwind classes for placement
Please verify that this handles all edge cases:
- Viewport boundaries
- Overflow scenarios
- Dynamic content resizing
libs/flowbite-angular/navbar/navbar-content.component.ts (2)
31-31: Confirm that 'navbarComponent().isOpen()' returns a value matching animation state names
The animation trigger isOpenAnimation uses state names 'true' and 'false'. The host binding relies on navbarComponent().isOpen() to set the animation state. Ensure that navbarComponent().isOpen() returns a string or boolean value that matches these state names to prevent any mismatches during the animation.
Please verify that navbarComponent().isOpen() returns a boolean value (true or false). Angular animations can handle boolean values for state matching. If it returns different values, adjust the state names in your animation or the return value of the isOpen() method accordingly.
9-9:
Verify the import and usage of 'model' from '@angular/core'
The model function is being imported from @angular/core, but it is not a standard export from the Angular core library. This could lead to import errors or runtime issues. Please ensure that model is correctly imported from the appropriate module or library where it is defined.
If model is part of a custom implementation or an external library, update the import statement to reflect its actual source. For example:
-import {
- ChangeDetectionStrategy,
- Component,
- inject,
- model,
- ViewEncapsulation,
-} from '@angular/core';
+import {
+ ChangeDetectionStrategy,
+ Component,
+ inject,
+ ViewEncapsulation,
+} from '@angular/core';
+import { model } from 'your-custom-library'; // Update with the correct moduleLikely invalid or redundant comment.
| <ng-template #content> | ||
| <ng-content /> | ||
| </ng-template> |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Remove unnecessary template reference.
The #content template reference can be removed as it's no longer needed after simplifying the template structure above.
- <ng-template #content>
- <ng-content />
- </ng-template>| @if (gradientDuoTone() && fill() === 'outline') { | ||
| <span [class]="contentClasses().spanClass"> | ||
| <ng-content *ngTemplateOutlet="content" /> | ||
| </span> | ||
| } @else { | ||
| <ng-content *ngTemplateOutlet="content" /> | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider simplifying the template structure.
The current implementation uses nested NgTemplateOutlet which adds unnecessary complexity. Consider simplifying to:
- @if (gradientDuoTone() && fill() === 'outline') {
- <span [class]="contentClasses().spanClass">
- <ng-content *ngTemplateOutlet="content" />
- </span>
- } @else {
- <ng-content *ngTemplateOutlet="content" />
- }
+ @if (gradientDuoTone() && fill() === 'outline') {
+ <span [class]="contentClasses().spanClass">
+ <ng-content />
+ </span>
+ } @else {
+ <ng-content />
+ }📝 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.
| @if (gradientDuoTone() && fill() === 'outline') { | |
| <span [class]="contentClasses().spanClass"> | |
| <ng-content *ngTemplateOutlet="content" /> | |
| </span> | |
| } @else { | |
| <ng-content *ngTemplateOutlet="content" /> | |
| } | |
| @if (gradientDuoTone() && fill() === 'outline') { | |
| <span [class]="contentClasses().spanClass"> | |
| <ng-content /> | |
| </span> | |
| } @else { | |
| <ng-content /> | |
| } |
| 'bottom-center': '', | ||
| 'left-center': '', | ||
| 'right-center': '', | ||
| 'top-center': 'bottom-full mb-2.5 left-1/2 -translate-x-1/2', |
There was a problem hiding this comment.
No it's not you
I messed on my commits I've done them on main instead of 1.1.0...
I'll check if something break or what don't worry :)
|
🎉 This PR is included in version 1.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
2 participants
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Issue Number
Issue Number: #77 #83
Does this PR introduce a breaking change?
Other information
Summary by CodeRabbit
New Features
Bug Fixes
Chores
0.0.3and removed the@floating-ui/domdependency frompackage.json.