Is It Possible to Dynamically Generate JavaScript Reference Directives? - javascript

I'm working on a team of developers that keeps reference directives in various files for intellisense purposes. As you can imagine, it's impossible to maintain these files. As such, I'd like to know if there's a way to dynamically generate them. Any way. At all. No matter how kooky.
Here's a reference to the kind of thing I'm talking about: http://msdn.microsoft.com/en-us/library/vstudio/bb385682.aspx#ReferenceDirectives
I'm trying to do this on the fly. Say, to dynamically make some references for every js file in a folder. Whatever. Anything. I'll run with it once I get a good starting point.

Why not use T4 to read all the files in the current folder and below? (accounting for, if necessary scripts that are not actually included in the project but present in the file system).
Or even better and more likely related to what you are trying to do?
Use the nice centralized _references.js VS helper for scripts that are core in functionality to the others that you are editing.

Related

How to organize Vue-JS : Non Javascript way?

How to organize Vue-JS project [files and directory]: Non Javascript way?
Coming from a non-javascript background, I found Vue.js very intuitive and easy to use. My earlier experience in Javascript is with JQuery and vanilla javascript on the browser.
I created an application using Vue , Vue-components and vue router. Everything works fine.
My problem is, I have ended up writing a lot of code in a single index.html file of my project. This file contains over 10 templates that I have created and attached to different component in my app. I want to know that is there a non-javascript way to organize these templates in seperate files.
I see that there are options using webpack and browserify to modularize the project. But coming from non javascript background, I don't find them intuitive. I don't want to go node - npm way because that has its own learning curve and moreover it downloads a dozen of files and dependencies in my project which I don't understand. I am old school and more comfortable downloading the files and including them in the webpages.
So probably, you understand where I am going to. I need a solution where I could put my templates as separate files and read those files in the different components.
What I have tried :
Declaring the templates inside my components. But writing all that html inside the component is not that clean. It also, makes my JS file too huge. I am better in putting all data in the index.html instead.
Storing template as smaller chunk "homepage.html","about.html" and in my components, using $.get / $.load to read different components in ready function of the component. This works but I still have to fire an additional ajax call for each component which is not efficient.
Please refrain from suggesting the obvious node-npm [webpack and browserify] way. I know thats what is supported by Vue but this needs a learning curve and complete setup. Answer to this question would actually help other developers who hesitate going the node-npm way.
Please shout back if you need more clarifications to the question.
The options you've mentioned are your only real ones... the HTML of the template needs to be available when it's needed, so you either have to have it within your html file off the bat, or load it using AJAX or an in-browser loader like RequireJS (and this extension that allows it to load HTML https://github.com/requirejs/text).
In-file templates make sense for very small projects. As your project grows, you'll need to start using the tools that are built for this. NPM rocks and every JS package that you'll ever need can be included in your project in seconds.
I highly encourage you to try the Vue CLI
It does use node, npm, webpack and downloads dozens of files. Which you've you've explicitly asked for not to use, so let me clarify:
The Vue CLI takes care of the complexity and configures webpack for you.
You don't even have to know it's using webpack.
It's very developer friendly (it even has a built-in gui) and lowers the barrier to entry compared configuring a webpack config.
I hope you'll also find it "intuitive and easy to use".

Calling javascript

I am setting up a site that relies on a lot of javascript items and i want to try and set it up so the pages only call what they need.
there are different types of functionality so i am goig to break them into their own js files to make it easy to use.
For example if there is a drag and drop functionality then i will include the js file for drag and drop. within that will be a generic call using a class to turn on the functionality. This way it is only used on a page that uses drag and drop.
This gets more compacted when i have ajax calls some are on change events on a select for example while others are on a button.
I could separate these into different files for each type perhaps.
my concern is if a call needs more parameters to be passed or a different url then where does this code go to make the call?
I don't really want to have code within the page itself if i can help it.
I would love to hear your thoughts on how to best set this up
RequireJS might be your answer:
RequireJS is a JavaScript file and module loader. It is optimized for
in-browser use, but it can be used in other JavaScript environments,
like Rhino and Node. Using a modular script loader like RequireJS will
improve the speed and quality of your code.
This sounds similar to what I'm doing, so here what I've done:
One central file that contains functions that are used pretty much everywhere.
A folder containing files that are used in several places, but aren't worth including everywhere.
A folder containing files that are only used on one page.
Then, simply include the necessary <script> tags and go!
Hmm, have you looked at existing frameworks http://speckyboy.com/2010/05/17/15-javascript-web-ui-libraries-frameworks-and-libraries/?

jquery structure - one function per file

I am primarily a c# programmer. I have recently been getting into some jquery development. when I am working on applications in c#, I create a new class file (.cs) for every new class that I create.
How do people generally structure their jquery/javascript applications. I would like to reuse some functionality across pages, so do I put each function in it's own .js file? or is it best practice to group like functions into files? I can't see putting each on in it's own file as that would create many calls to import individual file into a page....
How are other people handling these types of situations.
Thanks for any thoughts.
EDIT - I should have mentioned that I am beginning to look at unit testing with QUnit and figured it would be good to have proper structure of my project to better facilitate unit testing.
If you DO put them all in separate files, you would want to have a build script that combines and minimizes them into a single one (or just a few) so you do not have 500 Javascript files to download to your browser.
I would suggest putting your common functionalities to a util.js file and then arrange your javascript codes according to functionality.
However it is not a good practice to have lots of js files included in every page, thus you might consider combinin the files into a single file and minifying that final js file. this way you would have optimized your final product while being able to unit test functionalities separately.
I generally keep all plugins into their perspective files but functions I create I tend to place into a "global.js" file that the entire site will pull from. Then I don't have to worry about pulling in specific files when a need a specific function. It will all be in the global.
Put it all in one file. Multiple HTTP requests are more expensive than big files, plus you're assured that the file containing the function you need is already loaded.

How do I compress tinymce and all plugins into a static file?

The documentation for tinymce notes that one can compress all the javascript and components (which I assume includes plugins) into a single file. They do note reasons why one might not want to that as well.
Compressing into a static file
It's also possible to simply concatenate the necessary components and some boilerplate code into a single .js file. However you will always have to recreate this file if you want to use other TinyMCE plugins, or you upgrade TinyMCE. You will also probably want to configure your webserver to compress javascript files.
But assuming one actually did want to do it, how does one actually go about it? Build.xml does does not provide an appropriate task it seems. At least when I tried it the plugins did not seem to be included when I loaded tiny_mce.js.
There are some really excellent command line tools for this, but you can also do this easily with just a text editor. The simplest way is to just open each file, copy the contents, and paste the contents into a single JS file ("everything-all-together.js", say). You'll need to make sure you paste the files into the single file in the same order you would've put the script tags into the HTML doc. Once you have all the files all together, you can use tools like JSXMin, YUI Compressor, or Google Closure. There are also some tools online that do this, like http://www.minifyjavascript.com/. You can paste in the uncompressed JS and copy back out the compressed JS. This makes the build process really cumbersome, but if you just need to do this once, that will get you there.
The best way to do this is to do it as a build step for the site. That means when you make changes to the JS files, you rebuild the compressed JS file to include the changes as well. This can be a cumbersome step if you're iterating quickly and changing files over and over again. You don't want to have to rebuild the compressed file with each save. You can solve this by setting up development and production modes of the site. When being loaded in development mode, the JS files aren't grouped together. When all the necessary changes are made, you'd rerun the build step to generate the single compressed JS file. To do the minification from the command line, you'd probably want to use Google Closure: https://developers.google.com/closure/compiler/. If you download the compiler app, you can do the following:
java -jar compiler.jar some-file.js some-other-file.js > compiled.js
That will generate a file called compiled.js that includes the contents of some-file.js and some-other-file.js in a minified format. You can specify as many files to compile as you need to. Actually, I'm selling Closure a bit short to say it's just minified. It's also extremely optimized code. Pretty much every site should be doing this to all of there JS all the time unless they're already doing something better.
I hope I'm getting you (and the tinymce docs) right, but this sounds a lot like combining JavaScript files on the server side. This means taking the contents of all of your JS files, putting them into one file and returning that one to the client.
Why would you do that? Well, this should be obvious, but.. you reduce the number of HTTP requests to your server, which is always a good thing.
How do you do that? There are many solutions out there for all server-side languages and frameworks, I suggest doing a Google search for "[your language] javascript minifier" or something similar.
Hope this helps.

How do you manage your Javascript files?

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.

Categories