0

I'm working on a project that has a massive script.js file where all the shared functions, code and more is placed; but it also has code that has some page-specific behavior.

Evidently, this causes issues in certain ways as including the line $('#bank-account').on('change' ... in those files that are not the one it is supposed to be run at, will trigger some random behavior.

Talking about static file serving, it's better to server 1 file than multiple files, and for that reason people concat and minify JS files. This usually take place on application-level code, like libraries or code that must run in all pages.

My question is, what about page-specific behavior? where should I be placing it? Take for instance something as simple as initializing a select library like $('#mySelect').select() or something as complex as a Vue or React object to create a data-driven component on that specific page.

Should this be located in a per-page javascript file structure, or maybe inside the tags at the bottom of the file?

1

There are a few ways you can separate your code. In an existing application, javascript namespacing might be helpful. You use your bundler of choice (gulp, grunt, etc) but separate out page javascript by file and namespace.

var myCo = myCo || {};
    myCo.page = myCo.page || {};
    myCo.page.productDetail = function(){
        // You can set properties and methods on the object to use later in
        // this code. Set these in the page.
        this.container = null;
        this.init = function(){
            // Here is where you put initialization code,
            // like setting controls you need to reference
            // or getting data, etc.
        };
        this.getProductData = function(){
            // return data here
        };
}

In your actual page, you'd have a script block that calls initialize on your "controller".

<script>
    var page = new myCo.page.productDetail();
    page.container = $("#pageContainer");
    page.init();
</script>

This is an easy way to make sure that code not associated with this page isn't triggered. You can use any js tha you have, just keep it properly namespaced and you can still use it, just make sure you keep all of your code that runs on a page in your page-specific js.

This has the added benefit of being easy to add to existing projects, whereas refactoring existing code to Angular (for me at least) was a nightmare.

I've never worked with React, but Vue seems to be pretty open to letting you use whatever code you want, meaning you don't have to necessarily wrap your utility javascript in special code for it to be used by Vue.

0

Whether it makes sense to have one bundle.js file or several depends on the parameters of your project aka demands:

  • When page load time is critical, it would make sense to split functionality into several bundles. Serving first a minimal set of functionality and asynchronously loading needed functionality afterwards

  • If you designing for mobile, meaning: not only for small displays but also for bad connections you have to calculate a tradeoff between one fat request vs many smaller ones and take flaky connections into account

  • Then there is the browser's cache: If you change your JS once in a while, users may not notice when they revisit your page, since the browser has cached your JS anyways

Evidently, this causes issues in certain ways as including the line $('#bank-account').on('change' ... in those files that are not the one it is supposed to be run at, will trigger some random behavior.

This is not evidently and a clear sign of a wrong design. In the best case, it should do nothing, which is determined and harmless behaviour.


To improve your code layout and design I would recommend, that you have a look into modern bundlers:

There you find concepts like entry points and some of them support tree shaking.

It is possible instead of having a single bundle.js having something like a shared.js which is a bundle of common functionality and a per page bundle which represents a separate entry point to your application.

tree shaking is a technology used to strip out unnecessary parts of code included to a bundle, which makes bundles small.

Take for instance something as simple as initializing a select library like $('#mySelect').select() or something as complex as a Vue or React object to create a data-driven component on that specific page.

If you are using said bundlers you could do it both ways: having one or several entry points. The component should be active on every page it is included and otherwise remain silent, doing nothing. And this is independend from using Angular, Elm, Ember, jQuery, Preact, Ractive, React, VueJs or whatever.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.