Dynamics 365 – Problems debugging fields on a form

“ If debugging is the process of removing software bugs, then programming must be the process of putting them in. ” – Edsger Dijkstra

Dynamics 365 is a place where only dirty entities and fields are saved! The clean fields are ignored #HoskCodeWisdom

  • Junior developer – assumes how things work
  • Good developer – finds out through trial and error
  • Great developer – does not assume and methodically confirms

Dynamics 365 can frustrate developers (The Frustrations of a CRM Developer), developers are provoked by the idiosyncratics, limitations and bonkersness of Dynamics 365 as Microsoft works on new ways to annoy developers 🙂

Bugs and problems areopportunities to gain a deeper knowledge of the workings of Dynamics 365.

New developers get caught out such as in the CRM 2011 (good old) when SetSubmitMode was a rite of passage for Dynamics CRM developers – CRM 2011/2013 – What does setSubmitMode do? and how does it work?

Unless you made the field dirty and change SubmitMode the field was not sent to the database to be saved

Try, Try and try again

On creation of an appointment the start and end times should be editable, on a form update those fields should be readonly.

Examples of using the SetDisabled(true) were found in the code, copied and adapted for the start and end times on the appointment entity.

He kept debugging and being puzzled because the start and end times were not changing, but why not?

Insanity: doing the same thing over and over again and expecting different results.  Albert Einstein

Developer Insanity: Testing the same code over and over and expecting intermittent result #HoskCodeWisdom

Hosk developer debugging beliefs

  • Investigate bugs with an empty mind
  • Microsoft 365 is full of quirks which make sharing knowledge between team members important
  • Bugs are not a sign of a bad developer, they are a sign of a developer developing #HoskCodeWisdom
  • Always help your fellow developers, big projects need a strong team.  Never leave a developer stranded
  • Don’t suffer in silence if you are not making progress, get help and get direction #HoskWisdom

SetDisabled = true

The way to make a read-only field editable is to use the Dynamics 365 JavaScript Xrm, get the control and use the setDisabled(false)

Xrm.Page.ui.controls.get(“your field name”).setDisabled (true); //Field readonly you can’t write any thing on field

if you change true as false;

Xrm.Page.ui.controls.get(“your field name”).setDisabled (false); //Anyone can put value on this field

I looked at the code, it looked fine, we checked a few things

  • Is there any other code changing the field back to read only –> No
  • Checked the line worked in the debugging console –> Yes
  • Was there a JavaScript error –> No
  • Debug the code, does it run the line of code which enables the field –> Yes

Appointment entity

In this example we used the appointment entity, which is an odd entity.  It‘s not possible to add new forms for the appointment entity Dynamics 365 – You can’t add new forms to the appointment entity There is code running on the appointment entity which a CRM developer has no control over, cannot see and cannot edit.

When you book appointment it sets the user who booked the appointment as the organizer of the appointment.  This is fine for Outlook but not what I wanted to happen in Dynamics 365.

Adding hidden custom code which developers can’t disable is frustrating as much as it is undocumented, believe Microsoft should write customizations in the same way standard Dynamics 365 developers do. This would allow us to see, modify, disable or extend the default behavior.

Stop, think

When you rule out the obvious, it’s time to check the stupid – #HoskWisdom

Appointment entities don’t allow you to add new forms (or change the status/status reason of the appointment) because we couldn’t add new forms, we had JavaScript which when the regarding field was set to a specific custom entity we disabled the default section and showed a new section with custom fields on.

Usually a developer would create another form but we couldn’t because it was the appointment entity

This resulted in the same fields being on the form twice, the start and end times.  So the code was working, except it was making the fields on the hidden section and the first fields on the form.

To resolve the problem go to the section (in code) and then retrieve the field you want and then make it make it editable.

Hosk values with bug fixing

  • Developers who fix a problem which doesn’t keep popping back because it‘s not properly fixed
  • Developers who use a bug as an opportunity to learn how Dynamics 365 works
  • Developers should try to resolve the problem first before asking for help
  • Don’t spend too long being puzzled by a bug before asking for help, Dynamics 365 has odd quirks and limitations which can take hours to resolve.  Get direction from a colleague after 1 hour of frustration
  • Developers should not assume, they must clarify (I wasted hours looking in the wrong place because I didn’t check my assumptions)

On a separate note but relatedish – Developers using JavaScript onload should be careful when setting and changing values because it can frustrate user by asking them to save a form when they haven’t change any values When to automatically change fields using Javascript 

