This blog is part of the blog series SharePoint JavaScript Context Development
- Part 1 – SP.Init.js and SP.ScriptUtility
- Part 2 – SP.ScriptHelpers
- Part 3 – Minimal Download Strategy
- Part 4 – The way of the Async Download Manager
- Part 5 – JavaScript Framework Governance (This post)
- Part 6 – jQuery vs SharePoint
Parts 3&4 are linked. Please read in order.
What if I told you that you did not need to include jQuery in everything you did? What if I told you that SharePoint has all the same functionality and that you only need jQuery if you are using a framework that requires it? Well, it’s true. Unless you are using SPServices, AngularJS, Bootstrap and the like you do not need jQuery.
However, this goes two ways, how do you know that the code, which you are using in SharePoint JavaScript libraries, won’t be scrubbed. You are putting your support contract time in Microsoft’s hands. If they update a piece of code, your entire intranet could come crashing down on you.
Clear governance decisions
First, we talk patch governance. If there is a new patch in SharePoint, it has to be tested against all customizations. Governance is imperative to running a SharePoint farm, and if you are in charge of this process and don’t do it, expect to be the one blamed when things do and will go wrong.
We can also look at the impact of loading additional frameworks into SharePoint that are already covered with out-of-the-box code. What are the additional page load times? Will the framework work with MDS? Will this slow our pages down and frustrate our users? The answer to this is no, it will not slow things down too much if you modify external libraries to work properly with SharePoint. However, this is the problem; you have to edit all external libraries in one form or another so that they do not conflict with out-of-the-box code. Testing this patch process in itself is a mind-boggling job, testing the framework with the entirety of SharePoint. Historically, jQuery and other external libraries have been used a lot with SharePoint, with minimal bugs. We know it sometimes conflicts with MDS, disabling it and that some pages use a $ symbol in the code so that we should use no conflict mode. However, what about future patches? Do we have in our governance plan to check jQuery at each patch? I would say not if we can help it and use it sparingly where needed, and only where it is needed.
Maybe many people disagree with me here. However, this is the thing almost all JavaScript developers will tell you what I have stated in the above paragraph, even the creators of jQuery say the same thing. We have 2 sides of the coin, use out-of-the-box methods and test their usages with every patch from Microsoft, or test our code and external libraries with every patch. Limiting external libraries to where required. If you look at it, the problem is the same on both sides of the coin we need to test our code with every patch. Both introduce risk from Microsoft and patching; this has happened before in more cases from external libraries than internal changes.
SharePoint does contain bugs
Another point I need to talk about is the bugs in SharePoint code. We know they exist, we often work around them and write small patches in our code. The JavaScript framework inside SharePoint is no exception. I have read blog posts of people coming across these issues and patching them. If done correctly in JavaScript, however, these patches can be graceful and reduce the risk of code breakage to a near non-existent level.
Example code to help with this process
So since this is a developer blog, I will give you a little bit of code that we JavaScript developers like to call a Monkey Patch or a Duck Punch.
SP.CamlQuery._getNameOld = SP.CamlQuery.getName;
SP.CamlQuery.getName = function(same, params) {
// Broken method base 64 encoded
// IE10+, FF, Chrome Only
var methodHash = "ZnVuY3Rpb24gKCl7cmV0dXJuIHR5cGVvZiB0aGlzLl9fdHlwZU5hbWU9PT0idW5kZWZpbmVkIj8iIjp0aGlzLl9fdHlwZU5hbWV9";
// We have btoa, we haven't already done this, and we can log out to the console
// You should refactor this bit to a method passing in the old method hash
if(typeof btoa != "undefined" && typeof SP.CamlQuery._getNameOldHash == "undefined" && typeof console != "undefined" && typeof console.log != undefined)
{
SP.CamlQuery._getNameOldHash = btao(SP.CamlQuery._getNameOld + "");
if(SP.CamlQuery._getNameOldHash != methodHash)
{
console.log("Method updated SP.CamlQuery.getName new hash [" + SP.CamlQuery._getNameOldHash + "]")
}
}
// Our patched code either running before then calling the original method
// or after calling our original method
// or replacing it all
// the original method now being able to be called with SP.CamlQuery._getNameOld()
};
What I am doing here is using a modern browser to expedite the checking of any patches made by Microsoft so that we can update our customizations. We can use the same method of checking either by running a one-time piece of code we paste into the console that checks our code or by having it built into our custom code.
Conclusion and Further Reading
So we have seen that it is not always a good idea to include external frameworks. However, we have also seen that with proper governance in place patch management need not be a big thing.
If you need any more information on patching SharePoint I recommend you try out these blog posts:
- Todd Klindt’s blog “Hey! Should I install this SharePoint patch?” and the Bugs, Notes & Regressions of the CU/PU/SP.
- Andy Talbot – SharePoint Accumulative Updates… Don’t Introduce a Gremlin!
- Matthias Einig – SharePoint Health check Part 1 – Auditing the SharePoint Farm
- MSDN Blogs – Farm Patching Explained – High Availability SharePoint
Coming Next
So what’s next for the series? Well, I said we do not need jQuery, so the next blog post will be me proving this point and showing you EVERY method in jQuery with its out-of-the-box SharePoint equivalent. I can tell you now already that most of the time the SharePoint versions are way cooler.
Stay tuned!
