Dropdowns: Modified Dropdown's _parent to use a new method called 'closest', to allow dropdown menus to not necessarily be the sibling of the trigger button element. So instead of trying to use dropdown wrapper as the direct parent, it can be an ancestor.
Description
This is a non-breaking improvement change to the Dropdown and Selector Engine JS files. More in the Motivation or context. But the long story short is that inside the dropdown's constructor, instead of setting this._parent to the direct parent element, this change will use a new method for the selector engine called closest which will find the closest ancestor that contains the dropdown menu element. This will then allow a not-so restrictive DOM structure. All existing behaviour as per Bootstrap documentation remains the same.
Motivation & Context
Currently, I'm trying to create web components that use Bootstrap's dropdowns as the main mechanism for our dropdowns in our design system. Currently based on the Dropdown's constructor, this._parent is set to only use the this._element's direct parent. So as per documentation, it allows usages like this:
Which is fine for most use cases. However, in our use case, since it is a design system, we also create web components for things such as buttons like this:
As you can see in the above, the button with the data-bs-toggle which is the element in the dropdown constructor is not a sibling of the .dropdown-menu element, so when the dropdown open is called, the code is stuck because of the restrictive HTML structure.
The proposed changes will address the issue whilst maintaining the original intent of the HTML structure of these elements, and works for the current HTML structure. I have tested this with all of the combinations within the Bootstrap documentation including dropdowns inside navbars, split dropdown and standard default use cases.
In terms of documentation, I don't feel a change is required on that front since all of the use cases in the documentation have not changed.
Type of changes
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Refactoring (non-breaking change)
[ ] Breaking change (fix or feature that would change existing functionality)
Dropdowns: Modified Dropdown's _parent to use a new method called 'closest', to allow dropdown menus to not necessarily be the sibling of the trigger button element. So instead of trying to use dropdown wrapper as the direct parent, it can be an ancestor.
Description
This is a non-breaking improvement change to the Dropdown and Selector Engine JS files. More in the Motivation or context. But the long story short is that inside the dropdown's
constructor, instead of settingthis._parentto the direct parent element, this change will use a new method for the selector engine calledclosestwhich will find the closest ancestor that contains thedropdown menu element. This will then allow a not-so restrictive DOM structure. All existing behaviour as per Bootstrap documentation remains the same.Motivation & Context
Currently, I'm trying to create web components that use Bootstrap's dropdowns as the main mechanism for our dropdowns in our design system. Currently based on the
Dropdown'sconstructor,this._parentis set to only use thethis._element's direct parent. So as per documentation, it allows usages like this:Which is fine for most use cases. However, in our use case, since it is a design system, we also create web components for things such as buttons like this:
On render, the HTML would look something typical to this:
As you can see in the above, the
buttonwith thedata-bs-togglewhich is theelementin the dropdown constructor is not a sibling of the.dropdown-menuelement, so when the dropdown open is called, the code is stuck because of the restrictive HTML structure.The proposed changes will address the issue whilst maintaining the original intent of the HTML structure of these elements, and works for the current HTML structure. I have tested this with all of the combinations within the Bootstrap documentation including dropdowns inside navbars, split dropdown and standard default use cases.
In terms of documentation, I don't feel a change is required on that front since all of the use cases in the documentation have not changed.
Type of changes
Checklist
npm run lint)