4

I have been working on SharePoint 2013 recently, and noticed that under variation sites, SharePoint 2013 has a java script file that defines a global variable called $ which overwrites the jquery $ and brakes all my code. Other solutions say to wrap it with a self executing anonymous function passing in jQuery.noConflict and making the parameter name $.

http://chuvash.eu/2012/06/01/in-cmssitemanager-js-conflicts-with-in-jquery/

http://blah.winsmarts.com/2013-5-SharePoint_2013_-JavaScript-and-amp%3B_jQuery_big_booboo_to_watch_out_for.aspx

http://api.jquery.com/jQuery.noConflict/

I was just wondering, since SP2013 has been out for years now and I never heard of this problem before, is this really a big problem or did someone find a fix for it?

I don't want to have to update all my jquery uses with with code since there is a lot of them.

Improve this question
5
  • 1
    There is an actual collision on the global $ object between jQuery and SharePoint's out of the box JavaScript. They even perform similar functions (like selecting elements) but the behavior is different. Usually this isn't an issue if you wrap your code in one of the SP.SOD methods since SharePoint's built-in code has already run by the time jQuery gets loaded and called. The SharePoint code has a whole interface I'll let someone else describe in an answer though
    – John-M
    Jan 14, 2016 at 15:33
  • Can you give an example by what you bean by wrapping code in SOD?
    – omega
    Jan 14, 2016 at 15:58
  • SP.SOD.executeOrDelayUntilScriptLoaded(myAwesomeFunctionDefinedBelow, "sp.js") is one example, take a look at the MSDN SP.SOD Methods Page for more info
    – John-M
    Jan 14, 2016 at 18:26
  • If I do that, at what point do I import jquery? And how? Should I requireJS it in my awesome function?
    – omega
    Jan 14, 2016 at 18:49
  • Thanks so much for sharing this. I spent a day trying to figure out what was wrong on a wiki page. And I can't believe that they have made a $ function! Unbelievable. At the moment I have experienced this only on Wiki pages.
    – ova
    Jul 28, 2016 at 11:07

2 Answers 2

Reset to default
3

On average there are no issues, that is why you won't see many issues posted.

Once you get deeper under the hood you might experience problems, but it all depends on your coding style. and no I do not have clear examples where I burned my fingers.
noConflict is an easy fix.

But lets face it, jQuery is something from the height of the Browser Wars.

Now (january 12th) Microsoft officially ended IE9 support why would we developers support below IE10 browser versions?

Modern ES5 (we're already on ES6 now) JavaScript can do everything jQuery does (and faster)

SOD was already mentioned, be sure to also fully understand https://www.spcaf.com/blog/sp-context-dev-part-6-jquery-vs-sharepoint/ (and the previous 5 blogs)

My advice: do not waste time learning (more) jQuery. Learn JavaScript

Improve this answer
11
  • Isn't the point of jquery, to simplify the code of javascript? Sure javascipt runs faster but if it means I can write much less code, then wouldn't I still use jquery? Also It has to run on IE11.
    – omega
    Jan 14, 2016 at 18:55
  • No the point of jQuery was to write code that all browsers support. The eco system evolved to a number of uncountable plugins that made life easier. Most of these plugins do not support modern 2.x jQuery. That is why I encounter (SharePoint) projects where every Add-in loads its own version of jQuery (oh what a joy for Mobile users). If you want to write less code and be ready for the future learn TypeScript (which transpiles to JavaScript)
    – Danny '365CSI' Engelman
    Jan 14, 2016 at 19:01
  • So to future proof SharePoint environment, are you saying to completely remove jquery, and use the build in sharepoint mquery described in the article?
    – omega
    Jan 14, 2016 at 19:04
  • Yes, learn the normal JavaScript way of doing things, learn what mQuery is and may do for you. You don't have to ban jQuery, just understand its not required. I only use jQuery because I am lazy and use $.ajax() .. but even that can be done without jQuery and with less code, see sharepoint.stackexchange.com/questions/157139/…
    – Danny '365CSI' Engelman
    Jan 14, 2016 at 19:11
  • I'm still not sure about whether to switch to mquery instead of jquery. Because as sharepoint evolves and we migrate content, there is a possibility of mquery changing which would break code, or being completely dropped (an example is Microsoft dropping Full text query in SP2013). But with jquery, as long as all the code works with jquery, you can just keep using that file locally. So it would seem like jquery is more stable in long term?
    – omega
    Jan 14, 2016 at 20:22
2

Using noConflict should already be a solution.

Consider also the possibility to don't use jQuery, where SP built-in mQuery could be sufficient, as very well highlighted by this article:
SharePoint JavaScript Context Development Part 6 – jQuery vs SharePoint

I really suggest you to read the whole article series because it's very interesting, and it also discusses noConflict option in part 5.

Another option could be approaching an AMD style to organize your code where, for instance using RequireJS, you could export and make available jQuery's functions, to your custom code that will use it, using the name most convenient to you.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.