$ (document) .ready () in the bundled script

Recently, I have been doing a lot of web optimization, and I had an interesting problem. I was wondering if anyone could find out about the existing solution.

Suppose you have several external .js files for each page, each of which has its own page $(document).ready() . Say, the document ready function for page 1 applies a style to each <li> in the body, and the document prepared on page 2 styles only <input type="button" /> s. A simple example.

Now say that you link these 2 scripts along with all your library scripts to reduce the number of HTTP requests when loading the page. Now both documents are ready, and whether on page 2 it will be formatted with a code intended only for page 1.

My question is, is there a way through jQuery or a third-party library to assign a specific document ready for a specific page, but still they are all linked into one .js file?

+8
source share
7 answers

From an architectural point of view, if a block of code makes sense on only one page, why shouldn't it be associated with this page? I know that it might seem more “organized” to put all your HTML in one place and your javascript in another, but does it really save your server or speed up work with your user?

The moment of addition comes when we reduce the number of connections, but increase the load on the server, because we fill so much unused junk into our combined file. Which better serves 1000 files of 1 thousand. Or 100 100 thousand. Files. If you have 100 pages with a unique document.ready , then you add a lot of data for the user when they visit only one page. The advantage of such a package is really useful only if there is a high probability that the user will use part of the related content. For example, Google.com, where they pre-cache the objects needed on the results page, because by the very fact that you are on Google google.com implies a rather high degree of confidence that you will perform a search. However, it does not pre-cache gmail or google docs.

+1
source

You must combine your scripts according to your pages.

Suppose your home page requires jquery and some custom scripts. Tie them together and refer to this kit.

For other pages, such as a profile page, you link the required scripts and link to them.

+2
source

I think there are conflicting goals in what you are trying to achieve: some of these things are common, and some of them are common to one page. If this is the last, then why is it in a common module?

Having said that, one of the approaches that we have successfully used is to transfer all commonly used functions to the main .js file, as well as to the entire site $(document).ready() .

Individual pages may have a localready() function, and the last step of $(document).ready() is to start it if it exists:

 /* === common.js === */ $(document).ready(function(){ // snip if (typeof(localready) != 'undefined') { localready(); } }); 

And in the next document:

 </body> <script> function localready() { foo(); bar(); } </script> </html> 

So, if the page being displayed has a localready () function, it is called and does whatever it needs to do. If this is not the case, the standard ready () is executed, and that is.

Hope this helps.

+1
source

I assume a simple if can solve this problem:

 $(document).ready(function(){ if(location.href == page1) { ... } }); $(document).ready(function(){ if(location.href == page2) { ... } }); 

change

If you do not want to touch the code, you do not want to include only the .js files that are on each page. This is even better because you are not wasting client resources on code that it will not use.

An example of achieving this would be to create some kind of server code to glue all the files together, rather than do it manually. PHP example:

 <script type="text/javascript" src="<?php echo Glue::javascript($array_of_files); ?>"></script> 

You can expand it to "glue" css or other types of files as you wish. In addition, you can even include code to minimize them as well. Of course, the function will cache these files, so it does not have to “stick” it every time.

0
source

By "bundle" do you mean suturing ?

One of the strategies that I saw and partially implemented myself is that the application should notify the view builder of all the necessary CSS / JS, as it creates the view; In your example, when the page is built alone, this allows the view designer to know that he needs a specific JS file.

When the page is ready for maintenance, only one JS and one CSS file are mentioned in the head, and they are wired files.

I saw how this was done simply dynamically, for example. <link rel="stylesheet" href="/style.css?pageOne&specialFooter&member" /> or using a caching mechanism, for example. <link rel="stylesheet" href="995093293da7f03f9b631e8d3ec4efc7.css" /> (where this is actually the file that was generated the first time a combination of styles was requested, and now it's direct CSS [no longer dynamic])

0
source

You can always handle page loading from an “application perspective”.

For example, create a “navigator object” that sets a constant when the user wants to go to the page:

 const navigateTo = (page) => { let pageName = '?'; switch (page) { case 'login.html': pageName = 'Login'; break; case 'index.html': pageName = 'Home'; break; default: console.log("Unknown page: " + page); } location.href = page; return pageName; } 

Convert your "document.ready" scripts to functions, such as the login page ready function:

 $(function() { console.log( "Login page ready!" ); }); 

will look like this:

 const loginReady = () { console.log( "Login page ready!" ); } 

Then, whenever a user changes the page by clicking on a link or navigation bar item, run this function:

 const runReadyScripts = (page) => { switch (page) { case 'Login': loginReady(); break; case 'Home': homeReady(); break; default: console.log("Unknown page: " + page); } }; 
0
source

Source: https://habr.com/ru/post/900479/


All Articles