We Keep Coding

Web Resource in Dynamics 365—Kendo UI destroyed by jQuery loaded by ClientGlobalContext.js.aspx

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

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.
Decide on a custom ‘namespace’ for your jQuery library. I am using ‘xrmjQuery’
On the end of your jquery.js script add the following line:
/* jQuery script goes here */
window.xrmjQuery = jQuery.noConflict(true);
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);
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.

write incremental number inside a file with grunt

i'm trying to figure out a way to make grunt write an incremental number or a hash on a file.
i have a file named config.yml which contains this:
version: 0.0.0
every time i change some files that i can specify somewhere (say all the .js and .css files), grunt should increment that number in some way.
i've seen some cache busting plugin but it's not what i am looking for as i don't want to have something like config.987234892374982.yml or config.yml?v=1.0.0 for example. i'm looking for a way to have grunt to find that number in that file, change it in a way that makes sense (incrementally ideally, or a random hash) and then save the file.
can you help in some way? thanks a lot!

I would seriously recommend against automatic version bumping for anything beyond the build number.
A version number is more than just an indication of how many times your product has been built. In essence, a version number is a semantic promise to your end user concerning compatibility with earlier releases. Node.js and npm and other systems using versioning are built around the core concept that X.Y.Z version numbers contain the following logic:
Software that doesn't have the same X version will have severely breaking changes that require those upgrading (or downgrading) to completely redesign the logic of how they use the software, and in some cases they even have to find alternatives because what they're doing right now doesn't work anymore.
Software within the same X version can relatively easily be swapped out without having to make sweeping changes to your own site or product.
Software within the same Y version can be swapped out without having to change any code, because it's supposed to be only bug fixes and security fixes. Only code that works around the things fixed needs to be changed.
Software within the same Z version has the exact same source, so if you have 2 copies of the same Z.Y.Z version, they can be used interchangeably.
This is the core contract that NPM and other package managers ask all their content providers to adhere to. In fact, it has already been shown that in some cases where content providers don't adhere to this versioning system, consumers of this content who assume semantic versioning apply have found their build to fail. Many consumers assume that if version 3.5.N works, that any version within the 3.5.X family will be interchangeable, and make use of that assumption by automatically building their code with the most recent version of the 3.5.X family.
Because of this, it's not a good idea to automatically bump versions beyond the build number. Bumping the patch version should only be done when you actually release a new version to the public, not after every build. Bumping the minor version should only be done when you have added new features to the product, but without the need for major changes to software that uses your product. Bumping the major version should only be done when you make drastic and destructive changes to your API, like moving and/or removing functions, function parameters, objects or attributes.

Any 3rd party packages used by Angular 4 in run-time (except RxJS)?

Angular 4 uses some RxJS types in its public API as well as depends on RxJS internally.
Thinking further on this, it might be good to know if Angular uses other packages for parts of its run-time functionality, so we could use them as well. It might prevent us from introducing extra dependencies for the app by re-using them from Angular.
But looking into node_modules, every Angular 4 app contains a massive amount of packages. Obviously, most of them doesn't get included in the run-time app bundle. At the same time, some of them (like lodash) could be very desirable to use in your Angular app as well.
So, is Angular based on any other packages except RxJS and which of them could be used in our own code similar to RxJS?

Angular is pretty buffed up, meaning it already comes with predefined strategy on how you should accomplish things. I believe it's built on RxJS so you won't be able to get rid of it.
But you don't really have to use it. When you pack your app for production it will not include all of the node_modules packages, only the ones that were used.
If you want to use a JS library that's a lot less heavyweight, and comes less structured, look into react.js and vue.js

Although RxJS is certainly a big player in Angular's dependency pool, it's certainly not the only one, and not even the only one you'll need to depend on to use Angular.
Zone.js, for instance, is another key component in Angular's architecture that you'll need to depend on to use it. Although both libraries are used extensively in Angular, you are by no means mandated to use them – that being said, you'll get a lot more out of the framework if you understand Observables and Zones.
Other things you'll need to depend on are easily inspected in Angular-CLI's polyfills.js file; things like core.js that shim up Angular's ability to run on lower-common-denominator browsers (cough, IE). There's also multiple #angular/*-scoped modules you'll need for other pieces of the framework, such as forms and http.
My recommendation? Boot up a CLI project and see what ends up in the dependencies section of your package.json. RxJS and Zone.js are the big contenders, but you may be surprised by other names on the list.

