I am looking for best practices/design patterns for keeping JavaScript in external JS files/bottom of the page. I am running into a problem where my pages are built from a number of components, and each component replies on a jquery component that needs several params passed to it.
So for instance in a JSP
<div class="component-a">
<div id="js-slideshow-<%= slide-id %>" class="js-slideshow"></div>
</div>
<script>$('#js-slideshow-<%= slide-id %>').initslideshow({'path':<%= path %>});</script>
The problem is I now have tags peppering my markup and there is alot of repeat code. Ideally I would break out all these JS calls into a JS file that is included at the bottom of the page.
My initial thought would be to load up any params the jquery plugins need as data-* attributes.
Something like
JSP
<div class="component-a">
<div data-path="<%= path %>" class="js-slideshow"></div>
</div>
JS file
<script>
$(".js-slideshow").each(function() {
$(this).initslideshow('path': $(this).attr('data-path'));
});
</script>
Are there any other good patterns for keeping JavaScript separated out in JS files even when the calls require data/context the server needs to provide and may only be available from the context of a component?
Clarifications:
This is simply practice of breaking out common presentation elements into separate files. Ruby on Rails partials are one example of this.
One component may be a “Slideshow” but depending on which page its located on i may want adjust its behavior using different values, such as different sets of images to show, different size images, or a different title, etc. This “variety” in parameters “known” by the server, and it would be up to the server to understand the context to pull the param values from a serverside data store and write them to the JS calls.
Ideally I would like to minimize the number of times the same “base” JS is written out and execute it at the bottom once for the following reasons:
1. Decrease page weight
2. Increase readability of generated HTML
3. Moved javascript code (even if they are just calls) from the HTML file to a JS file(s) – which is a clean separation of code and data
4. Allows for more data to be cached (the JS file can be cached and the extra page weight doesnt have to be downloaded on other page requests)
5. Avoid the scenario of more complex components having multiple events bound to the same element. For example:
$(".slideshow").init('<%= param %>') adds a bind event to the .slideshow element, if I call $(".slideshow").init('<%= param %>') multiple times, multiple events will be bound to that DOM element. (I think bind works like that, if not live or delegate does).
I can get around it by calling init on a uniquely named element, but this requires adding unique ids to each slideshow DOM element, which seems unnecessary.
In terms of development I will most likely have a separate JS file for each component, but will pack them into a single file during the build process.
so what you are saying is that the parts of your site come in “modules” that have their own HTML and JS, and that when you sum it all up, they are just in the middle of things?
i suggest you put script paths as variables or
data-*and have a loader at the bottom do the lazy loading later.like say:
then at the bottom of your page, before your `, you have some script that does:
in the end, you have a clean page. at least, you need jQuery and the code above in the page. the rest of your scripts are dynamically loaded at the bottom.