Chapters
57 Chapters
|
6:19:46
|
Login to bookmark this video
-
Course Code
Subscribe to download the code!
Subscribe to download the code!
-
This Video
Subscribe to download the video!
Subscribe to download the video!
-
Subtitles
Subscribe to download the subtitles!
Subscribe to download the subtitles!
-
Course Script
Subscribe to download the script!
Subscribe to download the script!
52.
Turbo Stream for Instant Review Update
Scroll down to the script below, click on any sentence (including terminal blocks) to jump to that spot in the video!
Subscribe to jump to this part in the video!
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
What PHP libraries does this tutorial use?
// composer.json
{
"require": {
"php": ">=8.2",
"ext-ctype": "*",
"ext-iconv": "*",
"composer/package-versions-deprecated": "1.11.99.1", // 1.11.99.1
"doctrine/annotations": "^1.0", // 1.13.1
"doctrine/doctrine-bundle": "^2.2", // 2.3.2
"doctrine/orm": "^2.8", // 2.9.1
"phpdocumentor/reflection-docblock": "^5.2", // 5.2.2
"sensio/framework-extra-bundle": "^6.1", // v6.1.4
"symfony/asset": "5.3.*", // v5.3.0-RC1
"symfony/console": "5.3.*", // v5.3.0-RC1
"symfony/dotenv": "5.3.*", // v5.3.0-RC1
"symfony/flex": "^1.3.1", // v1.21.6
"symfony/form": "5.3.*", // v5.3.0-RC1
"symfony/framework-bundle": "5.3.*", // v5.3.0-RC1
"symfony/property-access": "5.3.*", // v5.3.0-RC1
"symfony/property-info": "5.3.*", // v5.3.0-RC1
"symfony/proxy-manager-bridge": "5.3.*", // v5.3.0-RC1
"symfony/runtime": "5.3.*", // v5.3.0-RC1
"symfony/security-bundle": "5.3.*", // v5.3.0-RC1
"symfony/serializer": "5.3.*", // v5.3.0-RC1
"symfony/twig-bundle": "5.3.*", // v5.3.0-RC1
"symfony/ux-chartjs": "^1.1", // v1.3.0
"symfony/ux-turbo": "^1.3", // v1.3.0
"symfony/ux-turbo-mercure": "^1.3", // v1.3.0
"symfony/validator": "5.3.*", // v5.3.0-RC1
"symfony/webpack-encore-bundle": "^1.9", // v1.11.2
"symfony/yaml": "5.3.*", // v5.3.0-RC1
"twig/extra-bundle": "^2.12|^3.0", // v3.3.1
"twig/intl-extra": "^3.2", // v3.3.0
"twig/string-extra": "^3.3", // v3.3.1
"twig/twig": "^2.12|^3.0" // v3.3.2
},
"require-dev": {
"doctrine/doctrine-fixtures-bundle": "^3.4", // 3.4.0
"symfony/debug-bundle": "^5.2", // v5.3.0-RC1
"symfony/maker-bundle": "^1.27", // v1.31.1
"symfony/monolog-bundle": "^3.0", // v3.7.0
"symfony/stopwatch": "^5.2", // v5.3.0-RC1
"symfony/var-dumper": "^5.2", // v5.3.0-RC1
"symfony/web-profiler-bundle": "^5.2", // v5.3.0-RC1
"zenstruck/foundry": "^1.10" // v1.10.0
}
}What JavaScript libraries does this tutorial use?
// package.json
{
"devDependencies": {
"@babel/preset-react": "^7.0.0", // 7.13.13
"@fortawesome/fontawesome-free": "^5.15.3", // 5.15.3
"@hotwired/turbo": "^7.0.0-beta.5", // 1.2.6
"@popperjs/core": "^2.9.1", // 2.9.2
"@symfony/stimulus-bridge": "^2.0.0", // 2.1.0
"@symfony/ux-chartjs": "file:vendor/symfony/ux-chartjs/Resources/assets", // 1.1.0
"@symfony/ux-turbo": "file:vendor/symfony/ux-turbo/Resources/assets", // 0.1.0
"@symfony/ux-turbo-mercure": "file:vendor/symfony/ux-turbo-mercure/Resources/assets", // 0.1.0
"@symfony/webpack-encore": "^1.0.0", // 1.3.0
"bootstrap": "^5.0.0-beta2", // 5.0.1
"chart.js": "^2.9.4",
"core-js": "^3.0.0", // 3.13.0
"jquery": "^3.6.0", // 3.6.0
"react": "^17.0.1", // 17.0.2
"react-dom": "^17.0.1", // 17.0.2
"regenerator-runtime": "^0.13.2", // 0.13.7
"stimulus": "^2.0.0", // 2.0.0
"stimulus-autocomplete": "https://github.com/weaverryan/stimulus-autocomplete#toggle-event-always-dist", // 2.0.0
"stimulus-use": "^0.24.0-1", // 0.24.0-2
"sweetalert2": "^11.0.8", // 11.0.12
"webpack-bundle-analyzer": "^4.4.0", // 4.4.2
"webpack-notifier": "^1.6.0" // 1.13.0
}
}
6 Comments
What is better solution taking into account server load (Mercure Hub)? Users subscribe for one topic "product reviews" so that Mercure Pushes information to all of them and Turbo, based on frame ID, decides if do something with it or not - like shown in tutorial. Or the better solution is to have unique topic for each product?
Hey Tomasz-I!
That's an excellent question! But... I don't have a good answer for you. My instinct tells me that having a unique topic for each product would be more efficient... and it almost definitely is. However, I don't know if it makes any practical difference. Regardless of how you name your topics, you will still have the same number of "connections" to Mercure. And, for example, if you look at the hosted Mercure service - https://mercure.rocks/pricing - when you consider pricing, the only 2 factors are "number of concurrent connections" and "number of POST requests per minutes" (so, updates). I'm doing some guessing, but based on this, it seems that the "number of concurrent connections" is the most important thing for performance. And "how many subscribers an update needs to be pushed to" may not be such an important thing.
Again, this is mostly guess work - we don't (yet) have Mercure on production (though I'm guessing we will have it at some point in the next few months).
Cheers!
Exactly. I asked this cause we have a sort of dilemma regarding the way we should handle some things. We use Mercure and Symfony for our Event app and website (mobile app and website for Conference organizers and attendees). For now we use this for Chat but there are multiple cases we are thinking about to use Mercure for communication. For instance - one general topic (not for any private conversation but for general stuff) to push information about new notifications, new surveys, new configuration (new menu item) etc. Now we are sure we will add Turbo for the web part and the idea of pushing new information and configuration to the website client is a great topic to consider. Thank you!
What it doesn't save in server resources it does save in server bandwidth.
In the example given here each page will only get the network traffic for the review in question, not the network traffic for all reviews.
Maybe that's tiny, maybe it's not -- imagine if amazon pinged out every review update for all the site to every single user currently connected ;-)
I'd used
<div {{ turbo_stream_listen('product-'~ product.id ~'-reviews') }}></div>and$mercureHub->publish(new Update('product-'.$product->getId().'-reviews', ...);instead of changing the DIV name for such a usecase.(Urg, Disqus eats twig templates inline - sorry about that)
Hey Xalior,
Thank you for this tip! I also tweaked your comment and wrapped the code with "pre" & "code" tags, it should be good with this I suppose.
Cheers!
Hey Tomasz-I!
Yes, this is a great use-case for all of this cool stuff :). The only item I could find specifically about Mercure performance is this issue - https://github.com/dunglas/... - which is not exactly what you were talking about, but somewhat similar. You can see that even dunglas says that he's not sure.
> For instance - one general topic (not for any private conversation but for general stuff) to push information about new notifications, new surveys, new configuration (new menu item) etc
My first thing to try would also be a "general topic" for this. You at least then know that every user has just "one" Mercure connection (not counting private chats) and not multiple at the same time (e.g. one for notifications, one for surveys, one for new config, etc).
Anyways, let me know how it goes!
Cheers!
"Houston: no signs of life"
Start the conversation!