Targeted parsing and initialization of components #824
+797
−712
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.
I've seen a lot of issues from people who use the vanilla version with HTMX (see issues #812, #813, #820 [mine], #821). More precisely, content that is dynamically loaded and swapped needs to be parsed by Flowbite to allow for interactivity. Calling
initFlowbite()
will cause the whole DOM tree to be reparsed which can cause weird behaviour, e.g. if the loaded content is within a modal (see issue #820).This PR intends to address these issues by making the internal initialization functions public so that they can be called on specific elements of the DOM tree. Furthermore, it adds an optional parameter to
init[ComponentName]
functions allowing for a more targeted parsing and initialization. The functioninitFlowbite
itself has been given such an optional parameter. This works by leveraging the fact that thequerySelector
can work on any node from the DOM tree.I believe that these changes will allow people using HTMX to target the elements to parsed and initialized within HTMX
onload
event without having to write their own initialization script. Given the growth of HTMX, I think this package benefits from being a little more agnostic about its initialization scenarios.I also think that documenting both the integration of Flowbite within a HTMX-driven application and the newly-added functions would be greatly beneficial to the people using this package. I would be willing to provide such documentation in a separate PR provided that you accept my contribution to the package.
Finally, regarding the Datepicker plugin, if my contribution is accepted, I will address it in a future PR. I have not included it as I wanted to address the most common issues and I wasn't certain if I needed to add to inject the methods in the
window
object. This pattern seems to have been followed for all components, but, oddly enough, not for this plug in.How to integrate it with HTMX
This is how I run it with the proposed version built and deployed in my current project.