Chapters

57 Chapters | 6:19:46 |

01

Turbo: Drive, Frames & Streams!

5:03
02

Installing Turbo

3:41
03

How Turbo Drive Works

9:37
04

Turbo-Friendly JavaScript

6:56
05

The "defer" Attribute & Conditionally Activating Turbo

4:02
06

Form 422 Status & renderForm()

9:05
07

Form Submits & The Preview Feature

7:06
08

The Problem of Snapshots & JavaScript Popups

9:46
09

Cleanup Before Snapshotting (e.g. Modals)

6:03
10

Fixing the Sweetalert Modal

7:14
11

Organizing our Turbo Events Code

3:12
12

3rd Party JavaScript Widgets

7:52
13

Fixing External JS + Analytics Code

8:46
14

Reloading When JS/CSS Changes

6:52
15

Manual Visits with Turbo

5:04
16

CSS Page Transitions

7:24
17

Polished CSS Transitions

8:58
18

Prefetching the Next Page

5:19
19

<link rel="prefetch">

7:37
20

Turbo Frames: Lazy Frames

6:32
21

Turbo Frames Look for & Load the Matching Frame

4:24
22

Using a Full HTML Page to Populate a Frame

7:24
23

Reliably Load External JS with Stimulus

9:57
24

Targeting Links in or out of the Frame

5:00
25

Adding a "Read More" Ajax Frame

8:02
26

Frame Loading Animations

7:45
27

Review this Product... in a turbo-frame!

7:50
28

Globally Disable Buttons on Form Submit

5:50
29

Frame-Powered Inline Editing

6:45
30

Frames & Form "action" Attributes

7:45
31

Frame Redirecting & Dynamic Frame Targets

6:21
32

turbo-frame inside a Modal

7:06
33

Lazy Modal & Big Cleanup

4:59
34

Close the Modal after turbo-frame Success

6:17
35

Prevent a turbo-frame from Rendering

6:34
36

Full Page Redirect from a Frame

6:05
37

Redirecting the Full Page from a Frame

5:14
38

Frame Redirecting and Clearing the Snapshot Cache

6:51
39

Manual "Restore" Visit

8:11
40

Adding a Custom Request Header Based on the Frame

7:02
41

Smart Frame Redirecting with the Server

6:29
42

Automatically Redirect Ajax Calls to /login

5:14
43

Turbo Streams

8:01
44

Streams: Reusing Templates

4:37
45

Multiple Updates in one Stream

7:00
46

Processing Streams by Hand for Fun & Profit

5:18
47

Mercure: Pushing Stream Updates Async

4:43
48

Running the Mercure Service in the symfony Binary

4:28
49

Listening & Publishing

5:42
50

Mercure Hub's JWT Authorization

6:58
51

Publishing Mercure Updates in PHP

3:47
52

Turbo Stream for Instant Review Update

8:50
53

Smartly Updating Elements for all Users

7:06
54

Visually Highlighting new Items that Pop onto the Page

5:26
55

Entity Broadcast

7:02
56

Broadcasting Frontend Changes on Entity Update/Remove

7:28
57

Toast Notifications

10:14

> JavaScript Frameworks & Tools > Symfony UX: Turbo

Buy Access to Course

12.

3rd Party JavaScript Widgets

|

Autoplay

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.

Start your All-Access Pass

Buy just this tutorial for $12.00

Previous Chapter

Next Challenge

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Login or register to check out the script

6 Comments

Sort By

Login or Register to join the conversation

Strahil-R 3 years ago

Hi @weaverryan!
any experience with integrating zopim/zendesk chat widget in a project using turbo? I have been trying different approached, but no luck so far :(

|

weaverryan SFCASTS Strahil-R 3 years ago

Hey @Strahil-R!

No, no personal experience - sorry. I assume the problem is related to re-initializing their "widget" after each Turbo navigation? Or is it something else? Assuming that this widget adds some new markup to the bottom of your page that you want to keep, you could, in theory (though I've never tried this), via JavaScript add a data-turbo-permanent attribute to some element that surrounds this widget. Then, when you navigate, Turbo will "not touch" this element.

Cheers!

|

Strahil-R weaverryan 3 years ago

Hey @weaverryan,
this is exactly the problem. I loads correctly on first page load, but fails on subsequent turbo visits. I will try out your proposal, thanks for that!
My hypotheses at the moment (after downloading the source code of the widget and trying to make sense of it) is that it does something on window.load event. And since this event is not fired on turbo visits the widget is not initialised properly.

|

weaverryan SFCASTS Strahil-R 3 years ago

Hey Strahil-R!

I will try out your proposal, thanks for that!

Let me know how it goes!

My hypotheses at the moment (after downloading the source code of the widget and trying to make sense of it) is that it does something on window.load event. And since this event is not fired on turbo visits the widget is not initialised properly.

This is an excellent theory. Unfortunately, it's still quite common for external JavaScript to only work on "real page loads". That should improve... because this also wouldn't work well with SPA's.

Cheers!

|

MaxiCom 4 years ago

I tried to come up with a solution on my own and the first one that came to my mind was to insert the widget script tag at the end at the body tag, this way it would be reloaded each time a new page is loaded,

do you consider this solution valid?

Thanks!

|

weaverryan SFCASTS MaxiCom 4 years ago

Hey @Maxime!

I would say... yes! Probably... maybe! :D

That is *likely* a valid solution. But here are a few things to think about:

A) Putting the script tag in body WILL cause the JavaScript inside of it to be re-executed on each visit. However, some external JavaScript still does not "expect" to be executed multiple times during the same true "page load". That is actually the case with the weather widget we add. Even if you put this in your body tag, without any other modifications, it is written in such a way that it only *truly* activates the weather widget one time per *true* page load... no matter how many times you execute that script.

B) There is a (probably) minor performance penalty for putting scripts in the body tag, which is why we are - in general - trying to avoid it. By putting the script in your head... and then doing something fancy to "reactivate" that widget on each visit, you are making it so that the original script only needs to be parsed once. If you put it in the body, it will be parsed and re-executed on ever visit. But for one or a few external JavaScript files, the performance penalty is probably not a big deal, but it's a nice thing to keep in mind.

Cheers!

|

Symfony 5.2 Turbo 1.2

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
    }
}

Previous Chapter

Next Challenge