Javascript in Phoenix templates

Hi!,

What’s the best way to sprinkle bits of javascript for use inside EEx templates, just simple things like handling button clicks, hiding tags etc. I’ve been using a <script> tag at the bottom of the template with some common functions in a global object created in assets/js/app.js.

Is this a reasonable pattern? What are recommended/best-practices around this?

Sorry if this question is a bit naive, I’m pretty new to web-dev and js in general.

2 Likes

Welcome to the forum!

A vanilla phoenix project is structured around modular javascript.

If you don’t want to use a bundler you can always specify:

mix phx.new PATH --no-webpack

Any additional assets are then kept directly under priv/static.

It may be necessary to adjust the endpoint to pick up assets under non-standard directories.


That being said npm is currently the de facto mechanism for publishing JavaScript libraries (essentially making bower redundant) - so there is significant drive towards adopting a bundler that works with npm.

2 Likes

Hi, you can create helper functions into separate files, it’s a very common and modular approach, something like:

helpers/buttons.js - Handle clicks for buttons
helpers/inputs.js - Handle events for inputs
helpers/animations.js - Handle animations for elements

Then you just import those files inside your main script to include them in your bundle.

Also I’d recommend using the defer attribute rather than putting <script> at the bottom. With defer the browser will download the script while the HTML is being parsed. If you put <script> at the bottom, the browser will parse the HTML and when it hits the <script> tag, it will download the script, so technically is slower.

Here’s a nice article about this: https://flaviocopes.com/javascript-async-defer/

I’d definitively not recommend async if you split your bundle.

2 Likes

And defer seems to be well supported these days.

The problem with a plain or async head script is that it delays FCP (first contentful paint).

You still have to be careful in some situations:

Use async or defer

1 Like

Take a look at Stimulus. This is exactly its use case.

Stimulus is a JavaScript framework with modest ambitions. It doesn’t seek to take over your entire front-end—in fact, it’s not concerned with rendering HTML at all. Instead, it’s designed to augment your HTML with just enough behavior to make it shine. Stimulus pairs beautifully with Turbolinks to provide a complete solution for fast, compelling applications with a minimal amount of effort.

2 Likes

I think this is a pretty reasonable way to start for your use case. The only possible issue is that your JS doesn’t go through the webpack pipeline if you do it page by page so any transformation / optimisation / minification will have to be done manually.

There is also the option of adding more entrypoints to the webpack config file. I tend to do this when I have shared JS relating to a feature spanning multiple pages. So instead of just app.js or sprinkles at the bottom of the page I’ll have blog.js, store.js, admin.js e.t.c.

2 Likes

Thanks for taking the time to reply!

I think I understand webpack a little better now, but what I’m a little unclear about is why we need to use a bundler at all with phoenix apps.

If my understanding is correct, SPA apps send a big blob of JS to the client, which once parsed and initialized creates markup, and handles everything client-side. So, it makes sense for them to pack everything into a single app.js and send when the page first loads.

In phoenix though, everything is handled on the server, so I’m confused as to why we’re sending the whole app.js bundle on each page load. It’s not like we send all our HTML each page load, we only send the layout and what’s required for that page to render, why not do the same with JS? Load common libraries in the layout template and load page specific js in their respective templates.

I feel like I’m missing something obvious, but not sure what it is.

2 Likes

You are not “sending”, you only specify the resources source. The browser then chooses to cache or not to cache this resource and is free to not download it again in the future.

This way you can massively decrease the number of requests made to your server. Also a single large request is usually more effecient regarding the payload/header ratio than many small ones.

Of course you are totally free to use many entry points and separate your scripts that way you describe.

Also bundling makes it possible to use modular JavaScript in the browser.

The bundler organizes the code in such a way that the various modules only interact with one another in a well defined manner. Browserify started doing this in 2011. It’s only since about 2017 that browsers started supporting ECMAScript modules natively - and even then using them tends to lead to a lot of additional requests because the aren’t bundled.

Thanks! It makes sense now, I was naively assuming browsers download it everytime.

Hi everyone, newcomer here

Is there any pattern or library that has a similar pattern to Laravel’s blade templating [1]?

I think it is very straightforward when we want to add css or js on a single page.

@extends('layouts.app')

@section('title', 'Page Title')

@section('css')
  .foo {
    margin: 0px;
  }
@endsection

@section('js')
  var foo = "bar";
@endsection

[1] https://laravel.com/docs/5.8/blade

1 Like

I’m not aware of any library doing this like in Laravel, but it’s easy enough to set it up on your own.

Take a look at render_existing:
https://hexdocs.pm/phoenix/Phoenix.View.html#render_existing/3

You would have a bunch of these in your app.html, or wherever you define your top-level layout files:

<%= render_existing @view_module, "page_layout/head_scripts_css.html", assigns %>
<%= render_existing @view_module, "page_layout/head_scripts_js.html", assigns %>

and then a page_layout folder structure per view template where you would create and place these head_scripts_css.html as needed.

The big difference between render_existing and what most templating engines allow for is in the possibilities in nesting.

In phoenix you can only use render_existing for view modules you know about. So e.g. the outer layout html is aware of the view_module the controller told it to render (might be selected explicit or implicit). It’s however not aware of arbitrary nested partial templates, which are used somewhere deeper down the call stack of templates rendered within other templates.

So render_existing doesn’t play well when you want a partial to add something to the layout.