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