Working with Angular 2 [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Our team is way too excited with the alpha release of Angular 2 and we're just eagerly waiting for it's stable release and getting started with it.
But during the ng-conf 2015 on Angular 2 by Misko, we came across following things which made me confused
TypeScript! Is it really needed to use typescript to gain better performance instead of writing plain simple JS code we've been doing all along. We've came across a few comments that says typescript helps in better performance.
ES6 features. Since angular 2 will be using a lot of es6 features, would that mean we'll have to wait for all the browsers support at least those features needed by angular 2 before we can kick start with it on our production applications.
Web components. Since angular 2 provides the facility to create web components and I've came across a few blogs on creating your own (using polymer), how hard is it gonna be for our team to create them? Or is it better if we just stick to old directives creation thing ?
Performance. I've seen this video of Angular + React which provides a good comparison of angular vs angular + react vs angular 2. But I'm not sure if that's the case that angular 2 is really fast all the way or if we can go ahead with building angular + react app to avoid waiting for angular 2 to stabilize or the browsers to have support for es6 features that angular uses.
I'm not sure I've structured my question well, but above are my concerns before I start learning angular 2 because with their demonstration of angular 2 + typescript seemed like it's gonna involve a lot of earning curve for me and my team.
I'll really appreciate if someone can clarify on the above listed concerns I have.
Thanks.

TypeScript! Is it really needed to use typescript to gain better performance instead of writing plain simple JS code we've been doing all along. We've came across a few comments that says typescript helps in better performance.
TypeScript is about static analysis for better type-safety. It also has a pretty nice suite of editor tools (e.g. WebStorm). You don't need it for performance. It's more a tool for helping you author. Personally though, I love it.
I've begun migrating some of my existing open-source libraries to TypeScript because it's so much easier to work with. For example, check out Task Runner before and after.
ES6 features. Since angular 2 will be using a lot of es6 features, would that mean we'll have to wait for all the browsers support at least those features needed by angular 2 before we can kick start with it on our production applications.
A lot of ES6 features can be polyfilled. Check out https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills.
Web components. Since angular 2 provides the facility to create web components and I've came across a few blogs on creating your own (using polymer), how hard is it gonna be for our team to create them? Or is it better if we just stick to old directives creation thing ?
Web components are also polyfillable (see here). In this case, I'd suggest you follow the Angular team's recommended practices for creating your components. Also perhaps keep an eye on what's coming out of the Polymer team in this regard.
Performance. I've seen this video of Angular + React which provides a good comparison of angular vs angular + react vs angular 2. But I'm not sure if that's the case that angular 2 is really fast all the way or if we can go ahead with building angular + react app to avoid waiting for angular 2 to stabilize or the browsers to have support for es6 features that angular uses.
This sounds to me like premature optimization. Build for (plain) Angular first and optimize only if you notice performance problems in particular parts of your application.

TypeScript! Is it really needed to use typescript to gain better performance instead of writing plain simple JS code we've been doing all along. We've came across a few comments that says typescript helps in better performance.
TypeScript is not required to use Angular2.
Most examples you see will use JavaScript:
classes (ES6)
decorators (ES7/Typescript)
types - (Typescript)
Except, browsers don't support those features yet so all Angular2 source will need to be transpiled to ES5.
So in ES5:
classes can be faked by extending prototypes
decorators can be faked using wrapper functions
types aren't really necessary to begin with, they're synctatic sugar added for safety
It would be unrealistic to expect existing users to inherit the risk of using experimental/bleeding-edge standards. As such, the documentation covers writing Angular2 apps in ES5, ES6/7, and Typescript.
Aside: I personally prefer not to use TypeScript. Traceur can be configured to support with experimental extensions for #decorators, and system.js provides a polyfill for the proposed es6-moduler-loader spec.
Here's a look at the Angular2 Documentation.
ES6 features. Since angular 2 will be using a lot of es6 features, would that mean we'll have to wait for all the browsers support at least those features needed by angular 2 before we can kick start with it on our production applications.
As I said already, ES6 isn't officially supported yet in all browsers. Even if it were, most sites will still require a polyfill to provide backwards compatibility to older browsers.
One of the cool features of the es6-module-loader is the ability to dynamically load dependencies on the fly. By the time Angular2 is out of beta, it should be easy to incorporate this into your app as a feature-detection strategy.
Web components. Since angular 2 provides the facility to create web components and I've came across a few blogs on creating your own (using polymer), how hard is it gonna be for our team to create them? Or is it better if we just stick to old directives creation thing?
Not hard although you may need to use Angular2-specific web components. The reason being, Angular2 is more than a front-end web framework. It's can also be used for isomorphic (ie prerender on the back-end), native, and mobile apps. That means, touching the DOM directly is highly discouraged.
As for the creation of the components themselves... It's no different than creating any other component in Angular2. Unlike the old MVC model of grouping code by type (ie models, views, controllers), the component model encourages grouping code by context.
When you import a reusable component, it should come with any directives, services, etc required to use it.
For an example, see the I created. In addition to cloning the repo directly from GH, the code can be installed and imported directly via JSPM.
Simply import it, add the component class to your view directives and any <ng2-markdowm> element in your template will just work. It doesn't get much easier than that.
Performance. I've seen this video of Angular + React which provides a good comparison of angular vs angular + react vs angular 2. But I'm not sure if that's the case that angular 2 is really fast all the way or if we can go ahead with building angular + react app to avoid waiting for angular 2 to stabilize or the browsers to have support for es6 features that angular uses.
There are 3 major performance improvements introduced in Angular2.
1. 2-way data binding is no longer the default
Elements that require data binding need to be explicitly marked in the template (ie don't fret, the new syntax makes this really simple). As a result the overhead required to do dirty checking on the DOM is dramatically reduced.
That means, no more $scope, $scope.apply(), and weird scoping rules in the HTML markup. Instead, the hierarchy of custom <elements> is defined in the Angular2 components.
2. Angular2 leverages the virtual DOM
jQuery made it extremely simple to directly manipulate the DOM. As a result, it also made it extremely easy for inexperienced developers to thrash the DOM and trigger layout reflows via frequent incremental updates.
The VDOM is basically a simplified in-memory representation of the DOM. Incremental updates get applied directly to the VDOM which later get applied to the actual DOM in batches.
Aside from network requests, DOM manipulation is JavaScript's greatest performance weakness. The VDOM on the other hand is an order of magnitude faster. Instead of expecting devs to follow 'best practices' by manually batching updates to the DOM, Angular handles batching transparently.
Fewer DOM manipulations = less UI rendering/reflows = a much more responsive user experience.
3. Angular2 runs on a background worker
This isn't exactly a new concept. Desktop GUIs have worked this way for years, it just wasn't technically possible the introduction of HTML5 background workers.
In most desktop applications, the main context runs synchronously+ and the UI runs asynchronously in it's own separate thread. That makes the user experience responsive regardless of whatever the application is doing in the main context.
+Note: This isn't necessarily true, but for clarity sake.
In the browser, all execution happens in the main context+. That means, every time Javascript has to block on a CPU-heavy operation, the user interface becomes unresponsive to the user. This is not ideal and makes for a lousy/inconsistent user experience.
+Note: In practice browser implementations vary greatly but lets keep things simple.
With web workers, it's possible to push everything but the DOM+ into a background worker context. Ideally, Javascript's should have little-or-no impact on UI responsiveness.
+Note: The DOM's state still needs to be accessible to the renderer.
One side-effect this transition is, the Angular2 architecture is now completely decoupled from the UI/DOM. Meaning, it's now possible to write UI adapters for other platforms (ex for IOS, Android, SmartTVs, etc) that run on the same Angular2 code natively.
React
As far as I can tell React is using all of the same performance improvements as Angular. They use the VDOM to batch updates, and mentioned native portability to other platforms so I assume they went through the same architectural change as Angular.
Honestly, using background processing to free up the UI is just another step in the evolution to reach feature parity with desktop applications.
Angular2 vs React
I encourage you to watch the video again all the way to the end. The presenter screwed up when he wrote the code so the live demo wasn't an honest comparison.
With that said, it doesn't really matter which is faster. Neither will be dramatically faster than the other but they'll both be dramatically more responsive and scalable compared to other UI frameworks.
Update:
Rewrote the section about web components to better answer the question.

Note that Angular 2.0 does promise to work well with Web Components and Polymer, but in the current stage, i.e. Angular 2.0 alpha, it doesn't work (see this). So you'll have to wait for a while I guess.

Practical approach to keeping jQuery up to date?

Some of the projects we're working on have strong roots in jQuery 1.4.2 or earlier, and somewhere between lacking the performance edge (or syntactic sugar) of the latest releases, the humiliation of using now-deprecated methods, and the discomfort of deploying a 3+ year old version of an actively maintained library, an upgrade is now imminent.
What are some practices popular in the community that we could adopt/re-visit to ensure a smooth rollout (i.e. focus on obscure compatibility issues, picking up global regressions, re-factoring some of the older code...)? How would they be best integrated into SDLC for future upgrades? What is a reasonable upgrade schedule for a library such as jQuery (I don't anticipate significant gains or justifyable costs to do so with every point release, but once every 6-12 months may very well be reasonable)?

To actually answer your three questions, here are some things I've done or at least recommend:
Best practices for a smooth upgrade rollout
Have tests. These can be unit tests for your JS and/or browser tests. These should cover at least the most typical and the most complex functionality used within your projects. If you don't have tests, write them. If you don't want to write tests, reconsider. If you reeeeally don't want to write tests, at least have a list of use cases that someone will be able to execute manually.
Make sure all your tests pass before the upgrade.
Read the release notes for every (major) version between the version you use now and the most current release. See also the Removed and Deprecated categories in the API docs. If any of your code uses jQuery UI, also look at those release notes and upgrade guides for the interstitial versions. As you do this, make note of the things you would likely have to change in your codebase (possibly making heavy use of grep).
If your project's current jQuery version is >= 1.6.4, also consider using the jQuery Migrate plugin to further assess the work required.
Decide on which version you want to be your upgrade target, based on the work required to get there, whether your project is using any third-party libraries that require a certain version of jQuery, other factors only you can consider, etc.
Meet with your team to go over the list of changes to be done to your codebase, and divide/assign the work accordingly. Maybe write some scripts or other tools to help out. If you have one, your team's coding style guide / best practices document may also need to be updated. Decide on one-shot (recommended) or rolling update releases, if that's possible+desirable. Come up with a suitable release strategy. (I recommend against releasing the upgrade as part of another unrelated large change to your codebase, so it's easy to roll back if you need to.)
Throughout the upgrade process, continually run your tests. When testing manually, always monitor the browser console for new errors. Write new tests that cover unexpected errors.
When all tests pass, decide on how you want to roll out--if it's a site, all users at once or a percentage at a time, etc. For a library or other project, maybe you'd release a beta/bleeding edge version that you can let your more ambitious users test out for you in the wild.
Document everything you just did so it will be easier for the next time.
[Profit.]
How to integrate upgrades into normal workflow
Again, tests. Make sure you have them. Make sure they're good, maintained, and cover a large portion of your codebase and use cases. A continuous integration setup to automate the running of these tests is highly recommended.
Consider getting your team to create and agree to follow a coding style guide or standard. This will make it easier in the future to search for deprecated function calls or constructs, since everyone would be following similar coding patterns. Tools such as scripts, commit hooks, static analysis utils, etc. to enforce good or sniff out bad coding style might be useful (depending on the team).
Investigate and maybe decide to use a package manager like NPM or bower to manage jQuery versions and other third party libraries you might use that depend on it. (You'll still need to maintain your own JS code and go through pretty much the same process as above.)
Again, once you're past version 1.6.4, make sure the Migrate plugin is part of your upgrade workflow.
Assess what worked from the initial big upgrade process, what didn't work, and extract a general process from this that works best with your current workflow. Whether or not you plan to upgrade every time there's a new version, there will be ongoing maintenance tasks and habits that you'd probably want to keep as general development best practices.
Reasonable upgrade schedule
That's essentially a CBA/risk management question. You'll have to weigh some things:
There should be no breaking API changes within the same major version, so you should generally be able to upgrade to the most recent minor version with minimal effort, no refactoring required. This assumes you have and maintain good tests, which you can run on your projects before you decide that all is well enough for a rollout.
Major version upgrades require more research, more refactoring, and more testing. After the research step, you should do a cost-benefit analysis of upgrading.
This might not matter much, but if any of your projects is a website that has many users, what would be the cost of making all of your users have to download essentially all of the changed JS files on your site the next time they visit it (instead of sticking with the older versions that are probably still cached in their browsers)?
The decision to upgrade should always be a subjective one. Minor or major, you'll still have to justify each time whether any upgrade would be worth it. Always read the release notes. Does it fix a security vulnerability or a bug related to issues that you or your users are currently experiencing? Would it significantly improve the performance of your project (be sure to have benchmarks to verify it later)? Does it greatly simplify a coding pattern you've been using, allowing your code to be written more cleanly and easily? Is there a third-party library you want to use that is dependent on this newer version? Are there third-party libraries you already use which are dependent upon the older version? (If so, are these libraries likely to be upgraded anytime soon to work with the newer version?) Are you that confident in your tests and QA process that an upgrade will take a reasonable amount of development resources and cause no major regressions? Were you thinking of eventually switching out jQuery with something else anyway? Etc.
Of course this is just my advice. There are a few recurring themes in it, and I hope they are clear. In any case, I hope someone finds this helpful!

You will always be outdated. Once you are done updating to the latest version, a newer one will come out a few months later.
Unless you are willing to put hours/days/weeks of development, testing and bugfixing, with the possibility of breaking user-facing functionality, you shouldn't be updating just to use the newest way of declaring event handlers. It won't hurt you. And normally this is a risky thing to do. This translates into dev team costs. You already know this. Refactoring, especially when there is no evident risk for the project, is in general hard to justify to managers. And you should double check your thoughts to be sure if having the new jQuery in code that is already working will make any difference.
Now, if you are working on creating new pages in an existing site, you could be including a new version in those areas. But, this will have a consequence: lets assume that you and your team, apart from developing the new part of the site, also have to maintain the part that is using the old one. Everybody will need to be aware of the specific version of jQuery they are writing their code against.
So, to close, I would say something like this. Unless there is real justifiable risk for the project to be delayed or to be technically blocked because of an older jQuery version, you are going to be getting into trouble for breaking something that is already working and will need to put extra hours just to make everything work as well as it was working before.
Anyway, this approach doesn't mean that you could start separating the 'new sections' from the old ones, and using the newest libraries in the new areas.

This is worth looking into: https://github.com/jquery/jquery-migrate/#readme
This plugin can be used to detect and restore APIs or features that
have been deprecated in jQuery and removed as of version 1.9. See the
warnings page for more information regarding messages the plugin
generates. For more information about the changes made in jQuery 1.9,
see the upgrade guide and blog post.

The Twitter guys have solved this problem quite nicely.
http://github.com/twitter/bower
It does what it says on the tin - it is a package manager for the web (and that includes keeping JS files like JQuery up to date)

In order to keep up to date in your development tree, I recommend using src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.js" (the full un-minified version which allows for easier debugging)
Then when you go to publish, just replace it with the specific minified version that is in the header comment (currently http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js) This has the bonus of allowing better client side caching and using someone else's bandwidth.
If caching is less of a concern than ensuring that it will automatically get bugfixes for that minor version release, you can use just the major and minor version such as: http://ajax.googleapis.com/ajax/libs/jquery/1.9/jquery.min.js (Note: google doesn't yet have the 1.9 series up; however the 1.8 series is up to 1.8.3) Since these get updated periodically for bug fix releases they don't get cached like the version specific releases

In this era we cannot be predictable about the stability of the any software versions. Few years Before the versions of software and services releases after a year or two year. But at this time the versions of the services are updating rapidly and frequently.
So if you are using any service with your service you have to use Agile Development. By this development method you can easily make changes in the new requirements and change the required methods according to you.
And please don't use depreciated methods because they are not suitable for long-time service versions. And make libraries of the used services of library of your own service function that are using other services so that you can easily change them according to your new version.
For example : like you have a method name update_var(); it is calling a another method of other service like $a = newlib::check_update();. Then by creating libraries you have to change the main library of the function of your and the core library of the involved service