Bonus: More on Flowbite

Hey @Octavio-B ,

Hm, it might be just a network issue or a temporary outage from jsDelivr. Or if you use a VPN or have some firewall set up - it may cause issues too. Could you try again after some time? Also, when you it this problem - try to load that URL directly in your browser, do you see a JSON output or is it not loaded as well?

Cheers!

Hello Victor,

Thank you for your quick response. You are right, it is a network issue; because when I try to load the URL directly in my browser, I don't get to see any JSON. I think it has to do with the firewall in my office. Is there another way to make this work?

Hey @Octavio-B ,

Hm, other than tweaking the firewall to allow it? Not sure, probably using a VPN may help, depends on the firewall setup, I think. Or use another CDN for this, probably the issue is only with this jsDelivr.

Cheers!

Hey @Diarill!

Where did you get the event autocomplete:open from? I don't believe that exists. I don't think UX autocomplete dispatches any event on open. However, the underlying autocomplete library "TomSelect" does dispatch some events: https://tom-select.js.org/docs/events/

The implementation would look something like this (referencing https://symfony.com/bundles/ux-autocomplete/current/index.html#extending-tom-select)

import { Controller } from '@hotwired/stimulus';

export default class extends Controller {
    initialize() {
        this._onPreConnect = this._onPreConnect.bind(this);
        this._onConnect = this._onConnect.bind(this);
    }

    connect() {
        this.element.addEventListener('autocomplete:connect', this._onConnect);
    }

    disconnect() {
        this.element.removeEventListener('autocomplete:connect', this._onConnect);
    }

    _onConnect(event) {
        console.log(event.detail.tomSelect); // TomSelect instance
        event.detail.tomSelect.on('dropdown_open', () => {
             console.log('opened!');
        });
    }
}

Let me know if this helps!

Hey @apphancer!

Hmm, I hadn't tried this yet, but it does make sense. Usually, when you have a "widget" like this, when you select a date it does, of course, update the underlying input with the value. But it almost always does it in a way that does not trigger the change event (iirc you need to do MORE work to have that happen). So you've diagnosed this perfectly.

You can find the fix & info here - https://symfony.com/bundles/ux-live-component/current/index.html#model-updates-don-t-work-when-external-javascript-changes-a-field which really points down to here - https://symfony.com/bundles/ux-live-component/current/index.html#javascript-manual-element-change

Let me know if that helps!

Cheers!

Thanks, Ryan, for pointing me in the right direction. That was very helpful!

I think I've managed to get to the bottom of it, and.... it looks like the issue is more serious than I first imagined, and.... the datepicker in Space Inviters is affected by the same issue.

Not only the changes to this field are not submitted for validation, but if you select a date for a Voyage (i.e. a different date than the default one), then change anything in the other fields, the autovalidation triggered on the other fields resets the value selected in the date field.

Here's how I changed the code inside the connect method of the datepicker_controller:

   let input = this.element; // needed as the 'this.' cannot be accessed inside the event listener  

    input.type = 'text';
    this.datepicker = new Datepicker(input, {
        format: 'yyyy-mm-dd',
        autohide: true,
        container: document.querySelector('dialog[open]') ? 'dialog[open]' : 'body'
    });
    
    input.addEventListener('changeDate', function(e) {
        input.dispatchEvent(new Event('change', { bubbles: true }));
    });

Hey @apphancer!

Nice work! Sorry for the VERY slow reply. This is exactly the reason why we need to share Stimulus controllers as a community, so we can get little details like this correct. That's something we're working on right now for ux.symfony.com.

Cheers!

Ryan,

I may be having the same issue. I'm using LiveComponents to search through items with a Live Search, and I'm using Tailwind CSS Number Input by Flowbite, which requires Flowbite.js. The number input works, but if I search and the LiveComponent renders with the Items matched in the search, the number input still works, but if I clear the search, the number input no longer works.

I checked this:
https://symfony.com/bundles/ux-live-component/current/index.html#javascript-manual-element-change

So I've created a Stimulus controller:

import { Controller } from '@hotwired/stimulus';
import { getComponent } from '@symfony/ux-live-component';
import { initFlowbite } from 'flowbite';

export default class extends Controller {
    async initialize() {
        this.component = await getComponent(this.element);

        this.component.on('render:finished', (component) => {
            initFlowbite();
        });
    }
}

And then I've added this to my component:

<div {{ attributes.defaults(stimulus_controller('render')) }}>

Is there something I'm missing?

Hey @Brandon!

Flowbite is great and a pain :).

Can you verify if:

• the initialize method of your controller is being called?
• Is your render:finished callback being executed?

I'm not sure where the problem is, but that's where I would start looking. I bet other people would be interested in the solution if we can find it.

Cheers!

Ryan,

Thank you for the response. This what I've come up with

Initial page load, before any search takes place, in my console I get:

application #starting
render #initialize
render #connect
live #initialize
live #connect
application #start

I run a search which I know will return 1 result and I added a console.log('Render Finished?'); after initFlowbite();, and in my console for whatever reason it comes up three times.

Render Finished?
Render Finished?
Render Finished?

If I clear the search and return everything, it says 'Render Finished' once more and my number field works on the first 'item', but not on the other four, unless I do a full page refresh, and it works the same all over again. I don't know a lot about JavaScript, but if you suggest more to test I can do it to figure this out. I can say that there is an event on the first number input that works, but not on any of the others.

What I did to get around this is like you have suggested in the past, make a small Stimulus controller to handle the increment and decrement of the input, basically taking the place of Flowbite. It would be nice for Flowbite to work out of the box, but if I'm making a Stimulus controller to help re-render Flowbite, I might as well use the controller to work right out the box with LiveComponents and increment and decrement my quantity.

Thank you for all your help, I wish you the best

Hey @Brandon!

What I did to get around this is like you have suggested in the past, make a small Stimulus controller to handle the increment and decrement of the input, basically taking the place of Flowbite. It would be nice for Flowbite to work out of the box, but if I'm making a Stimulus controller to help re-render Flowbite, I might as well use the controller to work right out the box with LiveComponents and increment and decrement my quantity.

Nice job! And this really summarizes my feelings about the Flowbite JavaScript: it's super enticing, but the implementation is not what I want. The initialization code is really hardwired to depend on full page refreshes and definitely doesn't play well with the DOM mutation that LiveComponents uses (and that more and more things use, like Turbo 8 morphing). Ideally, as morphing becomes more common, libraries like Flowbite will work better with them. But until that fancy future, Flowbite offers these wonderful things that are beautiful and instant... until they stop working. Then you've gotta debug and it may or may not feel worth it in the end, which is a shame.

So good work, and I wish I had a magical solution, because I also want to use Flowbite more often :)

Cheers!

Hey @Shay-H

Thanks for you kind words, we're here to help :)

Cheers!

Hey @jdevine!

But if someone following the lesson uses light mode in their browser, wouldn't the issue still remain?

Yes - I get your point. I guess there are two ways of thinking about it:

1) I was imagining that, in a real app, you would be less lazy than I was and actually code the templates to properly support light mode. If you did that, then the auto-detection is perfectly great.

2) But, if we are determined to have this be a space-themed dark site only, then totally: we should use the class and set class="dark" like you suggested :).

Also, it's cool that you can opt to just use the flowbite-datepicker js and not the rest since that would be the one flowbite component with interactivity that would be the most painful to rebuild from scratch.

Ah! I'm really glad you thought so! I had the same thinking: all of the other JS (tabs, dropdowns, even the modal) seem relatively simple. A rich date picker on the other hand... yea, that's much bigger.

Cheers!