Develop Reference

What's the benefit of an IIFE that returns a value than just using that value?

I had found this code on Smashing Magazine:
window.browser = (function () {
return window.msBrowser ||
window.browser ||
window.chrome;
})();
I had noticed that this expression seemed equal to this one:
browser=window.msBrowser||window.browser||window.chrome;
Side note on the above code
It was supposed to be used in a browser extension, but it doesn't work in background scripts because they don't support window. Some other code that should work is:
if(typeof msBrowser!=="undefined")var browser=msBrowser;
else if(typeof chrome!=="undefined")var browser=chrome;
else if(typeof browser==="undefined")throw "UnsupportedBrowserError";
Is there a reason that the author had written the code in the way above? Not knowing the answer, I just decided to keep it the way it is. If there is a reason, what is it, and if there isn't a reason, would it be safe to use the one line alternative or should I use something else?

Is libphonenumber-js compatible with Angular's buildOptimizer option?

I'm trying to implement libphonenumber-js in my hybrid angularjs and Angular 7.2.2 project. It works fine in JIT (ng serve) but it gives errors when I enable buildOptimizer and optimize in angular.json.
If I enable only one of the above, it works fine as well.
I have no errors during the build, but when I open the form on the site I have the following in my console.
angular.js.pre-build-optimizer.js:14961 TypeError: (0 , r.default) is not a function
at MfjL.e.default (isValidNumberForRegion.js.pre-build-optimizer.js:37)
at e.isValidNumberForRegion (phone-utils.service.ts:32)
at O (my-account-data-controller.js.pre-build-optimizer.js:48)
at xt (my-account-data-controller.js.pre-build-optimizer.js:57)
at Object.invoke (angular.js.pre-build-optimizer.js:5117)
at O.instance (angular.js.pre-build-optimizer.js:11139)
at it (angular.js.pre-build-optimizer.js:10002)
at angular.js.pre-build-optimizer.js:9311
at angular.js.pre-build-optimizer.js:9176
at Object.link (angular.js.pre-build-optimizer.js:28821)
We use ng upgrade (https://angular.io/guide/upgrade) in our site.
In the chrome debugger, when I click on angular.js.pre-build-optimizer.js:14961, I get to
// Support: IE 9 only
// console methods don't inherit from Function.prototype in IE 9 so we can't
// call `logFn.apply(console, args)` directly.
return Function.prototype.apply.call(logFn, console, args);
When I click on isValidNumberForRegion.js.pre-build-optimizer.js:37, this is the code:
// `parse` extracts phone numbers from raw text,
// therefore it will cut off all "garbage" characters,
// while this `validate` function needs to verify
// that the phone number contains no "garbage"
// therefore the explicit `isViablePhoneNumber` check.
var input = void 0;
if ((0, _isViablePhoneNumber2.default)(number)) {
input = (0, _parse_2.default)(number, { defaultCountry: country }, metadata);
} else {
input = {};
}
The function that is not found being (0, _isViablePhoneNumber2.default)(number).
I would really like to be able to use both optimize and buildOptimizer since it is a huge app and this really improves performance. Any idea how to debug that ?
EDIT: This may be related https://github.com/angular/angular-cli/issues/11439

Updating the library to version 1.7.6 and using the new functions fixed the issue.

Should I keep console statements in JavaScript application?

I am using console.log() and console.dir() statements in 3 places in my 780 lines of code JS script. But all of them are useful for debugging and discovering problems that might appear when using the application.
I have a function that prints internal application's state i.e current value of variables:
printData: function () {
var props = {
operation: this.operation,
operand: this.operand,
operandStr: this.operandStr,
memory: this.memory,
result: this.result,
digitsField: this.digitsField,
dgField: this.dgField,
operationField: this.operationField,
opField: this.opField
};
console.dir(props);
}
I also have a list of immutable "contants" which are hidden with closure but I can print them with accessor method called list(); in console.
Something like this:
list: function () {
var index = 0,
newStr = "",
constant = '';
for (constant in constants) {
if (constants.hasOwnProperty(constant)) {
index = constant.indexOf('_');
newStr = constant.substr(index + 1);
console.log(newStr + ": " + constants[constant]);
}
}
}
The third place where I use console in debugging purposes is in my init(); function, where I print exception error if it happens.
init: function (config) {
try {
this.memoryLabelField = global.getElementById(MEMORY_LABEL);
this.digitsField = global.getElementById(DIGITS_FIELD);
this.digitsField.value = '0';
this.operationField = global.getElementById(OPERATION_FIELD);
this.operationField.value = '';
return this;
} catch (error) {
console.log(error.message);
return error.message;
}
}
As my question states, should I keep these console statements in production code?
But they come very useful for later maintenance of the code.
Let me know your thoughts.

Since these are not persistent logs you won't get much benefit out of them. Also it runs on every individuals machine since everyone has their own copy of the program. If you really need it, it would be better to have a variable that can toggle this feature. Espcially if you are targetting to debug a whole lot of pre-determined stuffs.
Client Side issues needs to be debugged slightly different from Server Side. Everyone has their own copy of the program. Browser-JS is run on client side you open the browser and all code that you wrote is with you in a full blown repl and debugging is easy compared to Server side where most likely you wouldn't have access to that system. It is so flexible that you could just override it when you are checking something in production right from your own browser without affecting anyone. Just override it with those console statements and debug the issue.
Its a good idea to have logs in Server side programming. It gives a lot of useful information and is persistent.

As said above, debugging code should not be present on a production environment.
However, if you plan to keep it anyway, keep in mind that all browsers do not support it.
So you may check its availability and provide a fallback:
if (typeof window.console === 'undefined')
{
window.console = {};
}
if (typeof window.console.log === 'undefined')
{
window.console.log = function() { };
}

According to mozilla developer network
This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.
Leaving console.log() on production sites can cause issues since it is not supported by older browsers. It is most likely to throw exceptions in that case.

It's historically considered a bad-practice by Javascript programmers. At the start of the eons, some browsers didn't have support for it (IE8 or less for example). Other thing to take in mind is that you are making your code larger to download.

Enable/Disable debug code dynamically

I'm writing a decent sized JavaScript animation library, that I would like to include debugging code in. I could easily do a check :
if(myLib.debugger){
console.warn('warning message');
}
However if this runs a couple thousand times a second, it would eventually cause performance issues. Add in a few more checks throughout the code and the effect will be even more noticeable.
What I'm wondering is if it would be possible to check onload if the debugger should be enabled, and if so... turn something like this:
//debugger if(!this.name) console.warn('No name provided');
into:
if(!this.name) console.warn('No name provided');
Leaving the code commented if its not enabled, and uncommenting it if it is, thus removing any possible performance issues. Could this be done somehow with a regular expression on the entire script if loaded in through ajax? I'm trying to avoid the need for 2 versions of the same code, lib.dbug.js and a lib.js.
Cross browser compatibility is not of great importance for this (I'm really only worried about new browsers), I see it as nice to have item. If its possible however, it would be a great thing to have.
Any insight would be greatly appreciated.

The simplest way to do this would be to check if the debugger should be disabled and if so, replace it with a mock object that does nothing at the very start of your script:
if (!myLib.debugger) {
window.console = (function () {
var newConsole = {};
var key;
for (key in window.console) {
if (typeof window.console[key] === 'function') {
newConsole[key] = function () {};
}
}
return newConsole;
}());
}
The overhead of this approach should be negligible.

If this is a JavaScript library... then I'd expect as a 3rd party developer that I could download/use 2 versions. The production version (no debug, AND minimized). If I wanted to debug, I would point to the debug version of the library instead.
e.g.
<script src="foo-lib-min.js"></script>
<!-- swap to this for debugging <script src="foo-lib-full.js"></script>-->

programmatic way to check which version is installed?

Is there a way through javascript to see what version (or rollup) the crm organization/server is on? What I really want to know is if I am on UR11 or before.
I've tried:
Xrm.Page.context - but nothing about versions (did I miss something?)
Checking if (crmForm == null) (Since that was disabled as of UR12) The problem is that if the org enables HTC support then crmForm will not be null, and I need to know what version with or without HTC support enabled.
What I've done for now is put the onus on the solution installer to modify a javascript file that has the "isRollup12" variable to true or false, which is quite clunky.

There is a global JS variable you could check:
alert(APPLICATION_FULL_VERSION);
//on UR12 '5.0.9690.3236'
//on UR11 '5.0.9690.2839'
//and so on...
But this method isn't supported, so use at your own risk.

you can check if the getClientUrl function is defined, it's a new function included inside UR12.
var isRollup12 = false;
if (Xrm.Page.context.getClientUrl !== undefined) {
isRollup12 = true;
}