Moving

With the introduction of the Symfony UX Initiative a lot of cool things are happening in the Symfony world related to JavaScript. Stimulus already has great integration thanks to the Encore.enableStimulusBridge() feature and Turbo has huge potential to give an SPA-like experience with server-rendered HTML. Related to this, I want to talk about a simple change that just happened to the symfony/twig-bundle recipe. If you start a new project today, the location of the {% block javascripts %} in base.html.twig has moved from the bottom of the page up into <head>: 1 2 3 4 5 6 7 8 9 10 11 12<!-- templates/base.html.twig --> <html> <head> {% block stylesheets %}{% endblock %} +

  • {% block javascripts %}{% endblock %} </head> <body> {% block body %}{% endblock %}
  • {% block javascripts %}{% endblock %} </body> </html>

Historically, this lived at the bottom of the page so that any <script> tags wouldn’t be executed until the page had already finished loading. This was for two reasons:

When your browser sees a normal <script> tag, it waits (blocks the page) while that JavaScript is downloaded and executed. You often want the full HTML to already be available when your JavaScript executes.

So why did we move the javascripts block into <head>? Isn’t that worse? Actually, it’s better, as long as your script tags have the defer attribute.

<script src=”” defer>¶ When your browser sees a <script tag with a defer attribute, it treats it differently. First, it still starts downloading it immediately… but your browser does not wait for it to be downloaded before rendering the rest of the page: it is “non-blocking”. And second, after the JavaScript is downloaded, your browser waits until the page is fully-loaded before executing the JavaScript. In other words: your browser starts downloading the file earlier (without blocking the page) but your code is still executed after the page is loaded: the same as having it at the bottom of the page. So as long as your add the defer attribute, life is good! Well… except for “inline” JavaScript: it behaves differently.

The “Caveat”: Inline JavaScript Cannot be Deferred¶ When you use <script src="/app.js" defer>, that code will execute after the page finishes loading, just like if the <script> tag were at the bottom of the page. But inline JavaScript cannot be deferred. Imagine you have an app.js file that creates a global variable: 1 2 3 4 5// app.js // set a global "App" variable window.App = { // ... }

And then you write some “inline” JavaScript in your template that uses it: 1 2 3 4 5 6 7 8 9<html> <head> <script src="/app.js" defer></script> <script defer> // try to use the App variable from app.js App.initializeSomething(); </script> </head> <!-- ... -->

If you tried this, you’d get an error!

Uncaught ReferenceError: App is not defined If you have multiple <script src="/..." defer> tags, they do render in order. The problem is that “inline” JavaScript cannot be deferred: it always executes immediately. This means that App.initializeSomething() is called before app.js. If you have a lot of inline JavaScript like this, then you may not be able to use defer. No problem: keep your JavaScript at the bottom of the page without defer. But the ideal solution is to move all of your inline JavaScript into external JavaScript files. This can sometimes be tricky if you want to pass a dynamic value into JavaScript. This can be fixed by setting a global variable and reading that in your external JavaScript: 1 2 3 4 5 6 7 8 9<script src="/app.js" defer></script>

<script>

  • // JavaScript is "inline" so we can use Twig to pass a dynamic value

  • App.initializeSomething('{{ someDynamicValue }}');

  • // read this from app.js

  • window.SOME_DYNAMIC_VALUE = '{{ someDynamicValue }}' </script>

In app.js, you can read window.SOME_DYNAMIC_VALUE. Another popular approach is to add data- attributes to an element and read them in JavaScript.

encore_entry_script_tags() and the “defer” Attribute¶ If you use Webpack Encore, then you probably don’t write your <script> tags by hand: you render them with the handy encore_entry_script_tags() Twig function. So, how can we add the defer attribute? In WebpackEncoreBundle 1.9, you can specify - in webpack_encore.yaml - an array of attributes that you want to include on all script tags. To always add defer: 1 2 3 4 5 6# config/packages/webpack_encore.yaml webpack_encore:

...

  • script_attributes:
  • defer: true

That’s it! No change needed to your templates. If you install WebpackEncoreBundle today, you’ll get this config automatically thanks its recipe. Have any questions, let us know! We’ll soon cover all of this on SymfonyCasts. Have fun!

                Sponsor the Symfony project.

http://feedproxy.google.com/~r/symfony/blog/~3/TKCr0S6v7Mk/moving-script-inside-head-and-the-defer-attribute

Creado 4y | 19 ene 2021, 14:20:26


Inicia sesión para agregar comentarios

Otros mensajes en este grupo.

A Week of Symfony #961 (May 26 – June 1, 2025)

This week, Symfony released the stable version of Symfony 7.3, which includes lots of amazing new features. We also published the maintenance versions 6.4.22 and 7.2.7.

Symfony development highlights

1 jun 2025, 8:50:16 | Symfony
New in Symfony 7.3: DX Improvements (part 2)

This is the second part of the blog post showcasing the main DX (developer experience) features introduced in Symfony 7.3. Read the first part of this blog post.

Verify URI Signatures… https://symfon

29 may 2025, 9:10:19 | Symfony
Symfony 6.4.22 released

Symfony 6.4.22 has just been released. Read the Symfony upgrade guide to learn more about upgrading Symfony and use the SymfonyInsight upgrade reports to detect the code you will need to change in you

29 may 2025, 9:10:19 | Symfony
Symfony 7.2.7 released

Symfony 7.2.7 has just been released. Read the Symfony upgrade guide to learn more about upgrading Symfony and use the SymfonyInsight upgrade reports to detect the code you will need to change in your

29 may 2025, 9:10:18 | Symfony
Symfony 7.3.0 released

Symfony 7.3.0 has just been released. Check the New in Symfony 7.3 posts on this blog to learn about the main features of this new stable release; or check the first beta release announcement to get t

29 may 2025, 9:10:17 | Symfony
Symfony 7.3 curated new features

Symfony 7.3.0 has been released. As for any other Symfony release, our backward compatibility promise applies and this means that you should be able to upgrade easily to 7.3 without changing anything

29 may 2025, 9:10:16 | Symfony
New in Symfony 7.3: DX Improvements (part 1)

Symfony 7.3 includes many small improvements aimed at making developers' lives easier and more productive. This blog post highlights some of the most useful DX (Developer Experience) features added in

28 may 2025, 9:50:15 | Symfony