How to compile css and jss in multi page application in laravel page wise using laravel mix . suppose i have page 1 , page 2 and page1 have test10.js, test11.js, test12.js and test10.css, test11.css,test12.css and page2 have test21.js, test22.js, test23.js and test21.css, test22.css,test23.css and so on. So someone let me know how to compile the css and jss in multipages applications.
For most cases, it is a good practice to optimize a big chunk of your assets to work on almost all pages. It is not a big problem that some pieces are not getting used on every page because caching gives better performance results when you only use one file that stays the same on every page.
There is an option for compiling multiple assets. You can just call the js() or sass() or an other method an other time. This time referencing an other file that needs to be compiled. In your layout you can add them per page.
What I like to do is the following:
I add a #stack('js) to my main layout.
For every piece of Javascript that only needs to be included at a single page I use #push('js) and #endpush.
Sometimes, when the code gets to big to handle, I add a js() method in my webpack.mix.js file. This gives me more freedom in writing my javascript.
A stack has a big advantage: It accepts multiple entries. This comes in handy when you use partials to build up your view and you want to keep the Javascript logic in the same files.
Related
I have a simple Laravel application with three routes: /page1, /page2, and /page3.
Each of these pages will have a root VueJS component, and a substantial tree of sub-components. Most of the sub-components will be specific to their page, but a few will be shared across pages.
I am using Laravel UI boilerplate, so that means ES6, single-page VueJS components, NPM and Webpack.
As far as I can see, I have two options for structuring the VueJS application. The first option would be to create an entry point for each page (page1.js, page2.js, and page3.js). The problem with this approach is that any code for the shared components is duplicated across the compiled assets. (I realise that I can configure Webpack to de-duplicate, but I'd rather not have to touch Webpack at all).
The other option would be to have a single entry point, app.js. This file would instantiate three different Vue instances, binding each to a different DOM element, #app-1, #app-2, #app-3. Each of my pages would then have only its respective DOM element. The question is, however, how much client memory will the unbound Vue instances consume?
For example, if the web page contains #app-1, then #app-2 and #app-3 will remain unbound. I would expect them to take some some memory, but will they take up an amount proportional to a simple Vue instance only, or proportional to their entire tree of sub-components?
I have some complex pages that make use of many RenderPartial (from 13 up to 20).
I've found that those pages are taking from 400 - 800ms to render (that's just for the view rendering time. Action time is not included and it is not an issue).
There are no queries/anything else on the pages, they just render a pre-loaded model. If I "glue" all the partials on each page, I can cut those times to 1/4. That's a lot of time.
Precompiling the pages do not solve anything, as that only impacts the startup time of the page. But the generated code it's the same.
My question then is: Is there a way I can, via some external tool, to "replace" those RenderPartials with the actual code from the partial? Maybe I can even run that tool on deploy only. After all, those partials are only used on specific pages and they do not need to be accessed from other actions as standalone views...
Thymeleaf puts a large emphasis on "natural templating", which means that all templates are already valid XHTML files. I always thought that is a great step forward that I can generate fragments in my templates e.g. in JSP I'd write
<tagfile:layout title="MyPageTitle">
<jsp:body>
Main content goes here
</jsp:body>
</tagfile:layout>
My "Layout"-Tagfile contains all the header-tags (title, link to stylesheets,...), the menu and justs inserts title text and body at the right point. I don't need to know anything about stylesheets menus or the like when designing my html fragement.
This is in contrast to the idea of Thymeleaf which encourages me to create full html pages (including a sample menu and all the headers). While the manual of Thymeleaf continues to emphasise how great this is, it never deals with duplication of code concerns:
I have one template that generates a menu and all my other templates (could be many) include a copy&pasted dummy menu just so that I can view the template in a browser without the server side generation mechanism. If I have 100 templates that means that prossibly the exact same dummy menu exists 100x (in each and every template). If I change the look of the menu it's not done with creating a new dummy menu, but I need to copy&paste the new dummy menu into 100 templates.
Even if I decide to do something as simple as renaming my CSS file I need to touch all my templates as well.
There is always the danger that my template looks just fine in my browser, but the generated output is broken because... well... I broke it (could be as simple as a misspelled variable name). Thus I will need to test the output with the actual generation anyway.
Did I misunderstand something there? Or is this indeed a trade-off? How do you minimize the impact of code duplication?
Natural Templates are just an option in Thymeleaf. As you can read here http://www.thymeleaf.org/layouts.html there are many options, including a hierarchical layout approach like the one you seem to prefer (I recommend you to have a look at the Layout Dialect).
However, Natural Templates are the preferred and most explained layout option because Thymeleaf was thought from the ground up to allow you to do static prototyping (in contrast to most other template engines). But it doesn't force you to.
So.. how are Natural Templates applied in the real world to avoid code duplication becoming an issue? That depends on the scenario, but one pattern we see repeated a lot is people creating full document, natural templates for 3-4 or maybe even a dozen of their application's templates, only those that are more likely to take a part in the design process --exchanged with designers, with customers...--, and simply not apply that header and footer duplication in the rest of the application's templates, making their creation and maintenance much simpler.
That way you can have the best of both worlds: a means to exchange fully displayable pages between programmers, designers and customers for the pages that this is really relevant; and also a reduced amount of duplicated code.
What's more, thanks to libraries like Thymol (referenced in the article linked above) you can even avoid code duplication completely, allowing your fragments to be dynamically inserted via JavaScript when you open your templates directly in your browser without running the application.
Hope this helps.
Disclaimer, per StackOverflow rules: I'm thymeleaf's author.
I want make my website to load faster, usually I put my code in the <head>, in some third party library's dom ready function, like jQuery.
I read that if I put the script code directly in the bottom, it could make the page load more faster.
So if its true, It means that If I put the script in the bottom its better right?
Loading a script causes the browser to block loading the rest of the page until the script is loaded and executed. This is to allow the code to make any changes before the browser continues rendering. Placing your scripts at the bottom of the page (just before the </body> tag) allows the browser to load an rednder substantially all of the document before it blocks to load the scripts. From the users perspective the page will load more quickly.
This is not the same as controlling execution by adding your code in a DOMReady function, although in practice there may be little difference in effect.
I'm building my first ajax-heavy application and am not sure of the proper approach for such things.
If, for example I ajax in a html partial (a form), with:
$('#content').load('form.html');
how should I include the javascript and css?
I can, of course include them in the original document, but that seems wasteful if the form is never loaded. I can inline them (in form.html) with <script> and <style> elements, but that seems like the wrong approach.
You can use a separate JS file and load it using $.getScript() in the .load callback.
Inline CSS should work fine, but since you run the risk of it messing up your main page, you should load it as part of the main page and not with AJAX.
If it were me, though, I wouldn't be afraid to leave a few extra lines of well-targeted JS and CSS code in your main page -- it's more efficient to load it with the other JS and CSS at the beginning, in the same file(s), than to fire off another network connection and wait for it to download.
The $.getScript() would make an additional http request to load the js file that is to be used in form.html.
So, say for example, if you load 20 forms via ajax, you have to make 20+20 http request( 20 for loading js file and 20 for loading the html for forms)
A possible optimized approach is:
loading the all the css ( minified) at the beginning.
IF a single js file is real large even after minifying,
Arrange the js functionality based on the PROABABILITY of use in different files ( (the fewer number of files , the better).
Minify those files and load the file with highest probability at the beginning .
And then use $.getScript() to load the file after checking if the file has already been loaded.