14

We have been using jQuery 1.4.2 in our web application. Recently it was suggested that we upgrade to a newer version. So far we are thinking about upgrading to 1.9.1 as we need to support IE7 and IE8. Our application uses bunch of plugins e.g. fancybox, cookies, tipsy, jcarousel and bunch of others. Plus we have a lot of script files, probably around 50 files. and then some scripts embedded withing the files. I feel like this is going to be a disaster! Does anyone have any advice? We are not set on yet upgrading to 1.9.1. If I want I can convince the managers to upgrade to a different version. What is our safest bet? Please advise.

Thank you!

sayayin
  • 971
  • 5
  • 23
  • 36
  • I answered a similar (but more generic) question here: http://stackoverflow.com/a/15507363/357774 . Hope this helps! – Noyo Feb 17 '14 at 10:48

4 Answers4

12

Just look at the deprecated functions still in your code; the big ones to watch out for are .live() and .delegate() which have been replaced with .on(), .attr() for which .prop() is the replacement, and .browser(). I've been updating my code as new versions came along and it's been pretty easy (about 20K lines of js) so you shouldn't have any problems. Just start with the functions I mentioned and I think that'll solve most of the issues. Then, look at the Migrate plugin.

frenchie
  • 51,731
  • 109
  • 304
  • 510
  • 2
    Deprecated functions aren't an issue (while the usage should be converted, they "still work"); *removed* functions and features are the ones that really cause the issues. – user2246674 May 13 '13 at 03:56
  • Right, so I think the best way to start your upgrade project is with the most used functions first (delegate, live, attr, browser). Removed functions are going to be easy to spot because your code will break; just replace with the new functions. – frenchie May 13 '13 at 03:59
3

You can try to use jQuery Migrate plugins which is used to detect and restore APIs or features that have been deprecated in jQuery and removed as of version 1.9.

Eli
  • 14,779
  • 5
  • 59
  • 77
  • Also DO DO DO read the upgrade guide...http://jquery.com/upgrade-guide/1.9/ most of the plugins will probably still continue to work with the migrate plugin, otherwise update to the newer ones if there are any – Daniel Powell May 13 '13 at 03:39
  • GitHub is definitely your friend here. I am not familiar with the various migration tools. I suspect they do a decent job, but you will undoubtedly have to regression test. We have recently done the exact same upgrade from 1.4.1 and are still fixing little things here and there. – iGanja May 13 '13 at 03:42
  • Thanks for the reply Daniel! I'll check the Migrate plugin. Any other suggestions regarding which version should I upgrade to ? Is it any safer if we upgrade to a version different than 1.9.1? – sayayin May 13 '13 at 03:44
  • @iGanja So you upgraded from 1.4.1 to 1.9.1? We will definitely have our QA team do regression testing but how bad was it? I don't care fixing little stuff. I'm just dreading, hopefully it's not crazy amount of changes. – sayayin May 13 '13 at 03:47
  • @user812355 mostly little stuff, no major gotchas. For the most part jQuery has done a good job creating upgrade paths for the migration tools to follow. One thing I ran into recently was in an expression which evaluated against "" where jQuery now returns null. I believe it was in retrieving a data element value, but I could be wrong. Bottom-line, there will be little things like that that a migration tool will be hard pressed to pick up. Admittedly, it was bad design to start, but don't we all have a bit of that in our code base? :) – iGanja May 13 '13 at 04:01
  • @Eli: just saw your profile and reputation points: VERY impressive! – frenchie May 13 '13 at 04:04
0

In addition to frenchie's answer, if your application injects custom html attributes from code-behind, at the client-side those attributes can still only be read using attr() instead of the new prop().

According to my current understanding this is because name-value attribute additions to elements are only recognized as properties when they are either native to the DOM element type, or have been added using the same client-side jQuery prop() method.

Doing a similar jQuery upgrade for the first time, I found this thread about the differences between attr and the new prop a very interesting read: prop-vs-attr

Community
  • 1
  • 1
alpha pecap
  • 353
  • 3
  • 11
0
  1. Do not use offset option in position properties, e.g. code $element.position({my: 'center center', at: 'center center', offset: '5 -10'}) should be replaced with $element.position({my: 'center center', at: 'center+5 center-10'}).
  2. Do not use $element.bind(), $element.live(), $element.delegate() to assign event handler, use $element.on().
  3. Do not use browser sniffing with $.browser, try to use feature detection instead ($.support).
  4. Do not use deferred.isRejected(), deferred.isResolved(), use deferred.state() instead. Do not use deferred.pipe(), the deferred.then() method should be used instead.
  5. Do not use the $elements.size() method, use the $elements.length property instead. The .size() method is functionally equivalent to the .length property; however, the .length property is preferred because it does not have the overhead of a function call.
  6. Checkbox/radio state in a .trigger()ed "click" event now has the same state as in a user-initiated action.
  7. Changed naming convention for .data() keys, e.g., ui-dialog instead of dialog. (http://jqueryui.com/upgrade-guide/1.9/#changed-naming-convention-for-data-keys).
  8. Do not use $.ui.contains(), use $.contains() instead.
  9. Each widget instance already has unique identifier this.uuid and event namespace this.eventNamespace = "." + this.widgetName + this.uuid. Do not generate similar things manually.

Original upgrade guides and full list of changes:

Victor
  • 3,669
  • 3
  • 37
  • 42