picture from here

Advertisements

CRM 2015 – How to set focus in Javascript

I wanted to set focus in Javascript after a user had changed a field to yes, this triggered an onchange event.  The onChange event set a new tab to be visible.

The new tab was below and the users didn’t always know it was there, so I wanted to nudge them in the right direction by setting focus on the tab.

Microsoft has added a great framework for manipulating the controls.  The Javascript for setting focus works on the Control level

Xrm.Page.getControl(arg).setFocus()

Xrm.Page.ui.tabs.get(“tab_schemaName”).setFocus();
Xrm.Page.getControl(“ntt_reviewteamid”).setFocus();

This blog post has a great page, it highlights the functionality available in the CRM SDK, displaying the logical structure of the JavaScript wrapper created for development

Microsoft Dynamics CRM 2013: Client API Enhancement

 

Different Versions

It’s important to check the CRM SDK XRM documentation because each release of CRM adds and removes functions.

Xrm.Page.ui control (client-side reference)

The CRM SDK documentation shows the functionality available for each release by selecting the CRM version in the drop down at the top of the page.

Javascript versions

When you select a different version it will change the methods available.  This enables you to see what functionality is available for each version and what new functionality has been added.

CRM 2015/CRM2013 – JavaScipt to get the current users name

This blog post will show you a quick way to get the name of the user using JavaScript.

Where you might use this functionality

This functionality is useful because you might need to update a User lookup field to a particular user in situations like

  • The current user changed a key field
  • The current user is primary contact for a project, account, deliverable.
  • Set a text field of the users name for reporting purposes.

Why are you mentioning it

To do retrieve the current user name in CRM 2011 it took a soap call to retrieve the user name field using the Xrm.Page.context.getUserId().  Below is a blog post I wrote

CRM 2011 – Setting a user lookup with the logged in user with Javascript

There is now a much easier way to do this in CRM 2013 and CRM 2015.  I found this way whilst reading this forum post

crm 2013: javascript get attributes from other entity in Contact Form

Start with the CRM SDK

The Hosk CRM developer mantra is to always start with the CRM SDK to see what methods and functionality exists which can help.

Searching the CRM SDK first helps you see what functionality Microsoft have added, most CRM developers will be surprised the number of new methods added.

It’s very easy for developers to copy and paste existing code in projects but just because it works it doesn’t mean its the best code to use.

This is classic case, the CRM 2011 code is long and involves a soap call, the new functionality added in CRM 2013 allows you to access the data with one line.

Microsoft Client code page – Client-side context (client-side reference)

There are three useful functions about the existing user (there’s another about language but I’m not including it).

getUserId
Returns the GUID of the SystemUser.Id value for the current user.
getUserName
Returns the name of the current user.
getUserRoles
Returns an array of strings that represent the GUID values of each of the security roles that the user is associated with or any teams that the user is associated with.

 

Xrm.Page.context.getUserId()

This would get you the SystemUser.Id

Xrm.Page.context.getUserName();

This would return a text string of the user name

Setting User lookups

The common reason for retrieving the user name and the user id is because both values are needed if you want to programatically set a lookup field in CRM.

Example code is shown below


var setUservalue = new Array();
 setUservalue[0] = new Object();
 setUservalue[0].id = Xrm.Page.context.getUserId();
 setUservalue[0].entityType = 'systemuser';
setUservalue[0].name = Xrm.Page.context.getUserName();

Xrm.Page.getAttribute("LookupField").setValue(setUservalue)

Alternatives

In the requirement I was working on I used JavaScript because I needed to set a field dynamically and instantly.  Other CRM customizations may have different requirements and you could set the lookup field using a Plugin or a workflow.

What I have learnt

  • Use the CRM SDK to see what functionality exists, there might be a better way
  • Microsoft added a new getUserName method in CRM 2013
  • You need the guid, name and entity type to set the value of a lookup field
  • If you don’t need to set the lookup instantly you can use workflows or plugins
  • CRM forum posts provide extremely useful information from a number of CRM developers

 

CRM 2013 – Javascript null setting oddity

I had an odd error where I was trying to null a lookup field in Javascript in CRM 2013 Service SP1.

When the user changed a lookup field, I wanted to blank out a few fields to make them select those fields again.  The fields being nulled were dependant on selection of the first lookup field and the options and values they could pick changed.

