Web Resource in Dynamics 365—Kendo UI destroyed by

Question

I have been using Kendo UI in web resources for Dynamics CRM for several years. My components require the use of ClientGlobalContext.js.aspx. In version 9.0.2.54 of Dynamics 365 online, I found that the newer version of ClientGlobalContext.js.aspx loads its own version of jQuery without checking to see if one is already present. It does this with a document.write statement, so this version of jQuery is always loaded after my code. I can work around this temporarily by using the JavaScript produced by this call with the jQuery load line commented out, since most of the instance/context specific information comes from the xhr request that is part of this page, but I am looking for a supported solution that will upgrade without issue and work across instances. These are the options that I’ve thought of, I am looking for suggestions as to which is the best and any additional guidance on that option. I’ve considered the following:

• Wait for ClientGlobalContext to be available then test for jQuery, use a document.write to include it if it is not there (won’t be with some versions, and they could stop including it at any time), once jQuery is available, load Kendo and proceed with my page. Again, I don’t have a way to change the Microsoft page and since there are asynchronous calls there, this may leave me with a timer loop—I can’t see how this isn’t ugly, but I may be missing something, and ugly or not it may be the best option.

• Convince Microsoft to check for jQuery before reloading it or to provide an alternate supported file without the jQuery. Since I haven’t seen anyone else expressing this frustration, I am not thinking this is likely. Not currently an idea on the Dynamics 365 forum, this was Telerik's suggestion, but is this a reasonable expectation?

• Move away from jQuery-based UI libraries since I will never control the whole page in Dynamics 365. Very painful, since I know and like the current library and the jQuery version has features I use that are not yet in the Angular version (Kendo Angular version would be the easiest migration even given that I would have to learn angular). I know this is subjective and not technical, so I can delete this option if it makes the question better, but it is an option and will be harder farther into the project.
• Another solution I haven’t thought of, keeping in mind that Dynamics web resources function completely client side. I am writing in TypeScript and using npm modules and Webpack if that is helpful

Answer 1

The use of jQuery is supported and recommended (in some circumstances).

We recommend that you use jQuery together with HTML web resources

I don't think its unreasonable to raise it with Microsoft to get some help. That said it may not be that helpful;

• It seems (in so far as I can tell) you are basically asking them to change some code - when you (or maybe Telerik) could change the code to achieve the same thing.
• Even if you did manage to convince them to make a change, it might not appear in the product for a long time (e.g. month's).

It would probably be quicker and save you time, to just implement a fix in your own code.

A solution you may want to consider (mentioned in the article above) is using jQuery.noConflict. Scott Durow presented a solution to a similar problem here.

1. Decide on a custom ‘namespace’ for your jQuery library. I am using ‘xrmjQuery’

2. On the end of your jquery.js script add the following line:

   /* jQuery script goes here */
   window.xrmjQuery = jQuery.noConflict(true);
   

3. Inside your jquery_ui.js script (notice the ‘-‘ has been changed to an underscore since CRM doesn’t allow them in web resource names), wrap the whole file in the following lines:

   (function ($,jQuery) {
     /*! jQuery UI Goes here */
   })(window.xrmjQuery,window.xrmjQuery);
   

4. Inside your JavaScript web resource that use jQuery and jQuery-UI, wrap your code in the following:

   (function($){
   // Your Javascript goes here and can reference $ as usual
   // e.g. var someField = $('#fieldName');
   })(window.xrmjQuery);
   

This technique is called encapsulation and namespacing of jQuery.

In regards to supportability and future upgrades. It's worth remembering what staying supported means.

... you can assume (with reasonable confidence) that your implementations will;

• Function correctly.
• Microsoft support will help when they don’t.
• Will continue working when an upgrade occurs (unless features are deprecated – this happens but you usually get several years’ notice).

The first article I linked above and this, frame the context in which jQuery is supported, but don't cover the specifics of this situation. I would suggest that any coded solution you implement will probably upgrade without issue. That said testing and validation is recommended by Microsoft before upgrading production.

Once your Sandbox instance has been updated ... test the update for your solutions and customizations.