-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathchallenges.yml
1906 lines (1691 loc) · 69.5 KB
/
challenges.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
how_drive_works:
question: |
How is Turbo activated when using the `symfony/ux-turbo` package?
explanation: |
Symfony adds a dummy stimulus controller to its controller list. This controller simply
imports `@hotwired/turbo` (which activates Turbo Drive!) and exposes `Turbo` as a global
variable. Fun fact: since beta 6, when you import `@hotwired/turbo`, that automatically
exposes `Turbo` as a global variable (so, the dummy controller doesn't really need to do
it anymore).
features:
multiple_choice:
choices:
a: |
When you install `symfony/ux-turbo`, it adds a dummy stimulus controller to
`controllers.json` file that imports `@hotwired/turbo`.
b: |
Turbo is automatically added to your codebase when you use webpack encore
and have `@hotwired/turbo` installed via `packacke.json`.
c: |
It doesn't work out of the box. You need to import Turbo on all of your files or in
`assets/bootstrap.js`. This way, you can selectively choose which parts of your website
use Turbo and which don't.
correct: a
how_drive_works_2:
question: |
Once you install `symfony/ux-turbo`, it automatically starts working throughout your
website. But, how exactly does it work and what does it do?
explanation: |
Turbo Drive intercepts actions like clicks and form submits and loads them with an Ajax call.
It will then save snapshots of these pages so that when you click the back or forward buttons
in your browser, the pages will load instantly. If a page takes a long time to load, it will
even show a progress bar on top of the page that you can customize!
features:
multiple_choice:
choices:
a: |
It downloads and installs a browser extension that processes all requests in the
background before clearing the page.
b: |
It loads JavaScript that intercepts events like clicks and form submits and
makes an Ajax request to load them in the background.
c: |
It works in the backend by leveraging web sockets, which make all pages load
faster.
correct: b
how_drive_works_3:
question: |
When Turbo Drive loads a new page, what exactly happens behind the scenes?
explanation: |
Turbo will merge the tags present in the `<head>` tag in a smart way.
It will remove anything in `<head>` other than JavaScripts and CSS tags. After removing
all non-JS and non-CSS tags from the old page, it will then inject anything that is left,
such as the `title` element and meta data elements from the old page to the new.
Lastly, it will add those `<script>` and `<css>` tags that aren't present in the current page.
features:
multiple_choice:
choices:
a: |
Turbo replaces the old page with the new page loaded through
Ajax and executes all `<script>` tags again.
b: |
Turbo merges all scripts, meta-data and even the `<title>` element present in
the `<head>` tag, then replaces the `<body>` with new content.
c: |
Turbo replaces the `<body>` with the new content but leaves the `<head>` tag intact,
except for the `<title>` element, which is replaced with the new title.
d: |
Turbo merges the new `<head>` tag by adding new `<script>` and `<link>` tags but replacing any
other tags with those from the new page. It then replaces the `<body>`.
correct: d
javascript:
question: |
What is the biggest way in which JavaScript works differently on Turbo-enabled websites?
explanation: |
As Turbo only loads JavaScript files once (and executes them once) per "session" (i.e. full page refresh), you
need to make sure any initialization code that needs to run on every "page load" is executed
properly! New scripts that are *added* to the `head`, however, do get parsed!
> If you put JavaScript into the `body` of a page, it will execute normally on every
> page load!
features:
multiple_choice:
choices:
a: |
There are no significant differences between a normal website and a Turbo Drive powered
site. That's what makes Turbo so great: you can use it on any site without major changes.
b: |
The difference is that, when Turbo Drive loads a new page, every JavaScript script
is parsed and executed again to ensure that the new page has been reinitialized
properly. This includes old scripts that don't get removed!
c: |
The difference is that, when Turbo Drive loads a new page, `<script>` tags that were
present in the previous page, don't get parsed and executed again, as you might
expect with a normal page load.
d: |
The difference is that, when Turbo Drive loads a new page, new script tags found in the `<body>` tag are
parsed but not executed. You need to move these to the `<head>` tag for them to be parsed.
correct: c
javascript_2:
question: |
What is one reason why it is not recommended to have JavaScript inside the `body` tag on a Turbo Drive
powered website?
explanation: |
When Turbo Drive switches to a page that was previously visited, its cache feature,
which makes the page appear instantly, will cause any JavaScript in the `<body>` to be
executed. When the actual page finishes loading, turbo will replace the cached page
with the new one, causing another execution of its JavaScript, thus potentially causing
issues.
Also, executing the same JavaScript code on every page is wasteful! When you put JavaScript
in the `<head>` tag, it's only parsed and executed *one* time, which means there is less
work to do each time Turbo Drive navigates to a new page.
The best way to use JavaScript in a Turbo Drive powered website is Stimulus!
features:
multiple_choice:
choices:
a: |
Having JavaScript in the `body` tag is not a recommended practice and thus,
should be avoided.
b: |
Because the Turbo cache can cause this JavaScript to be executed twice on a page
load, leading to potential issues.
c: |
There are no problems with having JavaScript in your `body` tag, although it is
not a recommended practice!
d: |
Because the JavaScript included in a `body` tag will *not* be executed by Turbo Drive
when the page loads!
correct: b
disabling:
question: |
Given this very basic template:
```twig
<html>
<head>
<title>My Template</title>
{% block javascripts %}{% endblock %}
{% block stylesheets %}{% endblock %}
</head>
<body>
{% block body %}{% endblock %}
</body>
</html>
```
How can we disable turbo on this page?
explanation: |
If you set the property `data-turbo="false"` in a `<body>` tag, it will effectively disable
Turbo for that entire page!
> You can also disable or enable (with `data-turbo="true") specific links within a page
> or entire page sections!
features:
multiple_choice:
choices:
a: |
```html
<html data-turbo="false">
<head>
<title>My Template</title>
{% block javascripts %}{% endblock %}
{% block stylesheets %}{% endblock %}
</head>
<body>
{% block body %}{% endblock %}
</body>
</html>
```
b: |
```diff
<html>
<head>
<title>My Template</title>
<meta data-turbo="false">
{% block javascripts %}{% endblock %}
{% block stylesheets %}{% endblock %}
</head>
<body>
{% block body %}{% endblock %}
</body>
</html>
```
c: |
```diff
<html>
<head>
<title>My Template</title>
{% block javascripts %}{% endblock %}
{% block stylesheets %}{% endblock %}
</head>
<body data-turbo="false">
{% block body %}{% endblock %}
</body>
</html>
```
d: |
Once you install and set up turbo (i.e. include Turbo in your main
JavaScript entry), you cannot disable it, except on a link-by-link basis.
correct: c
forms:
question: |
In this video, we fixed our forms by making them respond with a 422 status code
when they fail. Which of the following explains why we do this?
explanation: |
A 422 status when a form has errors is a better way of handling a form failure. It
also tells Turbo that there has been an error and needs to re-render the page.
Previously, when we returned a 200 status code, it made Turbo think that our form
did submit successfully. But, when a form submits successfully, we should redirect.
This... confused Turbo, which thought that our form did submit successfully...
but then we did not redirect.
features:
multiple_choice:
choices:
a: |
We do this to avoid an error by Turbo where it says that "form submits should
redirect to another location".
b: |
We do this to better conform to HTTP standards, since our code was incomplete
in this regard.
c: |
We do this to show a nice new feature of Symfony regarding forms, where it can
handle different status codes on different situations.
d: |
All of the above.
correct: d
preview:
question: |
Hey! I've prepared this template for a shiny new Pong page!
```twig
{% extends 'base.html.twig' %}
{% block title%}Play Pong in the Browser for Free!{% endblock %}
{% block metas %}{% endblock %}
{% block body %}
<div id="pong_game_app"></div>
{% endblock %}
```
But now... I want to avoid showing a "preview" if the user navigates back to this page.
I've added a `block metas` so that I an add the proper tag to the `<head>` element to avoid
the preview... but I can't seem to remember exactly how this is!
What is the actual `meta` tag that we need to add to stop turbo previews?
explanation: |
You can also set this meta to contain the value `no-cache` which means that it won't generate
any snapshot cache at all (not even for the back button!)
Other metas that we can leverage with turbo are:
```html
<meta name="turbo-visit-control" content="reload">
```
This enforces a full page reload every time turbo visits this page. Check the Turbo Drive reference
for more information on these!
features:
multiple_choice:
choices:
a: |
```html
<meta name="turbo-cache" content="no-preview">
```
b: |
```html
<meta name="cache-control" content="no-preview">
```
c: |
```html
<meta name="turbo-cache-control" content="no-preview">
```
d: |
```html
<meta name="cache" content="no-preview">
```
correct: c
modal_preview:
question: |
What happens when Turbo creates a preview of a page?
explanation: |
This is important because you need to make sure your page functionality is preserved
between page views.
In general, the best way to add JavaScript functionality with Turbo Drive is its best
friend: Stimulus! But there *are* workarounds we can do to keep our existing JavaScript
working.
features:
multiple_choice:
choices:
a: |
At the moment right before leaving the page, Turbo clones the DOM using `cloneNode`,
which does *not* include event listeners added from JavaScript.
b: |
At page load, Turbo clones the DOM using a "deep clone" algorithm, but
since JavaScript hasn't executed yet, no listeners are included in the preview.
c: |
At the moment right before leaving the page, Turbo clones the DOM using a "deep
clone" algorithm, but removes any event listeners added by JavaScript because
it relies on Stimulus to add them back.
d: |
At page load, and after all JavaScript has been parsed and executed, Turbo clones
the DOM using a "deep clone" algorithm. It then removes any event listeners added by
JavaScript because it relies on Stimulus to add them back.
correct: a
modal_preview_2:
question: |
In my web page, I decided to create my own modal. It's just a `<div>` element
that I set to `display: block` whenever I want to show it. Not a big deal!
```html
<div id="my_great_modal" style="display: none">
<h1>Welcome to our Pizza Section!</h1>
<p>You need to be a pizza lover before you proceed!</p>
<button
class="btn btn-primary"
onclick="javascript:document.getElementById('my_great_modal').style.display='none';"
>
Proceed
</button>
</div>
```
I then use JavaScript to discretely show this popup under certain circumstances (i.e. when
I detect that a customer might not love pizza!).
But, when the user leaves the page when the modal is opened and then hits the browser's
back button, Turbo is showing this modal for a brief period of time while the preview is
showing. I don't want that!
How can I hide this modal every time Turbo shows my page preview?
explanation: |
Leveraging the turbo event `turbo:before-cache` is the best solution for things like
these, because you can clean up and prepare your snapshot before turbo takes it so that
you ensure that you will always see the right state!
Other events, like `turbo:load` might look useful, but they will
only fire after the page has finished loading, which means that the preview event
already took place!
features:
multiple_choice:
choices:
a: |
```javascript
document.addEventListener('turbo:before-visit', (event) => {
document.getElementById('my_great_modal').display = 'none';
});
```
b: |
```javascript
document.addEventListener('turbo:before-cache', (event) => {
document.getElementById('my_great_modal').display = 'none';
});
```
c: |
```javascript
document.addEventListener('turbo:before-fetch-request', (event) => {
document.getElementById('my_great_modal').display = 'none';
});
```
d: |
```javascript
document.addEventListener('turbo:load', (event) => {
document.getElementById('my_great_modal').display = 'none';
});
```
correct: b
cleaned_preview:
question: |
In our video, we show how closing a bootstrap dialog before exiting a page,
so that we can have a cleaned preview, doesn't quite work. When we came
back to the page, we saw a greyed invalidation div covering it!
Fixing this required some more hacking to get it working properly.
Why did we get this weird behavior?
explanation: |
The `turbo:before-cache` event is synchronous, which means that what you do in that
event handler will happen instantly. If, in that event, you call some animation
(like the bootstrap `close` function), then the animation won't finish executing.
This can cause two potential problems. First, the snapshot will be taken before the element
that is animating (e.g. the modal closing) is finished animating. And second, as in this case,
Bootstrap is "listening" for the animation to finish so that it can do other clean up, like
removing the overlay. But because the element was removed from the page, the animation never
"finishes" and the cleanup never happens. Weird, eh?
> Alternatively, you can disable cache on certain pages if the clean up
> process seems too complicated
> Also, starting on Turbo Drive v7.0.0-beta.8, you can add `data-turbo-cache="false"` to
> *any* DOM element individually so that they get removed before the page gets cached
> without you doing anything else!
features:
multiple_choice:
choices:
a: |
This happened because bootstrap has a bug where calling `close`
on a modal sometimes doesn't close it properly.
b: |
This happened because Turbo has a bug where sometimes our code inside a
`turbo:before-cache` event doesn't execute quickly enough.
c: |
This happened because we called `close` on our dialog and forgot to make the
`turbo:before-cache` callback asynchronous.
d: |
This happened because we called `close` on our dialog right inside
`turbo:before-cache` and the closing animation didn't have time to
finish before the cache was saved.
correct: d
js_widget:
question: |
In this video, we've added a weather widget snippet to our page and saw how it
only works the first time our page loaded. When we clicked on subsequent pages, it
stopped working!
Why?
explanation: |
In our video, the snippet of code is executed every time we load a page because it's
in our `<body>` element! But inside the snippet itself, there's a check before adding
the `<script>` to our `<head>`: the `<script>` is only added if it's not already present.
This is why the `<script>` tag was only added once, and therefore, only executed one
time no matter how many pages we visit with Turbo.
> When we forced our snippet to add the `<script>` tag without any check, it effectively
> added a new copy of itself into our `<head>` *every* single time we change the page.
> This worked, but now we have a new problem: our `<head>` is growing forever!
features:
multiple_choice:
choices:
a: |
Because the `<script>` tag that our snippet of code adds to `<head>` is only added once,
due to a check made by the code itself, and only executes once.
b: |
Because the `<script>` tag added by our snippet of code to `<head>` is added multiple
times but only executed once since there is no full page load when we are navigating
using Turbo Drive.
c: |
Because Turbo recognizes similar scripts between page views and avoids re-executing
them between page views.
d: |
The widget snippet worked as expected. It did not stop working after subsequent
page views: we even verified that the `a` tag was present!
correct: a
analytics:
question: |
When does the `turbo:before-render` event fire?
explanation: |
This is useful because you can access the contents of the new `<body>` element
that is about to replace the old one, so that you can tweak it and modify it
before any JavaScript is executed! Notice that when a page has a preview of it,
this event will fire twice! Once on the preview, and once when the full page load
has finished after the Ajax request!
> You can access the "about to be added" `<body>` element with `event.detail.newBody`!
> Related is the `turbo:render` event, which fires *after* the entire rendering operation
> has completed.
features:
multiple_choice:
choices:
a: |
It fires every time turbo has to render a page, but before its new contents have
arrived via Ajax.
b: |
It fires once per session, before Turbo initializes its JavaScript engine.
c: |
It fires every time that turbo has to render a page, including new Ajax requests
and previews, and before it replaces the `<body>` element with the new `<body>`
contents.
d: |
It fires every time that turbo has received a new page via Ajax, after it
replaces the `<body>` element but *before* executing any JavaScript in it.
correct: c
analytics_2:
question: |
At the end of our video, we talk about analytics and show an example of how you can
execute code *once* (and only once) on every page load (including the first page load!)
What event acomplishes this? And what is the *best* explanation for why other events won't work?
explanation: |
`turbo:load` is very usefull if we need to execute some code on a "per view" basis. It will
execute on every page view and will *not* repeat itself if a page has a preview. *Just* what
we need to get our analytics code working!
features:
multiple_choice:
choices:
a: |
The event to use is `turbo:load`. `turbo:before-render` and `turbo:render` do NOT execute
on the first load. They *also* execute twice if a page has a preview to show first!
b: |
The event to use is `turbo:load`. `turbo:before-render` could also work, but it does not
execute on the first page load.
c: |
The event to use is `turbo:render`. `turbo:load` only executes on the first page load but
doesn't execute later. `turbo:before-render` can execute twice if a page has a preview.
d: |
The event to use is `turbo:before-render`. `turbo:render` can execute twice if a page
has a preview, but *not* `turbo:before-render`. `turbo:load` only executes on the first
page load but doesn't execute later.
correct: a
asset-tracking:
question: |
I just came from our company meeting and I have big news! We have just released a
new version of our main CSS file!
But I'm getting complaints from users who are unable to see those changes! Oh no!
What is happening? Why are some users seeing out-of-date CSS?
explanation: |
The reason we aren't seeing up to date CSS is that turbo *thinks* that it shouldn't
update those files which have the same name!
Since Turbo is now performing full page reloads, our CSS stays the same until
we do a full refresh in our Browsers.
features:
multiple_choice:
choices:
a: |
Because when Turbo looks at the new files and see that they have
the same name as the ones we already have, it assumes they are
the same file and doesn't overwrite them!
b: |
Because our browser has cached our CSS and JavaScripts and the user
needs to perform a full refresh in order for Turbo to get the new
sources.
c: |
Because we forgot to enable file versioning in our application. This
alone would fix the issue, since Turbo by default reloads all files
with different versioning so that it keeps our CSS and JavaScript up
to date!
correct: a
asset-tracking_2:
question: |
Now that we understand why some users aren't seeing the new CSS file, what could
we change on our app to prevent this in the future?
explanation: |
One of the few instances in which we can say that a full reload is *needed* is when
our frontend code changes (JavaScript or CSS)!
By adding file versioning to our system, we can make sure that new files are downloaded once
they change. But this alone is not enough! Webpack prevents similar named files with
different hashes from running! And besides, if they did run, we would be duplicating
them on our `<head>` element: the old *and* new CSS/JavaScript files would be loaded on the same page!
By leveraging the `data-turbo-track="reload"` attribute on our `<script>` and `<link>`
tags, we can make Turbo Drive force a reload of the page if the collection of files
in the `<head>` element ever changes! This combination of techniques is our best
friend!
features:
multiple_choice:
choices:
a: |
By modifying `config/packages/webpack_encore.yaml` and adding
```yml
'data-turbo-track': reload
```
To both `link_attributes` and `script_attributes`.
b: |
By making sure you enable versioning in Webpack Encore:
```javascript
.enableVersioning(Encore.isProduction())
```
By modifying `config/packages/webpack_encore.yaml` and adding
```yml
'data-turbo-track': reload
```
To both `link_attributes` and `script_attributes`.
c: |
By modifying `config/packages/webpack_encore.yaml` and adding
```yml
'data-turbo-track': refresh
```
To `link_attributes`.
d: |
By making sure you enable versioning in Webpack Encore:
```javascript
.enableVersioning(Encore.isProduction())
```
And by modifying `config/packages/webpack_encore.yaml` and adding
```yml
'data-turbo-webpack': track-versioning
```
To both `link_attributes` and `script_attributes`.
correct: b
manual_visit:
question: |
On our site, there is one section that is very special: We expose the secrets to
creating the world's most perfect pizza. But not all users are ready for this
earth-shattering information. And so, I've decided to hide the entire page with
a button and open a big dialog on the front page of that section...
Here's how it looks!
```html
<html>
<head>
...
</head>
<body>
<p id="page_warning">
This page has been hidden for security reasons. Please click
<button
class="btn btn-primary"
onclick="javascript:document.getElementById('my_great_modal').style.display: block"
>
here
</button>
if you are ready to uncover some true secrets!
<p>
<div id="my_great_modal" style="display: none">
<h1>Welcome to our Pizza Section!</h1>
<p>Proceed only if you are ready for pizza to change your life!</p>
<button
class="btn btn-primary"
onclick="javascript:hideDialogAndShowPage()"
>
Proceed
</button>
</div>
<div id="the_rest_of_my_page" style="display: none">
...
</div>
<script>
window.hideDialogAndShowPage = () => {
document.getElementById('my_great_modal').style.display='none';
document.getElementById('page_warning').style.display='none';
document.getElementById('the_rest_of_my_page').style.display='block';
}
</script>
</body>
</html>
```
This works as expected, but I'm a bit nervous about leaving too much time
for our users to decide. They should be quick! So I've added a timeout on
the main JavaScript of the page to force users *away* after a certain
amount of time.
```javascript
window.setTimeout(() => {
window.location.href = '/';
}, 10000);
```
How can we use Turbo Drive (instead of just `window.location.href=`)
to perform a page visit without doing a full refresh?
explanation: |
By using the syntax `import * as Turbo from '@hotwired/turbo'` you import *all*
public functions from the library into an object called `Turbo`. This enables
you to use some Turbo Drive specific actions in your scripts, like `Turbo.visit()`.
> You can also use destructuring to import only the functions you need. In
> this case, that would be: `import { visit } from '@hotwired/turbo'`.
> Turbo is also set automatically as a global variable once you import it anywhere in your
> page, so you can also use Turbo from inline scripts... though you should try avoiding
> those, of course 😉.
features:
multiple_choice:
choices:
a: |
```javascript
import Turbo from '@hotwired/turbo';
window.setTimeout(() => {
Turbo.visit('/');
}, 10000);
```
b: |
```javascript
import * as Turbo from '@hotwired/turbo';
window.setTimeout(() => {
Turbo.location.href = '/';
}, 10000);
```
c: |
```javascript
import * as Turbo from '@hotwired/turbo';
window.setTimeout(() => {
Turbo.visit = '/';
}, 10000);
```
d: |
```javascript
import * as Turbo from '@hotwired/turbo';
window.setTimeout(() => {
Turbo.visit('/');
}, 10000);
```
correct: d
transitions:
question: |
I just came back from a meeting with our designer, and she has an *amazing* concept
for a new transition that we need to add to our page loads between clicks! It looks like
this in the CSS main file:
```css
body {
background-color: #fff
transition: background-color 0.2s;
}
body.turbo-loading {
background-color: #f00;
}
```
I think this is going to look *awesome* (and won't render too many of our viewers blind)!
Our solution to implementing this using Turbo Drive event listeners is as follows:
```javascript
document.addEventListener('turbo:visit', () => {
document.body.classList.add('turbo-loading');
});
document.addEventListener('turbo:before-render', (event) => {
event.detail.newBody.classList.add('turbo-loading');
});
document.addEventListener('turbo:render', () => {
document.body.classList.remove('turbo-loading');
});
```
But upon peer-review, our coworker tells us that this is wrong! Our `turbo:render`
callback is missing a `requestAnimationFrame`!
```javascript
document.addEventListener('turbo:render', () => {
requestAnimationFrame(() => {
document.body.classList.remove('turbo-loading');
});
});
```
Why do we need this?
explanation: |
`turbo:visit` will trigger immediately after a user clicks on a link to another page.
It will take care of transitioning our background color to `red`.
Once the new page renders, in order to gracefully fade back into white -as opposed to
an instant change- we use two more events:
`turbo:before-render` re-adds this class to the newly added `<body>` element so that it
*starts* red.
Finally, once the rendering finishes, `turbo:render` removes it in the browser's next frame,
so that the browser can play the transition to the white color. If we didn't add
`requestAnimationFrame`, the transition would *not* happen at all, since there would be
no time for the browser to "pain" the screen in the previous state before the transition.
features:
multiple_choice:
choices:
a: |
We need to implement all of these callbacks within `requestAnimationFrame` so
our browser can animate all of the transitions.
b: |
Because in that particular case, both events `turbo:before-render`
and `turbo:render` execute in the same frame. This means that our class would
be added *and* removed in the same frame and the transition would not take place.
c: |
Because we use `requestAnimationFrame` every time we need to implement a CSS
transition.
d: |
Because in this particular case, our last transition wouldn't have time to complete
animating unless we defer our last callback to another frame. This will happen
*after* the transition has finished.
correct: b
transitions_2:
question: |
Why is it hard in Turbo to implement page load transitions in versions 7.0.0 beta?
explanation: |
The fact that we cannot pause a render operation in Turbo before 7.0.0-rc.1 means that
our transition, if we make one, will always take the time it takes for the Ajax call
to finish. This makes it hard for us to perform complex transitions when we can't
*pause* the render until our animation properly finishes.
> Notice that starting with version 7.0.0-rc.1 the "Pausable rendering" PR has been
> merged, making it easier to implement page transitions between clicks!
features:
multiple_choice:
choices:
a: |
Because there are no good event handlers to use when transitioning pages for
this particular purpose.
b: |
Actually, you *can* easily implement page transitions between clicks in 7.0.0 beta.
c: |
Because when a page finishes loading, Turbo replaces the `<body>` element
immediately, leaving no time for a transition.
d: |
Because there are other libraries that can achieve this.
correct: c
transition_finish:
question: |
In Turbo Drive, how can we tell when a page is a preview or a freshly downloaded page?
explanation: |
Turbo adds a `data-turbo-preview` attribute to the `<html>` element whenever a preview is rendered. We
can use this to identify whether we're dealing with a preview or a real page in JavaScript.
features:
multiple_choice:
choices:
a: |
```javascript
document.body.hasAttribute('data-turbo-preview');
```
b: |
```javascript
document.querySelector('body').hasAttribute('data-turbo-preview');
```
c: |
```javascript
document.documentElement.hasAttribute('data-turbo-preview');
```
d: |
There is no way of differenciating between a preview and a real page in
Turbo.
correct: c
native_prefetch:
question: |
Imagine our website has a *very* important landing page - the route to it is
`app_pizzas`. We want to "prefetch" this from *every* page so that it's
always ready to be loaded instantly if the user wants to go there.
Assuming we have a `{% block metas %}{% endblock %}` that we can override, what
is the native way to do this?
explanation: |
`<link rel="prefetch">` is a useful tool that you can leverage with Turbo Drive
when you need to make certain pages readily available to the user.
In our example, we want to add this prefetch link on every page (e.g. in `base.html.twig`).
Make sure you have this in mind, because if you add a prefetch link in a *specific* page,
this won't stay in the `<head>` element for other pages!
features:
multiple_choice:
choices:
a: |
```twig
<link rel="prefetch" src="{{ path('app_pizzas') }}">
```
b: |
```twig
<link rel="prefetch" href="{{ path('app_pizzas') }}">
```
c: |
```twig
<a rel="prefetch" href="{{ path('app_pizzas') }}"></a>
```
d: |
```twig
<meta rel="prefetch" href="{{ path('app_pizzas') }}">
```
correct: b
lazy_frame:
question: |
What is a Turbo Frame and what does it do?
explanation: |
The `<turbo-frame>` HTML element is a custom element that allows us
to make areas of our site navigate independently of the rest of our site.
You can use Turbo Frames if you want navigation (e.g. link clicks and form submits) to
happen (or "stay") inside of a specific area, instead of affecting the entire page.
area of the page, instead of having the whole page refreshed.
Another use is when you want a part of your page to load lazily via Ajax, after
the rest of your page has loaded.
features:
multiple_choice:
choices:
a: |
A Turbo Frame is an `<iframe>` element in a page that has extra
functionality, like loading pages via Ajax calls.
b: |
Turbo Frames is a system that allows you to create complex animations
in our web pages by making Ajax calls.
c: |
A Turbo Frame is an area of our page in which we can load content and
update it via Ajax calls that return HTML. It behaves similarly to the
old `<iframe>` system.
d: |
A Turbo Frame is an area of our page that has the ability to stay loaded
while other parts of our page change. It is mainly used as navigation bars.
correct: c
frames_find_frames:
question: |
My website has a terribly complex sidebar! Our project manager asked us to extract
it to a separate route so that we could load it lazily using Turbo Frames. This
work is done! Our route has the name `_app_nav`, and it renders a frame with an id of
`app_nav_frame`.
How could we load this in our main template?
explanation: |
The `src=""` attribute tells Turbo to make an Ajax callto this URL to fetch the frame.
Once it does, it reads the `id` attribute of the original `<turbo-frame>`
(`id="app_nav_frame"`) and finds a `turbo-frame` with that *same* id inside the Ajax
response's HTML.
features:
multiple_choice:
choices:
a: |
```twig
<turbo-frame src="{{ path('_app_nav') }}"></turbo-frame>
```
b: |
```twig
<turbo-frame id="app_nav_frame"></turbo-frame>
```
c: |
```twig
<turbo-frame id="_app_nav" src="{{ path('app_nav_frame') }}"></turbo-frame>
```
d: |
```twig
<turbo-frame id="app_nav_frame" src="{{ path('_app_nav') }}"></turbo-frame>
```
correct: d
frames_find_frames_2:
question: |
When we load a Turbo Frame, we need to specify an `id` property both in the frame
on the page that does the loading, and on the frame in the rendered fragment.
Why?
explanation: |
A core feature of Turbo Frames is the ability to fetch a full page via Ajax... but then
*only* find and use the `<turbo-frame>` inside whose `id` matches the frame id that
*initiated* the request.
This means that several frames can load *the same* URL and only take the parts that
belong to that particular frame for updating it.
features:
multiple_choice:
choices:
a: |
Because Turbo needs to know if the rendered fragment matches the frame that
did the request, since URLs can be hacked.
b: |
The rendered response can have any id. Turbo just looks at `<turbo-frame>`
elements within it and will only render that part of the response.
c: |
Because Turbo will look at the part of the rendered response
that exactly matches the `<turbo-frame id="">` pattern and only render that
part.
correct: c
lazy_frame_full_frame: