Toast Notifications

Hey Aries,

Basically, the same package :) The package was renamed, IIRC to include the company name because they provide more than one package and it's easier to distinguish packages related to them, that's it :)

Cheers!

Cool beans. Thanks.

Hey Nick!

First, I'm not an expert on this. So, I'll tell you what I know, but it's not coming from a place of real-world experience with many subscribers/updates like this.

From the Mercure side of things, the managed pricing page can kind of give you some clues: https://mercure.rocks/pricing. In general, I think the answer is that you'll run into bottlenecks performing too many updates first before you'll run into bottlenecks on Mercure.

For example, on the Hobby plan, you get 250 concurrent connections and 30 POST request / minute. So, with your example, if we have 100 users and each is subscribed to the same ONE topic, then that's 100 concurrent users, still well below the limit. And, you only need to publish ONE update.

If each user is subscribed to a different topic, then that's still 100 concurrent users. In theory, you (I believe) update all 100 topics with ONE update (because you can pass multiple topics to an Update) if all of those updates are identical. I have no idea if there is some upper limit on the number of topics you can pass. Or, if each Update needs to be a bit different (for each topic), then you'd need 100 updates, and that WOULD be a problem (since the limit at this level is 30 / minute).

So, in general, your bottleneck is probably more about how many updates you post vs concurrent users. Or, to say it differently, I would tend to design things so that I need only one / a few updates. Then, I would scale my Mercure instance based on how many concurrent users I need.

Let me know if this helps - it CAN be tricky to get right. Another thing to consider (based on your situation) is that you COULD send 100 updates to Mercure without slowing down your app by using Messenger to send these. The downside would just be that those updates might not be as instant, as it might take some time for your worker to process through them.

Cheers!

Hey @SamuelVicent!

Nice to chat with you - I'll do my best to brainstorm :).

Is there any way to load a static content?

I'm not sure I fully understand this still. For the link that loads content from the server, that is just a normal link, right? You shouldn't need to do anything (write any custom JavaScript) - you can just allow the link to be a normal link and then, on click, Turbo will follow it. I feel I'm missing some important detail here (because that answer is too simple) - so please let me know :).

and another just show a pre-loaded content that was previously hidden

Turbo won't help you here - this is more of a simple "hide/show this element" situation. In my app, if I were doing this with any frequency, I'd create a general-purpose Stimulus controller for this - the end Twig would look something like:

<div {{ stimulus_controller('toggle-content')>
    <button {{ stimulus_action('toggle-content', 'show') }}>Show</button>
    <div style="display: none;" {{ stimulus_target('toggle-content', 'content') }}>
        I am hidden content
    </div>
</div>

When the button is clicked, the show() method in the Stimulus controller looks for the content target and unhides it.

Again, I feel like I may not be fully grasping your situation (and so I might be answering the wrong question!) so let me know :).

Is there any way to load dynamic content only once?

What do you mean? Are you referring what happens when you click a normal link and Turbo loads the next "page"? Are you working with Turbo frames? Something else?

Let me know some of these extra details and I'll see if I can help further :).

Cheers!

Hi Ryan,

• First point understood! thanks a lot. We understand that is not turbo responsability hiding and showing divs :)

• Second point, sorry for my description, let me explain a bit better. Using turbo, imagine a page with two links, a user first clicks on LinkA, then on LinkB, and then on LinkA again. The question is: Is there any way to keep the Snapshop previously created when user clicked LinkA for the second time? The objective of this approach is not reloading the same content twice. This behaviour could happen inside a turbo-frame as well.

Thanks a lot!

Hey @SamuelVicent!

Ok, I think I understand then! Here is the flow:

1) User clicks Link A. The URL for LinkA is downloaded then shown
2) User clicks Link B. The URL for LinkB is downloaded then shown.
3) User clicks Link A again. The original, cached version of Link A is shown immediately. But the URL for LinkA IS downloaded again, and then shown to the user when it finishes.

If I understand correctly, you'd like to remove this part:

But the URL for LinkA IS downloaded again, and then shown to the user when it finishes.

And thus just show the original, cached version of Link A and do nothing else. Is that correct?

If so... I'm not sure! :). I am not aware of a built-in way to do this (i.e. I am not aware of any data-turbo="restore" type of attribute you could add somewhere to opt into this). To do this, I would try to "cancel" the visit - https://turbo.hotwired.dev/handbook/drive#canceling-visits-before-they-start - but I don't know if this would work. It would only work if canceling would cancel the request but Turbo still shows the page from cache. I just don't know exactly how Turbo will behave. Also, you would need to somehow figure out whether or not the page is already in the cache or not. That info may be present on event.detail (?) or by checking of the current html element has a data-turbo-preview attribute on it (assuming that the preview is shown BEFORE your event listener is called).