It’s good practise to reduce the number of choices users have by filtering out values in option sets and lookups, hiding/showing fields.  This makes the forms more cohesive, less noise for the end users.  Read more about CRM Form design in the article below

Good CRM design should not make users think

The initial code was in a function and looked like this

        if (Xrm.Page.getAttribute("field1").getValue() != null) {
            Xrm.Page.getAttribute("field1").setValue(null);
        }


        if (Xrm.Page.getAttribute("field2").getValue() != null) {
            Xrm.Page.getAttribute("field2").setValue(null);
        }
        

Oddly field1 was correctly set to null but field2 refused to be set to null.

To add to the annoyance of not setting the field to null, the not nulling triggered the OnChange event for the lookup which set other values on the previous not nullable value!!!

This made me angry

Stepping through

When bug fixing the goal is understand exactly what is happening, once you understand what is happening it might be possible to work out why or work around it.  There is a big difference between

  • Knowing what is happening
  • Your assumptions about what is happening

Assumptions are dangerous because they can easily be wrong.  When bug fixing don’t assume anything and prove everything.  I have wasted plenty of time with assumptions and investigating the wrong section of code.

I started debugging and stepped through the setting the values to null.  The handy part of debugging JavaScript is the console allows you to integrate the values.

The values on the GUI looked like fields1 and fields2 were both not being set to null.

I debugged and stepped through the code, field2 wasn’t being set to null but the OnChange event was running for field2 which was setting field1 and field2 to the values based on the previous field2 value.

One change at a time

One of the golden rules when debugging a problem is to change one thing at a time, monitor the effects of the change.  This rule is particularly inportant if the change is a configuration change which will be changed on multiple environments (DEV, TEST, PREPROD, PROD).

When changing values or code, making a solitary change will show you the effects of the one change.  If you change 5 things at once which resolves the problem, you don’t know what change has fixed the problem.  In the multiple change scenario you would either need to go back and change one variable at a time or make all the changes in all the environments.

When making changes to code/config it’s good practise to minimise the changes, which minimises the potential unknown effects of these changes and reduces bugs coming from these changes less likely.

I tried

  • removing field1 change
  • swapping the order, changing field2 before field1
  • double checking javascript
  • Asking fellow CRM developers

Asking fellow CRM developers did bring a few mumbles of maybe having seen something like it before but no one could remember what is was or what they did (if only they wrote a blog post about it!!)

None of the other changes did much.

To the Internet

 

Searching the internet didn’t bring up anything directly relevant (how often does that happen!), it did lead me to this page

Javascript, onChange events no longer work on an empty field

This wasn’t the problem I was experiencing

I just noticed that if you have a form field that triggers a Javascript function on the onChange event it no longer triggers the function if you clear the field, but ONLY when you change the field data. For instance; if you have a Name field populated with a name, and you remove the name – the function isn’t triggered. It’s left empty. You have to change the text inside the field.

 

The problem being talked about here is setting required fields to null didn’t trigger the onchange.  I had this reverse of this problem I was setting field2 to null, it wasn’t setting but triggering the OnChange, which means Microsoft fixed the problem report (the forum posts were Feb 2014).

The forum post go me thinking, lets change the field requirements and see what happens.

Setting field requirements using Javascript

Fields have three levels of requirements

  • none
  • required
  • recommended

For some reason accessing these programmatically seems quite different from setting/adjusting them using the GUI.  Looking at the list what is the point of recommended, it should be required or none.  Why you would want to change a field to have a requirement level of recommend?

The code is string based, which seems a little odd and prone to syntax errors.  To find all the Javascript methods use this page on the CRM SDK

Xrm.Page.data.entity attribute (client-side reference)

Here is an example using the trusty field2

  • Xrm.Page.data.entity.attributes.get(“field2”).setRequiredLevel(“none”);
  • Xrm.Page.data.entity.attributes.get(“field2”).setRequiredLevel(“required”);
  • Xrm.Page.data.entity.attributes.get(“field2”).setRequiredLevel(“recommended”);

I changed my code to set the required level to none, set field2 to null and then reset the required level to required.

//I had to set required level to none because assign null wasn't working, might be fixed in future roll ups
	if (Xrm.Page.getAttribute("field1").getValue() != null) {
            Xrm.Page.getAttribute("field1").setValue(null);
        }

        Xrm.Page.data.entity.attributes.get("field2").setRequiredLevel("none");
        if (Xrm.Page.getAttribute("field2").getValue() != null) {
            Xrm.Page.getAttribute("field2").setValue(null);
        }
        Xrm.Page.data.entity.attributes.get("field2").setRequiredLevel("required");

