dojo.require("dijit.Dialog");
dojo.require("dijit.form.Form");
dojo.require("dijit.form.Button");
dojo.require("dijit.form.DateTextBox");
dojo.require("dijit.form.TimeTextBox");
dojo.require("dijit.form.ValidationTextBox");
dojo.require("dijit.layout.TabContainer");
dojo.require("dijit.layout.ContentPane");
dojo.require("dijit.Tooltip");
dojo.require("dojo.parser");
dojo.require("dojo.fx");
dojo.require("dojo.dnd.Manager");
dojo.require("dojo.dnd.Source");
dojo.require("dojox.layout.ContentPane");
dojo.require("dojo.io.iframe");
This appears with CDN or with src="",
and show in inspect element in my page a lot of requests, someone know why?
Well, It seems you want to understand the flow of Dojo I mean how it works and how it loads its dependencies.
In above snippet code as we can see you are using legacy model/version of dojo
First we understand the require and define
require and define are part of the asynchronous module definition (AMD) API.
You use define to define a module that can be consumed by other code. Generally, define will be used in a javascript file. The javascript file is defining a module. All Dojo files use define.
You use require when you are not defining a module, but you require modules that have been defined.
Loading of widgets
So in your network and console you can observe that whenever you load the dojo cdn link it simply loads the init.js default loader file. very small in size and easy/faster to load.
So once your dojo loader is loaded based on your dojo configuration then it start looking for dependencies which you are using in your project so which ever widgets (dojo controls, classes, files etc.) you mentioned in require it will start loading those widget from CDN.
In this case dojo doesn't load the whole dojo library in your prject it simply loads only those widgets which you mention in require.
Hoping this will answer your concerns :)
Related
I was going through Mui's Server-side Rendering DOCS.
And It says to prevent FOUC, we should inject style to rendered HTML on server side.
This was very clear.
But after that, it says "On the client-side, the CSS will be injected a second time before removing the server-side injected CSS."
this is the part I don't get.
why should we inject CSS again on client-side if it's already injected server-side?
Is there any difference between client-side cache and server-side cache?
And what is benefit of doing this?
If I had to guess, it would be that if some new Material UI element appears during runtime, the client needs to be able to handle that. SSR after all is for the initial loading of the page. So basically it is client rerendered to allow being dynamic.
This however creates issues for me personally as well since the new tag overwrites my Tailwind . Am trying to figure out how to render the client version above/before the Tailwind one, hence is why your question popped up on Google.
Edit: If I remember correctly, I solved using emotion; https://emotion.sh/docs/ssr
If we give cq:includeClientLib inside my component jsp and if we drag and drop the component twice on that page, will the clientlib gets loaded/included twice?
what will be the case if we do in Sightly way (data-sly-call="${clientlib.all # categories='somecategory'}") ?
And also what is the suggested method of including client libs, either create a clientlib specific to the component and load only for that component or include all the CSS and JS at a common clientlib and use it across?
No, the clientlib is only included once for a category.
This is by design as the HTL (and respective JSP tag) are evaluated during runtime and the processor keeps a map of categories that have already been included and does not include them again.
As #i.net mentioned, each category will only be included once. To answer your follow up question about the suggested method..
The best practice seems to be to define a client library for each component, which is then embedded into a "global" client library. That global client library will then be included within your page template.
/etc/designs/acme/clientlibs-all
categories=["acme-all"]
embed=[compA,compB]
/apps/acme/components/compA/clientlibs
categories=["compA"]
/apps/acme/components/compB/clientlibs
categories=["compB"]
The reason the global client library is located under /etc/designs is to prevent exposing /apps to the public. However, in AEM 6.3, you could make use of the allowProxy property to serve the code at /etc.designs/. This would then look like this:
/apps/acme/clientlibs/clientlibs-all
categories=["acme-all"]
embed=[compA,compB]
allowProxy=true
/apps/acme/components/compA/clientlibs
categories=["compA"]
/apps/acme/components/compB/clientlibs
categories=["compB"]
Adobe recently released a good tutorial of more recent best practices around client library structure: https://helpx.adobe.com/experience-manager/kt/sites/using/getting-started-wknd-tutorial-develop/part3.html
Right now, I am using <%- assets.js() %> to include all the javascript files on all pages. So, it means all the functions will be initialized on all pages.
I am wondering how can I disable a javascript file on a specific web page? Or, if there is a way to include some of the javascript files on a specific web page but not all the javascript files.
The trouble with the auto-loading is that it's really hard to dictate the ordering of the source files in any meaningful way-- it really comes down to how you've structured the front-end.
In v0.8.x (the version you're working with, from what I can tell), you can use the config/assets.js to control the ordering of folders that get loaded in. This is not ideal, but is a decent workaround that my team used on several projects.
In v0.9, we've removed rigging/asset-rack in favor of tight integration Grunt, which has a large community and some really cool and well maintained packages for most types of asset bundling, etc.
In any case, here are the different approaches you can investigate for serving assets in the new version of Sails.js:
Treat it just like anything else
In your layout.ejs file, create <link /> and <script></script> tags to link in your css and javascript files like you would normally.
Use AMD (Require.JS)
I think lots of folks would say this is actually the best option. Require is a pretty powerful tool. And I'm mostly in agreement-- if you're working with front-end javascript that could be coming from anywhere, and is going to be extended by other developers who may be using a different framework, AMD is a great way to make sure you stay safe. If you're using Require, each js file is its own module, and declares its own dependencies, so asset dependency management becomes a thing of the past. Then in production mode, there are a couple of different options to compile and minify your CSS and JS. You can even dynamically load templates and CSS from JS with Require, which is pretty neat. AMD/RequireJS is a hands-down winner if you're interested in loading some or all of your assets asynchronously. It's also an all-client-side solution, which is pretty cool.
The only downside in my mind is the complexity. If you have control over the framework being used, you really shouldn't have to manually enter dependencies for each file-- it can figure that out itself (see https://github.com/balderdashy/mast/blob/2.x/lib/raise.js)
Use Grunt
When you make a new project with sails new foo in Sails v0.9, a file called Gruntfile.js is created. It has lots of stuff in it, a lot of which isn't being used by default. You can do almost anything with Grunt, but in particular, you'll want to look at how it's set up to copy files from assets/* to .tmp/public/.
sails new foo --linker (Sails v0.9 only)
Linker is a lot like what asset-rack/rigging does currently. It creates the same Gruntfile as #3 above, but utilizes more of the contents. It will auto-link files in the order you specify. Instead of view partials (e.g. <%= %>), the scriptlinker plugin allows you to customize the delimiters where js, css, and templates will be injected. By default, the Gruntfile is set up to use JST precompiled templates, but again, you can set it up however you like.
Hope that helps guys, and best of luck!
-Mike
PS- v0.9 is coming out very very soon, I've just been working through tests and issues to make sure we're 100% there. If you'd like to try it out, check out:
https://gist.github.com/mikermcneil/5930330
The lead for Sailsjs replied to this issue (though it was about selecting CSS files):
"For now, you can (a) bring in all styles all the time and make only the relevant ones apply (b) use another tool (like Grunt) to bundle assets like you would in a vanilla node.js project or (c) link the stylesheets manually (put them in your public folder)."
See: choosing assets sailsjs
Similar, more complex questions have been asked in the Google group:
https://groups.google.com/forum/#!topic/sailsjs/yt9EpJlfzXA
Considering the above, you may want to have a separate layout.ejs for each page. You can specify the layout.ejs you want for each page with
res.view({ layout: "different_layout" })
The layout.ejs would (a) not call assets.js() but have < script > for all the js files needed, or (b) call assets.js() to serve all the common js files in ./assets/js plus < script > to serve the page dependant ones residing elsewhere.
I have a wrapper around assets.js() that allows you to include all assets except for specified files. You can also use it to include only specific assets elsewhere. So you could load your common assets in layout and include other assets only on pages where they are required.
See my answer to How can I include javascript assets selectively in SailsJS?
I'm getting into Google Web Toolkit, and am a little confused about the Entry Points in GWT. Google's docs say:
If you have multiple EntryPoints (the interface that defines onModuleLoad()) within a module, they will all be called in sequence as soon as that module (and the outer document) is ready.
If you are loading multiple GWT modules within the same page, each module's EntryPoint will be called as soon as both that module and the outer document is ready. Two modules' EntryPoints are not guaranteed to fire at the same time, or in the same order in which their selection scripts were specified in the host page.
So does each page in your website need an Entry Point defined for it?
Do you only really NEED an entry point when you have javascript generated based on your Java classes?
Are you able to combine multiple auto-generated-js definitions into a single *.gwt.xml file?
EDIT: Link to quoted source: http://code.google.com/webtoolkit/doc/1.6/DevGuideOrganizingProjects.html
Thanks!
The most straightforward way to make a GWT app is to have a single page for the entire application, and a single top-level module (defined in a .gwt.xml file). Each module has a single EntryPoint class. Then all of your different "pages" are sub-sections of the same page, ideally using GWT's history mechanism to keep track of state changes that in a non-AJAX web app would be new pages. So if you set things up this way you'll need one EntryPoint for your whole app.
The bit of the docs that you quoted (link?) discuss what I think is an advanced use case, where you've got more than one module that you're loading on a single page.
there is one options, U can create maven project with sub projects, means U can create multi entrypoint,
each entry point have own html. See more details
I've a big GWT module which comprised of many java classes (& of course it's impossible to break it down into several modules).
My GWT application consists of some forms, but the users usually work only with a few of them, anyway they should be able to open any form as they need.
Now my problem its that gwt generates a big js file that will load each time, but most of its content may never use!
Is there any way to break the big js module file into several smaller files(for example, one file for each class) & gwt load them automatically as needed ?
You need Code Splitting - http://code.google.com/webtoolkit/doc/latest/DevGuideCodeSplitting.html
Conceptually, think of you code as a tree starting with your onModuleLoad() method. Every method call is a branch in this tree. Now GWT's code splitting is an axe that you can cut the tree at any branch. You can cut your tree anywhere and any number of times you want.
At startup, GWT will only load the part of the tree that contains onModuleLoad. Others will be loaded when you first access that part. In terms of code, other branches will be loaded ansynchronously, and you will be notified in a callback when it has finished loading.
Read the docs at the link I pasted above. It has enough material to get you started.