So, that's one idea... which may or may not work - I'm not sure :). But I'd be curious to hear if it did!

Cheers!

Hi Ryan,

We made some tests and finally could cancel a second hit to server.
Here you are a minimal code in javascript:

const urls = new Set();
document.addEventListener('turbo:before-fetch-request', (event) => {
    const url = event.detail.url.href;
    if (urls.has(url)) {
        event.preventDefault();
    } else {
        urls.add(url);
    }
});

Would have been great having a buit-in for this behaviour (something like you mention like data-turbo="restore"), but this suits our needs :)

Thanks a lot for your help!!!

Hey @SamuelVicent!

Ah, I love this solution and approach - very clever :). Thanks for sharing it.

Cheers!

Hey @Growiel!

> There is one point that I was looking forward that sadly was not covered by the tutorial: private streams and/or different broadcasts

Yea... I didn't want to get into the weeds with this, since this tutorial isn't strictly about Mercure. But it's definitely a missing piece.

> 1) I have a "buyer" and a "seller" Entity, when one buys from the other, they both get a toast message, but with a different message. One would > say "You just bought for 15EUR" and the other one "You just sold for 10EUR".
> So I need a way to broadcast changes depending on the logged in user. Is there any ways to do that ?

Say the "buyer" has a user id of "10" in the database and the seller has a user id of "20". You could have the buyer listen to user_10 and the seller listen to user_20. Then, when the transaction is complete, you would post 2 updates: one to user_10 (with the "You just bought" message) and one to user_20 (with the "You just sold" message). There are other slightly variations on how to accomplish this, but I think this is the general idea :).

For both this situation (and the next one described below), you would need to make sure that only the authorized user can listen to their channel (e.g. we need to prevent the seller from being able to listen to the buyer's channel).

> 2) A Facebook-like notification system, where you get notified only on things that concerns you.

I would have each user listen to a user_ID channel, very similar to what I described above. The only downside is that this can cause you to have a lot of "listeners" to Mercure, which could cause you to need more Mercure resources (each user would always be listening to at least 1 channel).

> 3) In the tutorial we did "When a review is updated on the admin site, update the frontend", using Broadcasts. What about doing the opposite ? If the review is changed on the frontend OR by another admin, i'd like my view updated too.

That's a cool idea! The Broadcast feature would work nicely with this: we could some additional stream elements to the template that target elements that are only found in the admin section. Then, we just need to make sure that, in the admin section, we are also listening to that entity's channel.

That's the simplest solution: make the broadcast template update ALL possible elements, both on the frontend and backend. The downside is that a clever user could look into the stream and see the HTML from your admin area. Depending on the situation, that could definitely be a problem :). If it is, then you will, one way or another, need to dispatch two updates whenever you change a review: one for the frontend and one for the admin area (each update would be publishing to a different channel).

Let me know if that helps :). It's a bit of a challenge sometimes to figure out the best arrangement of "channels" to optimize "number of listeners" and "number of updates" and "privacy".

Cheers!

Thanks a lot for answering, somehow I did not a notification from Disqus.

As you can see all of my use cases rely upon one thing: privacy. We don't want someone seeing something he shouldn't by using his devtools to look at he stream(s).

I already thought of the "one user = one stream" technique, and it's the one I'm using at the moment, just wanted to pick your brain on if there's something more elegant because it does have some limitations.

For the last use case, we'd have to go with custom updates right ? Broadcasts would only allow us to broadcast either the front template or the admin one (unless we're okay with the security issues).

Hey @Growiel!

> Thanks a lot for answering, somehow I did not a notification from Disqus

That's ok! I'm glad you saw the reply :)

> just wanted to pick your brain on if there's something more elegant because it does have some limitations.

If there is a more elegant solution, I would also like to know it. So, there may be one, but not that I'm aware of.

> For the last use case, we'd have to go with custom updates right ? Broadcasts would only allow us to broadcast either the front template or the admin one (unless we're okay with the security issues).

Exactly. If you used the Broadcast, then the broadcast template would need to include both the frontend and backend HTML... which maybe you're ok with, or maybe not :). So probably you would need to make the Broadcast update just the frontend templates and dispatch a second, custom Update for an admin-only Mercure channel.

Cheers!

Hey Nick!

Thank you for your feedback! We're happy to hear you love this, and that's why we do want our users to code along with the course author - it definitely worth it, the material is learned much better than when you just watch videos without coding.

Cheers!