I am currently started learning with node js, as I am working With Intel WebRTC SDK. If I want to make some modifications or add feature to the existing library, what do I have to do? Do I need to create modules or directly change in the files? If there is any other solution, please guide me. I am currently changing the codes of library itself, which I need to do again for a new version of their library. Please guide me through it.
It really depends upon what kind of changes you need to make and for you to get specific guidance, you will have to show the exact types of modifications you're trying to make (before/after code changes).
Additions to the library can likely be done without modifying the library itself by just adding new methods to the module or just making new methods available in your own module.
Replacement of existing methods with your own version can also likely be done without actually modifying the source by just replacing a given method with a reference to a new implementation in your own source file.
Fixing of bugs should likely be done via some sort of source control system (like GitHub) so that you can more easily apply patches you've already done to a new version of the source code.
Wholesale changing of existing code to do something different or work differently should probably be completely avoided because (as you have discovered), it creates a merging nightmare when you want to take a newer version of the original code. Instead, write a new function that does what you want and leave the current function in place. Then, your new function can live on, even after upgrading to a new version.
Related
I'm building a project in javascript, using paper.js in some features.
Most of my project is built in vanilla Javascript, just some minimum but important features are built with paper.js
The problem is that the library (.min library) is 200kb.
The normal library is 300kb, I was wondering if there is an automatic way to see which functions are being used in the main paper.js library, in order to delete the useless functions.
If there is no program or automatic way to do this, maybe some advice of how to do it manually, or which tools you recommend for me and my team in order to delete useless functions, then minify the file and run it smaller.
Thank you all guys, I did not added any specific code because I want this anwser to be global.
Greetings
You have to do it manually but it's not an easy (and certainly not quick) process. You'll have to find which functions you're using and then find whatever classes or functions those functions reference. You would probably have an easier time creating a new script then copy/pasting what you're using (and any referenced content) then running it with your script, log errors, and repeat.
When you're done there's many minify libraries and services online you can use to minify the new script.
I used the paper-core version and then minified.
I saved 140kb by doing this.
There's still no way to see useless functions in this library
I'm using a nice framework for Adobe ExtendScript called Extendables. I forked the project here: https://github.com/daluu/Extendables
A problem though is that in some ways using the framework is worse than not because the framework extends javascript objects with more functionality. And on an initial review of the code files, they seem rather interdependent such that it will take some work to uncouple the strict dependencies to make it optional/configurable to load only what you need and skip the rest in case of issues with particular features (i.e. you can just not load/include what you don't use - I don't think that's currently possible, although I might be mistaken). See the issue tracker in my project for details but in general the issues encountered using the full framework is failure of try/catch blocks and object iteration includes unintented properties.
For me, I'd just like at a minimum to make all functionality optional and just load the logger and Jasmine test framework as those are the only two feature/modules that I really use with Extendables. I don't care for the extensions to strings, files, object, arrays, etc.
As I'm a novice in javascript/ExtendScript, and this is not a trivially simple javascript framework, I could use suggestions on how to decouple the dependencies so that every module (baring it's dependendencies) can be optionally loaded, and where there are dependencies we can group into sets as in you can load or not load this set of features.
Sorry that I can't include code snippets as its too much to post, you can find it in my Github fork.
Not sure if this is best StackExchange site to post but starting here.
You should be able to extract the log module from this file:
https://github.com/daluu/Extendables/blob/master/core-packages/logging/lib/index.jsx
Try to use it like this (not tested):
#include "core-packages/logging/lib/index.jsx"
Log.debug("Log this");
You might need to adjust some things in there e.g. Folder.extendables does not exist in ExtendScript. Also exports.Log at the end will throw an error.
I am about to release a javascript library.
I would like to save the file as [library-name].1.0.0
Then as the library will evolve you will be able to download new versions, e.g.
[library-name].1.0.1.js
[library-name].1.0.2.js
[library-name].1.0.3.js
[library-name].1.1.0.js
[library-name].1.2.0.js
[library-name].2.0.0.js
My question is: is there any reason not to save the version in the name of the file?
I am using other 3rd party libraries and the ones for which I don't store the version I always have to figure out if I have to upgrade or not.
For instance, I use codemirror.js, and I always wonder if I am using the latest version.
If you are giving it for download, then its a good idea to have version number as part of file name. Also its a good idea to add version number along with the license info at the beginning of the file like jQuery does
Checkout - http://code.jquery.com/jquery-1.9.1.min.js
Only case where you shouldn't add version number is when you are referencing a script file throughout your website - because you don't want to change all references whenever you update the script.
I've never released any libraries myself, but putting the version number in the file name sounds like a fine idea to me.
On upgrading, I think not putting the version number in the file name is used for libraries where the author doesn't expect to introduce breaking changes in future versions, only bug fixes and additions that don't affect code already written against the library. This means that people who use the library but don't host it themselves (i.e. who point to the library on a public CDN) automatically point to the latest version, and thus get bug fixes without having to do anything.
But, as you say, for people who download the library and host it themselves, it does mean they have to open the library file to check the version number.
If you want to match what some other library publishers do, you might want to have a look at Semantic Versioning - it codifies the x.x.x version numbering system.
And if you're going to release your library through Github (which I believe is what the cool kids do these days), you might want to use Jonathan "Wolf" Rentzsch's system for doing semantic versioning there.
If you are using unit tests you can make sure that the V1 unit tests all work fine against V2 before releasing the library.
Smashing article on js unit testing
If I understood your question correctly, one reason not to include the version name is that if you're hosting the script users using that CDN-hosted file don't have to change any code when you upgrade.
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#.
We're developing a snippet that is embedded in 3rd party sites, and uses jQuery.
The snippet checks if the site already has jQuery loaded. If so, it uses that library, otherwise it loads our own copy (currently jQuery 1.4.4, we're migrating to the latest soon).
There are breaking changes in jQuery. One such change, for example is the change in semantics of attr(), and introduction of prop().
Are there some guidelines to working with jQuery in a way that will be as backward compatible as possible? Even when we migrate to latest, we still want to use an existing jQuery library if it exists instead of loading a new copy, to save load time and resources.
There are a few solutions to your problem
1. Use a subset of jQuery
Find the subset of jQuery that works upto a reasonable amount back and only use that subset.
Note that I recommend not using .attr at all, ever. since a) it's a minefield and b) it has different behaviour on different versions. You may find the sensible subset of jQuery is quite small. Good luck finding it.
2. Just use the latest version
Use the latest version of jQuery and tell your library users that they need to upgrade.
Seriously everyone should be using the latest version anyway, force them to upgrade.
3. Don't use jQuery
Don't have a dependency on jQuery.
Seriously, the less dependencies you have the better your code is
I prefer 3. as an optimum solution
Take a look at these guidelines:
http://www.davidtong.me/upgrading-jquery-from-1-4-x-to-1-6-1/
it's not the latest version available of jQuery, but it's enough hot.
Version 1.6.4 is a minor release
From version 1.6.4 to 1.7.x some new features and fixes were introduced but nothing seems is breaking code written for jQuery 1.6 version
This is one of my pet peeves with jQuery even though I love what it(jQuery) enables overall.
I wish the jQuery team would have addressed this early in development and created a version initialization method so you could "request" a specific version when building your library. Ideally, you'd have:
(function($, undefined) {
// your code
}(jQuery.noConflict(false, "1.4.4")));
Where jQuery.noConflict would accept a "key" for which API version you would like to use for this library. Each jQuery loaded would check automatically if a previous jQuery was loaded and create a new reference entry for it in an associative array. (check for jQuery/$, request jQuery.jquery to get version, request jQuery.loadedVersions to obtain the previous associations, and build a master list of all loaded APIs) If no valid library was found, it could default to the latest available version or just kick out an error.
Of course, this doesn't help you (unless you want to modify a subset of jQuery APIs and keep them up to date yourself... /yuck) but short of that, it's a bit of a crap shoot.
noConflict will return the jQuery API if $ is not the current jQuery API (thus, not overwriting the $) but it doesn't really handle API conflicts and you'll only ever get the last jQuery API loaded. It would simply ignore the first loaded API (because it's not === to the current code scope jQuery object) and return itself.