You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The "bundled" version of the JS includes Popper, and both Popper and Yew assume complete control of the DOM. Popper-managed components have significant rendering errors when you dynamically add or remove components from a page. This doesn't show up in any of the examples, but is a huge problem with more complicated UIs.
#46 adds support for tooltips using popper-rs, which has proper Yew support. The new Tooltip component in that PR seems to work with both the bundled and non-bundled version of Bootstrap's JS (as well as both Bootstrap 5.1 and 5.3) – because Bootstrap tooltips support is opt-in.
I'm working on dropdowns support in a branch, which I'm extracting from a private project with some fairly complex UI use cases where elements are dynamically added and removed quite frequently (so anything Popper based is completely broken).
There are some challenges with this:
My project was based on Bootstrap 5.3, and there are some subtle differences in the Bootstrap JS such that they don't work properly with Bootstrap 5.1 (eg: keyboard navigation is broken). I'm planning on targetting Bootstrap 5.3 - which should also fix Support for newer Bootstrap versions #41.
The dropdowns JS is triggered by class attributes – it is not opt-in, and there is no opt-out.
The "bundled" version of Bootstrap completely breaks my new components, because its Popper conflicts with what I'm doing on the Yew / popper-rs side.
Using the non-bundled version seems to be better, but I'm still trying to evaluate the best way forward here. I plan to do something similar to react-bootstrap, because React also assumes complete control of the DOM.
The NavDropdown component relies on Popper, so switching to non-bundled Bootstrap JS it will break it. That will need to be re-implemented using popper-rs like Tooltips / Popper support #46.
What I've done in my dropdowns branch with regards to updates so far is:
Add include_cdn_js_bundled() method which uses the bundled JS like include_cdn_js() does today.
Make include_cdn_js() call include_cdn_js_bundled(), marked as #[deprecated], for backward compatibility with existing apps.
Add include_cdn_js_unbundled() method which uses the unbundled JS, make that the recommended entry point (except NavDropdown won't work until the rest of the dropdowns work is in).
I intend to make those updates/splits a separate PR from the rest of the dropdowns work, then have the dropdowns branch deprecate include_cdn_js_bundled().
The "bundled" version of the JS includes Popper, and both Popper and Yew assume complete control of the DOM. Popper-managed components have significant rendering errors when you dynamically add or remove components from a page. This doesn't show up in any of the examples, but is a huge problem with more complicated UIs.
#46 adds support for tooltips using
popper-rs, which has proper Yew support. The new Tooltip component in that PR seems to work with both the bundled and non-bundled version of Bootstrap's JS (as well as both Bootstrap 5.1 and 5.3) – because Bootstrap tooltips support is opt-in.I'm working on dropdowns support in a branch, which I'm extracting from a private project with some fairly complex UI use cases where elements are dynamically added and removed quite frequently (so anything Popper based is completely broken).
There are some challenges with this:
My project was based on Bootstrap 5.3, and there are some subtle differences in the Bootstrap JS such that they don't work properly with Bootstrap 5.1 (eg: keyboard navigation is broken). I'm planning on targetting Bootstrap 5.3 - which should also fix Support for newer Bootstrap versions #41.
The dropdowns JS is triggered by
classattributes – it is not opt-in, and there is no opt-out.The "bundled" version of Bootstrap completely breaks my new components, because its Popper conflicts with what I'm doing on the Yew /
popper-rsside.Using the non-bundled version seems to be better, but I'm still trying to evaluate the best way forward here. I plan to do something similar to
react-bootstrap, because React also assumes complete control of the DOM.The
NavDropdowncomponent relies on Popper, so switching to non-bundled Bootstrap JS it will break it. That will need to be re-implemented usingpopper-rslike Tooltips / Popper support #46.What I've done in my
dropdownsbranch with regards to updates so far is:include_cdn_js_bundled()method which uses the bundled JS likeinclude_cdn_js()does today.include_cdn_js()callinclude_cdn_js_bundled(), marked as#[deprecated], for backward compatibility with existing apps.include_cdn_js_unbundled()method which uses the unbundled JS, make that the recommended entry point (exceptNavDropdownwon't work until the rest of thedropdownswork is in).I intend to make those updates/splits a separate PR from the rest of the
dropdownswork, then have thedropdownsbranch deprecateinclude_cdn_js_bundled().