Open greysdawn opened 2 weeks ago
Thinking about it, I'm not entirely sure why the line I referenced above is written the way it is. The only time the backdropDivClass
is used is when the backdrop is explicitly desired. I'm assuming this might be a holdover from a previous version where the backdrop was used as the outside click wrapper every time, but that doesn't seem to be the case anymore. Would it be safe to get rid of the extra class checks?
This should work fine and be safe to use from what I can tell:
// current
let backdropDivClass = twMerge("fixed top-0 start-0 z-50 w-full h-full", backdrop && bgColor, backdrop && bgOpacity);
// proposal
let backdropDivClass = twMerge("fixed top-0 start-0 z-50 w-full h-full", bgColor, bgOpacity);
Describe the bug
(Sorry for the long title haha)
As the title says: when creating a drawer component with
backdrop
initially set tofalse
, but later set totrue
through bindings, the backdrop will never display even whentrue
. I suspect this is due to the way that the backdrop classes are initialized, as that only checks forbackdrop
to betrue
during the initialization of the component (see: this line)Doing this the other way around works (ie. initializing to
true
and later changing tofalse
), but can create unintended behaviors. An example of that can be seen with an app that keeps the drawer open on larger screens, where refreshing the page will cause the backdrop to show before being set tofalse
and becoming hiddenReproduction
Repl: https://replit.com/@GreyHimmel/Drawer-Backdrop-Bug?v=1
This doesn't display the other backdrop issue I mentioned above (with drawers that are always open), but it does showcase the different behaviors between the two initialization values. Should work out of the box and has buttons to activate each type of drawer and toggle their backdrop props
Flowbite version and System Info