Fancier Toasts: Auto-close & Fading

Hey @Francesco!

This is a fair observation. I think it's better than it was several years ago. Modern JS has many of the features we used to use libraries for.

As for trusting the packages. There is the audit command to look for security vulnerabilities. I think your talking about supply chain attacks though. Indeed, this is a managed risk with every package manager, including composer.

npm has the concept of signed packages you could look into. I believe there's been some discussion about this idea being added to composer too.

--Kevin

Hey @lid

An option would be to pass a Twig variable from the controller and generate the CSS class dynamically {{ 'duration-['~time~'ms]' }}

Cheers!

Thanks for your suggestion. Unfortunately, I would prefer a solution where configuration needs to be done at one position only. The notification is a component, a small one - at the client-side.

I managed to get it working this way:

In closeable_controller.js

if (this.hasTimerbarTarget) {
    setTimeout(() => {
        this.timerbarTarget.style.transitionDuration = `${this.autoCloseValue}ms`;
        this.timerbarTarget.style.width = 0;
    }, 10);
}

Does something speak against it?

Thank you very much!

It requires a bit more JS code but if you plan to re-use that controller in many places I think it's a better approach than mine

Cheers!

Hey @labfordev

Can you tell me why it would trigger a double-page refresh? I think that's more related to how your frontend and backend communicate with each other.

Actually, I'm using Vite.js to manage my assets, and it behaves and functions quite similarly to Webpack Encore. I have an asset configuration for the backend and an asset configuration for the frontend. Each with its own stimulus controllers, etc...

On the import of the JS entry file into my HTML, I added, for both the back and front parts, a data-turbo-track="reload" attribute so that the browser reloads the page when I switch from the backend to the frontend and vice versa.

When I launch a flash message from the backend, for example, or even more concretely from an event listener at the moment of user logout, it's impossible to display this flash message on the frontend (landing page following the logout).

It seems like turbo makes an ajax call to the frontend, and since it sees the data-turbo-track attribute, it reloads the page completely. Consequently, the flash message seems to have already been consumed in the meantime.

I'm not sure if this is very clear... Sorry for my very Frenchy English ^^
I think it closely resembles these issues:

• https://github.com/hotwired/turbo/issues/114
• https://github.com/hotwired/turbo/issues/897

Hey @labfordev!

Yes, I understand! Interesting - and that first issue, indeed, seems to be exactly what you're talking about! That's tricky. Honestly, I can't think of a great workaround :/. From our Symfony app, we have no idea that the first page request is about to be ignored and then a 2nd will follow... so we can't add any intelligence that would say "please don't remove the flash messages yet". The only ideas I have are:

A) Disable Turbo on forms submits where you might know this will happen. This, I admit, is not a super great solution.
B) In theory (?), you could check the Referer. And if the current request is for the frontend, and the Referer was for the backend, you could add some special code to "keep" the flashes in the container for an extra request. This... seems like it would work... but it also feels like there could be cases I'm not thinking about. To "keep" the flash messages for an extra request, you could... possibly create a custom Twig function - is_switching_areas() - that detects this situation. Then use peek on the flashbag instead of get().

Sorry I can't be more helpful, but I am interested how you solve this :).

Cheers!

Hey @weaverryan!

Thank you for your great response! Indeed, it's quite a unique "problem" :p.
I'll try to look into it when I have a bit more time, following what you just said.

I'll get back to you if I find a solution.

Cheers!

Yea... those issues seem related to your problem. I don't know what's causing it. I'll see if Ryan can help us out

Thank you very much :)

Thanks for the mention @Rudi-T! All fixed now

Hey @Chris-56789 ,

Good question! That's a GitHub Copilot PhpStorm's plugin: https://github.com/features/copilot - a kind of AI autocompletion.

Cheers!

Thanks

Hey @tonysm!

Nice! I'd add a data-turbo-temporary attribute to the notification message itself so it's not added to the page cache if the user leaves the page before the notification is closed/removed (it would cause a weird behavior if they get back to the page again and the notification is in the page cache, they'd see it for a short moment as the live page version is being fetched and replaces the cached version).

Absolutely! I do this too. I forgot to do it in the video, but added it later... and meant to add a note to this chapter, you just reminded me to add! :).

To avoid losing the notification when a user leaves the page, you could make the notifications wrapper element data-turbo-permanent and give it an ID, but unfortunately, this has a weird side-effect of not adding new notifications to the wrapper element if you're doing that with regular flash+redirects (since the permanent elements won't be touched)... maybe that's also fixed with Turbo Streams?

Hmm, interesting! Indeed, streams would fix this. I've never done it before, but instead of actually rendering the streams inside of the <div id="flash-container">, you could render them right below/above this as a stream:

<div id="flash-container" data-turbo-permanent></div>

{% if app.session.flashBag.peek('success')|length > 0 %}
    <turbo-stream action="append" target="flash-container">
        <template>{{ include('_flashes.html.twig') }}</template>
    </turbo-stream>
{% endif %}

This should work. It looks a bit odd - instead of physically rendering into flash-container... you render an element that says "render this into flash-container", but it should work. I'd love to know how it works in practice!

Cheers!