Leave a comment

If you have written some unusual code as a work round for a limitation in design or a known bug, it’s good practise to leave a comment explaining to other developers (and maybe your future self) why you have put the code.

Reasons why you should comment unusual code

  • A developer could easily delete the code without realising what is meant to do
  • It could be confusing for other developers to read and understand
  • A rollup/service patch might fix the code and it could be safely removed
  • The developer reading the code might know the solution to this problem
  • It’s good practise

CRM 2013 – Disabling a subgrid

This blog post will look at possible ways to disable subgrids in CRM 2013.  I had a requirement if a user made a case restricted then the case couldn’t be linked to any other cases.

Requirements

  • On the case form we had functionality to select a parent case and a subgrid to add child cases.
  • Case had a restricted bool field
  • Restricted cases could not link to any other cases

If the user set restricted to Yes I had to disable the subgrid and the case lookup, e.g. stop the restricted case from being linked

Disabling the case lookup field was was straightforward

  
Xrm.Page.getControl(fieldName).setDisabled(true);
	

Frustratingly for me subgrid control does not have a setDisabled method, this means disabling the subgrid would not be as straightforward.

Disabling a sub grid

This is a different story, a story with twists, frustration

An unsupported way

http://www.magnetismsolutions.com/blog/paulnieuwelaar/2012/02/28/Disable_Subgrids_with_Javascript_in_Dynamics_CRM_2011.aspx

  
// Disable a subgrid on a form
function disableSubgrid(subgridName) {
document.getElementById(subgridName + "_span").disabled = "true";
}
	

I’m not going to consider putting in unsupported changes because if you do then Microsoft will unsupport your customizations.  This probably doesn’t sound like much of a threat but if you find a bug with out of the box functionality Microsoft won’t even look at your customizations due to the unsupported code.  When the customer then finds out they have no Microsoft support because of your code.

Why you shouldn’t put unsupported customizations in Microsoft Dynamics CRM

From the Hosk Wisdom page 🙂

Don’t even think about making unsupported changes in CRM because Microsoft will un-support your CRM if they find out – Hosk

Don’t do unsupported CRM customizations, 99.9 percent of the time there is another way.  For the 0.1, tell the customer its unsupported – Hosk

Other Options

If I can’t disable the subgrid (in a supported way), what other options do I have?

Disable buttons on subgrid

Scott Durow the Ribbon Workbench creator has an excellent article on disabling the add new button.  This hiding rule could be set on all the add buttons on the subgrid.

Show or hide the ‘Add New’ button on form sub-grid based on the value on the form

It’s worth reading this article just to look at the image which explains what buttons on the sugrid link to what buttons on the command bar inside the Ribbon Workbench.

In theory this option should work but it would involve setting up enable rules for all the buttons on the subgrid.

Hiding and Showing

Hiding and showing sounds like a kids TV show, actually I’m thinking of Show me Show Me

My initial thought was to disable the grid but in CRM 2013 sub grid doesn’t have a setDisable, which stopped my plan but looking at the CRM SDK I can see subgrids control does have a setVisible.

This line of supported code will hide the subgrid 

Xrm.Page.ui.controls.get(controlName).setVisible(false);

This shows it again

Xrm.Page.ui.controls.get(controlName).setVisible(false);

The code above worked and it did hide the subgrid, the problem I had was it looked odd because it left a big blank white space where the sub grid was hiding (not very well).

The other problem is sub grids load asynchronously.  I needed my code to work on the form OnLoad event but when it came to hiding the the subgrid it was loaded yet and would throw an error.

To get round this error, I would need to wait until the subgrid had been loaded, so I could subsequently hide it (which doesn’t seem right when I say that out loud)

I created this code to wait until the subgrid is loaded.

  function ShowSubgrid(show) {
        var Subgrid = Xrm.Page.ui.controls.get("ChildCasesGrid");

        if (Subgrid == null) {
            setTimeout(function () { ShowSubgrid(show); }, 2000);
            //if the grid hasn’t loaded run this again when it has
            return;

        } else {
            if (show) {
                ShowControl("ChildCasesGrid");
            } else {
                HideControl("ChildCasesGrid");
            }
        }
    }
	

