I'm working on a JavaScript library which needs to give the user the ability to run some code on load. Of course, I'm familiar with window.onload, and things like $(function() {}); with jQuery. But I don't want to be dependent on another library, and I want this particular function (along with the rest of the lib, of course) to be cross-browser.
So is there an accepted way of attaching to the onload function without overriding another library's load functionality (or having mine overwritten if they include another lib after mine)?
Expose an initialization/onload method and require it be called by the consumer on load. In other words, push the issue off to whomever is using the library and will likely have a convenient method like that offered by jQuery.
This is a solved problem but it isn't simple: the answer to "$(document).ready equivalent without jQuery" has the code of how jQuery does this.
More hits: javascript onload without jQuery
Related
Background
I am new to Node.JS but very experienced with JavaScript and jQuery. I have had no problem installing jQuery via npm install jquery, however, referencing plugins within the code is another challenge.
I have reviewed this similar StackOverflow question, and the solution appears to work but it seems to me that instantiating a "fake" browser window and injecting your jQuery plugin-based functions each time you need the plugin is possibly not the most efficient approach.
The specific plugin that is failing for me linq.js (yes, I am aware that js linq is available via npm but it is not the same as linq.js!).
NOTE: The plugin to which I am referring does not rely on any DOM elements; in my case, it simply runs JSON objects through various data functions. This is why I don't think I need to instantiate a window object.
Question
How do I properly import and use jQuery plugins in a Node.JS application?
You can't do this. JQuery manipulates DOM on the client-side, which means that it has no business on the server-side where NodeJs runs.
You don't.
You don't use jQuery on the server, ever. It has no place there, you don't have a DOM on the server and jQuery itself is a mediocre library to start with.
If you really want to use a "jQuery plugin" in node, you rewrite the plugin as a standalone module without a jQuery dependency.
As an aside, you also shouldn't need linq.js because it's an API you don't need, you already have array methods. Also your coding C# in JavaScript rather then learning JavaScript.
You also have all the array methods (map, filter, reduce, etc) so you simply do not need this. If you really want some of the sugar linq.js offers use underscore instead. (I personally recommend for ES5 over underscore)
Please use ECMAScript correctly rather then emulating C#.
are there any problems mixing my code with standard javascript and jquery? Will things conflict? Would I be unable to use standard javascript within jquery calls?
jQuery is framework for JavaScript
This means that if you use jQuery, you use JavaScript at the same time.
So no, there will be no issues if you put JavaScript inside the code that already uses jQuery, because you add nothing new / conflicting. Because you already are using JavaScript within your code.
jQuery does a good job of keeping itself compartmentalized within the jQuery (or $) object, so it plays well with existing JavaScript, and even with other JS APIs. The only thing I can think of that you should really look out for is if you use $ elsewhere (for example, if you use PrototypeJS). In that case, you can use jQuery's noConflict.
The only issues you will find is if your code overwrites the base prototypes. Otherwise your code will work fine with javascript libraries and frameworks including JQuery.
No there wont be any problems.
JQuery is just JavaScript written by other developers available to you through an API. Therefore, JavaScript inside JQuery is just JavaScript inside JavaScript.
I have had some problems with using onclick="javascript......" handlers at the same time as using jQuery handlers.
I would suggest if using jQuery to tend toward using it's handler system rather than the html versions.
some time ago, I was reading an article(a library built by some guy) about how his library can do
lazy loading of JS
resolve dependencies between JS
(typically encountered when trying
to "include" one js from another)
include files only once. thought
specified multiple times regardless
of how they are called (either
directly specifying it as file or
specifying it as one of the
dependencies)
I forgot to bookmark it, what a mistake. Can some one point me to something which can do the above. I know DOJO and YUI library have something like this, but I am looking for something which I can use with jQuery
I am probably looking for one more feature as well.
My site has asp.net user controls
(reusable server side code snippets)
which have some JS. Some of them get
fired right away, when the page is
loading which gives a bad user
experience. Yahoo performance
guidelines specify that JS should
be at the bottom of the page, but
this is not possible in my case as
this would require me to separate the
JS and the corresponding server side
control into different files and
maintenance would be difficult. I
definitely can put a jQuery
document.ready() in my user control
JS to make sure that it fires only
after the DOM has loaded, but I am
looking for a simpler solution.
Is there anyway that I could say "begin executing any JS only after DOM has loaded" in a global way than just writing "document.ready" within every user control ?
Microsoft Research proposed a new tool called DOLOTO. It can take care of rewriting & function splitting and enable the on-demand js loading possible.
From the site..
Doloto is a system that analyzes
application workloads and
automatically performs code splitting
of existing large Web 2.0
applications. After being processed by
Doloto, an application will initially
transfer only the portion of code
necessary for application
initialization. The rest of the
application's code is replaced by
short stubs -- their actual function
code is transferred lazily in the
background or, at the latest,
on-demand on first execution.
OK I guess I found the link
[>10 years ago; now they are all broken]
http://ajaxian.com/archives/usingjs-manage-javascript-dependencies
http://www.jondavis.net/techblog/post/2008/04/Javascript-Introducing-Using-%28js%29.aspx
I also found one more, for folks who are interested in lazy loading/dynamic js dependency resolution
http://jsload.net/
About the lazy-loading scripts thingy, most libraries just adds a <script> element inside the HTML pointing to the JS file to be "included" (assynchronously), while others like DOJO, fetches it's dependencies using a XMLHttpRequest and then eval's its contents, making it work synchronously.
I've used the YUI-Loader that is pretty much simple to use and you don't need the whole library to get it working. There are other libraries that gives you just this specific funcionality, but I think YUI's is the safe choice.
About your last question, I don't think there's something like that. You would have to do it yourself, but it would be similar to using document.ready.
i did in my framework a similar thing:
i created a include_js(file); that include the js file only if it isn't included reading and executing it with a synchronous ajax call.
Simply put that code in top of the page that needs dependencies and you're done!
Is it possible to have 2 different jQuery versions in the same document, and have them to not collide with each other?
For example if I create a bookmarklet and want to base the code on jQuery.
This bookmarklet is injected on some page that uses another version of jQuery then my code would overwrite the version used on the page.
Is it possible to avoid that?
Or are there some other libraries that provides this functionality
Or maybe I should rethink the whole thing.
Thanks for answers and pointers,
bob
jQuery comes with a way to avoid collisions. After you load the first version, you can assign it to a different variable.
var $j = jQuery.noConflict();
And then load your second jQuery version. The first one you load can be accessed with $j(...) while the second one can be accessed with $(...).
Alternatively, somebody made a little helper in an attempt to make it easier to switch between different versions.
Here is a way to detect is JQuery is already present: jQuery in widget
Work out the oldest version of JQuery your code will work with.. And refuse to work if the version present is too old. Only a few people will miss out, most sites using JQuery are pretty up to date..
Why not just have different versions of your javascript, for different versions of jquery, so, look at what version is on the page and get the appropriate code that will work on that version of jquery.
This would be safer, as anything else may be very fragile, as it sounds like you don't have control over the version of jquery that will be on the page.
For a while I had been running JavaScript component initialization by waiting for the "onload" event to fire and executing a main() of sorts. It seemed cleaner and you could be sure the ID state of your DOM was in order. But after some time of putting that through its paces I found that the component's initialization was choked off by any sort of resource hanging during the load (images, css, iframes, flash, etc.).
Now I have moved the initialization invocation to the end of the HTML document itself using inlined <script /> execution and found that it pushes the initialization before other external resources.
Now I wonder if there are some pitfalls that come with doing that instead of waiting for the "onload".
Which method are you using?
EDIT: Thanks. It seems each library has a specialized function for DOMContentLoaded/readyState implementation differences. I use prototype so this is what I needed.
For me, we use jquery, and its document ready state ensures that the DOM is loaded, but is not waiting for resources like you say. You can of course to this without a javascript framework, it does require a function you can create for example: document ready Now, for the most part putting script at the end of the page sure ensure the rest of the page is there, but making sure the DOM is ready is never a bad thing.
Jquery has $(document).ready()
The ideal point at which to run most scripts is when the document is ready, and not necessarily when it is "loaded".
See here
I use neither. Instead, I depend on YUI's onDomReady() (or onContentReady()/onAvailable()), because it handles the timing of initialization for me.
(Other JS libraries have similar methods for executing only once the page is fully loaded, as this is a common JS problem.)
That is not conform to any (X)HTML spec and I would be advised against that. It would put your site in to a quirks mode of the browser.
The correct way around the issue would be to use the DOMContentLoaded event, which isn't supported in all browsers. Hacks (eg polling doScroll() or using onreadystatechange) exist, so libraries are able to provide this functionality across browsers.
But there are still problems with DOMContentLoaded and chunked transfers which haven't been addressed by popular JavaScript frameworks.
Here's my take on the issue.