Im developing a ember.js based app.
On some "sites" (templates) I want to load a specific js-game, so I have to include extra tags like <script src="game.js"></script>. But since handlebar-templates are defined by <script>-Tags itself, its not possible to simply put my dependencies within a template directly.
How can I include js-files on some individual sites only?
Including files in an Ember.js application is a bit more complex than in a regular website.
If you do not use ember-cli, then you could either include your all your JavaScript files directly in your index.html (one by one) or (and this is better) you could also bundle all your game JavaScript files into a single file (called games.js for instance) and include that single file in your index.html. You can bundle JavaScript files using tools such as grunt or brunch or broccoli.
Now if you do use ember-cli (which I recommend), then you could simply list your files in your Brocfile.js (see documentation here). Learning ember-cli might take a little bit of extra time but it will really help you in the future :)
Good luck!
Ok I found an possibility to solve that problem:
Like described in the handlebars.js-FAQ here (5.), I have to use some kind of a "Hack" to avoid parsing errors. Just need to add an empty command {{!}} into the word "script" like <scr{{!}}ipt src=...>...</scr{{!}}ipt.
That works for me.
Also, as kpdecker says here, it is better to use precompiled templates than defining them inline.
You can try to insert the necessary scripts from didInsertElement hook of the corresponding view. And, if so, in order to avoid duplicates, remove that scripts in willDestroyElement hook of the same view.
Related
I have developed a custom Joomla template, and I need to add a piece of custom javascript to a Joomla core module (mod_articles_news), without a plugin, if possible (this should be so simple that I don't think I want to use a third party plugin for that). And async, if possible.
I have been searching thoroughly, but haven't found the perfect solution. Either they want me to install a plugin or the solution refers to a custom written module (suggesting to add JS before installation of module) while I am dealing with a core module (Articles Newsflash) that is already installed per definition. (The reason I need to use JS is to make a conditional design change, presently not possible with CSS).
I have been following the steps outlined here, but to no avail. Namely, I added the following code into the module's template folder (mod_articles_news/tmpl/my-template-name.php)
<?php
JHtml::script(Juri::base() . 'templates/my-template-name/js/myScript.js');
?>
(Of course, I have added the myScript.js file into the above location).
When checking it live, nothing happens, the browser is not loading my JavaScript at all (the script itself is tested and it works).
Please help me what I am missing here. Thank you in advance!
If you want to do customization you should use a Joomla! template for this. A template determines the basic HTML including the necessary CSS/JS for your site. In addition it can contain overrides for modules and components so you can do even more customization without touching any of the original code.
What you want to do sounds like a simple customization. Just add any CSS/JS which is necessary to achieve your task to the template.
You could try
<?php
JHTML::script('templates/my-template-name/js/myScript.js');
?>
alternatively, is there any reason you can't add it via your custom template, as suggested by Sven Bluege
TL,DR: How to load css and javascript files independent of Meteor assumptions about alphabetical order (which is far from how it works in practice.)
Stackoverflow tells me this question might be subjective but I hope not.
Meteor loads files based on alphabetical order (and other rules.)
So to force it to load the CSS and JS files in the order I wanted, I had to start the fiels with numbers that indicate the load order. If I have jquery.js and bootstrap.js, Meteor will load bootstrap.js before jquery.js. But bootstrap depends on jquery so jquery must be loaded first.
In order to solve this, the options are:
1. Put the files in the public directory and manually load them. But this didn't work as Meteor appears to be sending the files with text/html MIME type.
2. Create a Meteor package and specify the load order from there. I find this like hitting a fly with a hammer just for loading CSS and Javascript.
3. Put a number before every file. In the previous example, to load jquery before bootstrap, rename the fiels to 1.jquery.js and 2.bootstrap.js This works and is tedious but at least I get to load the files the way I want them to.
I am new to Meteor so I am wondering if there are recommended best practices concerning this. I was thinking of using AMD for javascript but that's limited to javascript.
Its an interesting question and this is probably one of the pitfalls of making a Meteor app.
You've mentioned all of the usable solutions such as creating an explicit package or renaming the files.
The best way I would think is to use the atmosphere packages. For example if you add bootstrap, jquery is a dependency of it so it will always load first. Most js libraries that involve load order are typically on atmosphere.
The other best way if there's no atmosphere package, though i'm not sure I would say is tedious is to put a number in front of the js file to indicate load order.
One thing is when you use the /public folder the files map to /, so you can load the js file yourself manually in the order you would want (in the root html file using /public. Meteor returns the text/html MIME type as its version of a 404 file not found error. This method is a bit troublesome though because the files are seperated in production and can cause trouble if one or the other dont load.
I'm developing a modular framework in javascript and am looking for a way to automatically optimize/combine a set of javascripts as a precompile step.
I'm already using grunt so a grunt-task would probably make sense.
The framework consists of modules in their own files (as in the rectangular 'widgets' we're all used to) that in turn may require other javascripts.
All this is wired using Require.js which works great.
However, I came across the following constraint when trying to use r.js which comes with require.js
The optimizer will only combine modules that are specified in arrays
of string literals that are passed to top-level require and define
calls, or the require('name') string literal calls in a simplified
CommonJS wrapping. So, it will not find modules that are loaded via a
variable name:
The thing is: modules may inherit from eachother, and even composition of other modules is possible through configuration (with the technical need to load the referenced modules sitting in their own js-files).
This doesn't work with the mentioned constraint above.
I'm sure I could cook up something myself with enough time, but perhaps someone has already done something like this. (r.js but more flexible).
A doable solution imho would be to:
let the precompile-task run the page for which the js needs to be optimized once (but on the server in Node instead of on the client, the framework is able to do this)
and somehow track all the libraries loaded in by require.js
read out require.js somehow and voila there's your list of js-scripts to load.
hand this to r.js through the include it provides and r.js handles it from there.
there are more pagetypes btw. But in r.js it seems possible to define common libraries, so they don't get included in the per-page-optimized file.
Does this sound plausible? Anyone ever tried something like this?
This seems overly complicated. In r.js build there is option onBuildRead, where you can modify source so that it would be acceptable to optimizer. Also you may look into Internal API: onResourceLoad. Where you can capture all loaded dependencies and then make a call to do custom build.
To load your page you would have to use PhantomJS, so that it acts as a browser and executes JS. Then signal node to produce custom build for that page. But then need to switch resources on that page to use custom build. I guess you can make it configurable and do that when in production.
It does sound that it is possible, not sure if it is feasible.
Coming from a C# background where every class is (best practices) stored in its own individual file, it makes development quite clean. I've never written anything complex in Javascript in the past, but I am starting to learn HTML 5 and I want to write a complex game using the HTML 5 canvas.
Putting all of my functions and code into a single .js file seems very messy. Is there a way to split it up, or a tool/IDE that lets you develop using separate files and compile them into a single one for deployment?
I guess I am looking for some best practice advice. Questions like this generally seem to get closed, so here are my specific questions to adhere to the SO FAQ that demands practical, answerable questions:
Does complex JS development usually involve all the code being in a single JS file? Eg. you're writing space invaders, do you just have spaceinvaders.js or do you have ships.js, logic.js etc.
Is it possible to split up your JS (whether using multiple script tags or pre-compiling to a single JS file) or to just put it all in a single file?
What's the industry standard? Does the HTML 5 spec make any recommendations?
There two possible ways.
Personally, I would use a build tool to simplify working with multiple files.
Using a build tool
Grunt
My favourite tool to keep up with complex js applications is grunt. With grunt you can develop in as many files as you want and use its plugins watch and concat to automatically concat them on save. You can do a lot more but this is the basic use case which may be helpful for you.
Grunt requires nodejs and takes some time to setup. But once you are ready with your Gruntfile setup it really speeds up your development process.
To make your project ready for production use you can also minify your scripts with some configuration and a single command.
A lot of the major javascript libraries are using grunt, easily recognizable based on their Gruntfile: jQuery, AngularJS, Twitter Bootstrap etc.
Grunt is also part of the development toolset yeoman.
Brunch
Brunch is another build tool which allows you to do similar things like grunt does.
Loading only the needed files
If you are developing a huge single page application and are concerned about the startup time of your application, one single file may not be the best solution. In this case you can use a javascript module loader.
Require.js
Therefor require.js is a goot fit. It allows you to only load the actual needed files on the current page. Though setting up require.js is a bit more work than setting up grunt.
Of course you can use more than one javascript file. How else would libraries like jQuery or Knockout function?
One thing to keep in mind, though, is that one of the things you want to do to keep your pages feeling snappy is to reduce the total number of http requests per page load. Adding a bunch of javascript files that are loaded separately causes an additonal request for each extra file. Therefore, you might want to experiment with a system for your build that stitches your javascript files together into a single item that you can use at deployment. There are a number of solutions out there that will do this for you in an automated way.
you could consider using requirejs - a very nice libray to split your javascript to modules.
it also provide a tool that you can "combine" all modules to a single file.
You can use as many javascript files as you want. Just add a link to them in your html code:
<body style="background-color: black" onload="main();" >
<!-- Your HTML body contents -->
<!-- Your scripts (here, I used HTML5 BoilerPlate to setup, and the links to jquery are provided) -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.9.1.min.js"><\/script>')</script>
<script src="js/main.js"></script>
</body>
Then you can hookup your main.js to listen for the main() function call:
function main() {
//here you can do your basic setup or delegate the control of the app to a different .js file.
}
or the jQuery document ready callback:
$(document).ready(function() {
//here is a good spot to hookup other jQuery listeners
});
Nowadays, we have tons of Javascript libraries per page in addition to the Javascript files we write ourselves. How do you manage them all? How do you minify them in an organized way?
Organization
All of my scripts are maintained in a directory structure that I follow whenever I work on a site. The directory structure normally goes something like this:
+--root
|--javascript
|--lib
|--prototype.js
|--scriptaculous
|--scriptaculous.js
|--effects.js
|--..
|--myOwnScript.js
|--myOwnScript2.js
If, on the off chance, that I'm working on a team uses an inordinate amount of scripts, then I'll normally create a custom directory in which we'll organize scripts by relationship. This doesn't happen terribly often, though.
Compression
Though there are a lot of different compressors and obfuscators out there, I always come back to YUI Compressor.
Inclusion
Unless a site is using some form of a master page, CMS, or something that dictates what can be included on a page beyond my control, I only included the scripts necessarily for the given page just for the small performance sake. If a page doesn't require any script, there will be no script inclusions on that page.
First of all, YUI Compressor.
Keeping them organized is up to you, but most groups that I've seen have just come up with a convention that makes sense for their application.
It's generally optimal to package up your files in such a way that you have a small handful of packages which can be included on any given page for optimal caching.
You also might consider dividing your javascript up into segments that are easy to share across the team.
Cal Henderson (of Flickr fame) wrote Serving JavaScript Fast a while back. It covers asset delivery, not organization, but it might answer some of your questions.
Here are the bullet points:
Yes, you ought to concatenate JavaScript files in production to minimize the number of HTTP requests.
BUT you might not want to concatenate into one giant file; you might want to break it into logical pieces and spread the transfer cost over several pages.
gzip compression is good, but you shouldn't serve gzipped assets to IE <= 6, so you might also want to minify/compress your JavaScript.
I'll add a few bullet points of my own:
You ought to come up with a solution that works for both development and production. In development mode, it should pull in extra JavaScript files on demand; in production it should bundle everything ahead of time. Switching from one behavior to the other should be as easy as setting a flag.
Rails 2.0 handles all this through an asset cache; other web app frameworks might offer similar solutions.
As another answer suggests, placing third-party libraries in a lib directory is a good start. You can also divide your own JS files into sub-directories if it makes sense. Ideally, you'll be able to arrange them in such a way that the files in a given sub-directory can be concatenated into one file.
I will have a folder for all javascript, and a sub folder of that for 3rd party/shared libraries, and sub folders for each component of the site to keep everything organized.
For example:
/
+--/javascript/
+-- lib/
+-- admin/
+-- compnent1/
+-- compnent2/
Then run everything through a minifier/obfuscator during the build process.
I'v been using this lately:
http://code.google.com/apis/ajaxlibs/
And then have a "jscripts" folder where I keep my custom code.
In my last project, we had three kinds of JS files, all of them inside a JS folder.
Library code. A bunch of functions used on most all of the pages, so they were put together in one or a few files.
Classes. These had their own files, organized in folders as needed, but not necessarily so.
Ad hoc JS. Code that was specific to that page. These were saved in files that had the same name as the JSP pages they were supposed to run in.
The biggest effort was in having most of the code on the first two kinds, having custom code only know what to call, and when.
This might be a different approach than what you're looking for, but I've been playing around with the idea of JavaScript templates in our blog engine. In a nutshell, you assign a Javascript template to a page id using the database and it will dynamically include and minify all the JavaScript files associated with that template and create a file in a server-side cache with the template id as a file name. When a page is loaded, it calls the template file which first checks if the file exists in the cache and loads it if it does. If it doesn't exist, it creates it on the fly and includes it. I also use the template file to gzip the conglomerate JavaScript file.
The template idea would work well for site-wide JavaScript (like a JavaScript library), but it doesn't cover page-specific JavaScript. However, you can still use the same approach for page specific JavaScript by including a second file that does the same as above.