This works but I don’t like having wait’s in code, particularly in a form load where you don’t want to add an extra lines running on a form load which usually takes a while and the form load performance is extremely visible to a user.

I am of the opinion to avoid waits in the code at all costs, if you have a wait in the code you have a bug/problem waiting to happen.  Most of the time its worth the effort to find an alternative solution and reduce the complexity of your code.

A wait in code is similar to seeing +1 in some code.  The code is working round a problem rather than resolving the cause.

When considering form loads in CRM, it’s probably comparable to the frustrating time it takes for a computer to boot up in the morning.  The time may only be a short amount of time but it feels about four times as long in real time.

Whilst a form is loading the user has nothing to keep them occupied so the time feels longer, try to keep forms loads as quick as possible.  Here is a blog post I wrote on performance issues

CRM 2011/2013 Investigating CRM Form Performance issues

QUICK BREAK TO LOOK AT CRM 2015 SP1 new GridControl stuff

Looking at the CRM SDK form events page, initially it loads the latest page for CRM 2015 and I noticed CRM 2015 SP1 has a new special Subgrid OnLoad event.

There is a new page Write scripts for subgrids, there is now a new GridControl and you can look Grid objects and methods to see the new cool things you can do

The Grid Onload method is cool but there are some other interesting methods I noticed

The grid has

  • getRows
  • getSelectedRows
  • getTotalRecordCount

From the Grid you can get do a getRows and from here there are some great helper methods in the GridEntity

  • getEntityName
  • getEntityReference
  • getId
  • getPrimaryAttributeValue

and other stuff which you should go and check out yourself

Back to CRM 2013 subgrids

After some developer brainstorming I decided to try putting the subgrid into a section.  The advantages of this is you can hide/show a section without having to wait for the form to load.

Another advantage is when you disable a section it hides itself much better, the form acts as if it wasn’t there at all, unlike hiding the subgrid which leaves a white space the same size as the subgrid.

To hide or show a subgrid you have to toggle the visible flag using the setVisible method

Hide

Xrm.Page.ui.tabs.get("tabName").sections.get("sectionName").setVisible(false);

Show 

Xrm.Page.ui.tabs.get("tabName").sections.get("sectionName").setVisible(true);

Plugin Option

Maybe the most straight forward to resolve this issue is to have a plugin which is triggered on change of parentCase field.  When setting this you could check to see if the child or parent case is a restricted case and throw a pluginException

Conclusion

The blog’s title is about disabling a subgrid but the goal was to stop restricted cases from being linked.

The benefit of Javascript customizations is they are instant because the code works on the client side.  Plugins are server side, so their is a delay in capturing and responding to the changes.

Javascript can often offer a better user experience because CRM developers can react instantly to changes in values and hide/disable fields.

Server side changes are less responsive and cannot guide the user in the same way Javascript validation code can but has to catch the values and decide whether to roll them back.  Server side validation can be more frustrating to CRM users because they have made the changes, only to find them being rejected.

In this scenario the plugin/server changes are in one place, where there are lots of Javascript code changes to do the same thing.

A key skill of a CRM developer is selecting the right customization for the right job

CRM 2015 SP1 – Turbo forms use asynchronous JavaScript web resource loading

I was reading this blog post from the CRM Lady

Turbo Forms in Microsoft Dynamics CRM 2015 (v7.1.0)

The article points to some good resource learn more about the new turbo forms.

The article from the CRM Team has a wealth of interesting information and lots of healthy warnings for you

Microsoft Dynamics CRM Online 2015 Update 1 – New Form Rendering Engine

What are the new turbo form

Microsoft have been doing lots of tinkering how the CRM forms are rendered.  This graphic shows the effect

// // // // // //

When I saw the graph above my first thoughts were

  1. WOW, Awesome
  2. How did they get such a dramatic improvement
  3. Will this break my customizations

How did Microsoft Improve loading times

I will quote the article

There are 2 main changes that have been made: loading process of the form, and handling of cache.

The article indicates they have moved to parallel loading and are caching more data.

 

Hmmmm Parallel Javascript loading

The increased form loading is great but parallel loading can have some downsides.  I first came across Javascript parallel loading in CRM 2011 rollup 12, you can read about here

To speed up form loading in CRM 2011 they switched to parallel loading and the result meant lots of Javascript methods suddenly stopped working.  The reason for this was because one Javascript file was calling a method on another javascript file.  This worked when the Javascript files were loaded in an order but when you load them all at once sometimes one Javascript file tries to call another dependant Javascript file which is still loading.

So suddenly lots of Javascript errors appeared and all developers had to write a Javascript wait file, like CRM MVP Scott Durow talks about in this article

This is a significant change and could cause lots of errors if you have Javascript code in your OnLoad functions which call other Javascript files.

I noticed a new section appeared in the mdsn article Write code for Microsoft Dynamics CRM forms

Manage library dependencies

As a performance optimization, Microsoft Dynamics CRM forms load JavaScript web resources asynchronously and in parallel. This means that the order in which the libraries are configured for a form does not guarantee that a library will be fully downloaded and initialized before another library might attempt to use one of the objects defined in it.

If you have code that depends on another library to be fully downloaded and initialized, the most straightforward approach is to combine both libraries within a single JavaScript web resource with your code below the library code. A more sophisticated approach is to use libraries such as head.js or require.js to control how the separate libraries are loaded.

 

Is Parallel loading good or bad

There is a quote in blade runner

Replicants are like any other machine. They’re either a benefit or a hazard. If they’re a benefit, it’s not my problem.

Upgrading to CRM 2015 SP1 could cause big problems to Javascript customizations.  It’s good practise to split up your Javascript code to separate files to make it reusable and maintainable but now Microsoft are recommending we put everything in one file.  This could turn out to be one big massive Javascript file, which is ok for performance but maintaining and working with this file is difficult.

This change could catch many CRM developers out because the errors are intermittent, sometimes the javascript files will have loaded in the correct order and work.

It will involve developers writing Javascript code which waits until all the Javascript files load which will cancel out any benefits from parallel loading.

It could be seen as an opportunity to restructure Javascript code to have a self contained loading script and then move other Javascript functions to OnChange events.  This would be a double win of increased loading time due to parallel loading and running less code.

You can use Legacy form loading style

There is a system setting which contains a global setting to control which form loading style you use.

It’s a great idea for Microsoft to put this in because the new speedier form loading code might take some while getting use to it.  When CRM 2011 polaris release came it, it caused a raft of blog posts because CRM Javascript customizations suddenly stopped working.

Settings -> Administration -> System Settings -> General. Select “Yes” under “Use legacy form rendering”

In a perfect world it would have been great to have a entity setting rather than a global setting for the form rendering.

I thought I would write about this because it could effect a lot of people and I never spotted this change until today.

 

What is the !! Javascript operator!!!!

I saw some Javascript code which the CRM Developer Pacman was working on and it had a bizarre If statement which used a double exclamation mark!!

One exclamation mark means not but what does two exclamation marks mean Not Not?

Below is the code in question

var roleName = null;
$.ajax({
    type: "GET",
    async: false,
    contentType: "application/json; charset=utf-8",
    datatype: "json",
    url: odataSelect,
    beforeSend: function (XMLHttpRequest) { XMLHttpRequest.setRequestHeader("Accept", "application/json"); },
    success: function (data, textStatus, XmlHttpRequest) {
        var result = data.d;
        if (!!result) {
            roleName = result.results[0].Name;
        }
    },
    error: function (XmlHttpRequest, textStatus, errorThrown) {
        //alert('OData Select Failed: ' + odataSelect);
    }
});

The code was doing an OData query and then checking the result with the if Statement

if (!!result) {

      roleName = result.results[0].Name;

}

What does the !! exclamation do

It’s quite clever because the first exclamation mark converts the object into a boolean value, the second exclamation mark checks to see if the boolean is false.

In C# developer terms its like casting the object to a boolean and then doing an inverted check (e.g. if not false)

This two Stackoverflow articles discuss and explain the !! exclamation in more detail but this answer and the truth table helped me understand

Double Exclamation points

''        ==   '0'           // false
0         ==   ''            // true
0         ==   '0'           // true
false     ==   'false'       // false
false     ==   '0'           // true
false     ==   undefined     // false
false     ==   null          // false
null      ==   undefined     // true
" \t\r\n" ==   0             // true

Using the table above my understand is the !! exclamation in the examples checks to see if the result object is not 0, undefined, null because all those values would be converted to a boolean type of false.

Here is another good discussion on the topic

What is the !! (not not) operator in JavaScript?

Whilst researching this topic I found the article below

Truthy and falsy in JavaScript

The article talks you understand how Javascript uses true, truthy, false and falsy in JavaScript

 

%d bloggers like this: