Last time, we’ve revisited how to implement a JavaScript customization from a non-developer perspective. If you haven’t read it yet, here’s the link.

From a non-developer perspective, using a JavaScript web resource can be quite easy or complicated depending on how the developer implemented the functionality needed from the JavaScript web resource. One can argue that a specialized JavaScript method would be easier for a non-developer to implement on their own. While I agree with this, a well-designed reusable JavaScript library is miles better, as it saves more time in the long run, especially for trivial but repetitive type of customizations like dependent picklists or dynamic subgrids. This is such whenever you need your picklist to be dependent on another picklist or you need a couple of sub-grids to be visible based on a picklist selection.

As an example, I created a Gist of a decently structured code template for creating a reusable JavaScript web resource that can be used for picklists.

Reusable JavaScript Customizations in Action - github gist

 

As you can see from the code snippet above, I used JavaScript namespace to avoid function name collision. Using JavaScript namespace is vital since function name collision can produce unforeseen results.

I created another Gist for a basic namespace template that I am using in most of my JavaScript customizations, as well as in full-stack web development in various platforms. Feel free to use it as well.

github gist 2

 

Going back to the first Gist above, notice that I used a naming convention of action + ControlType for the method name. This is so that the user guide that we will be creating for the non-developer customizer will be more intuitive and easy to remember. Just by looking at the name of the method, anyone will have a good guess of what it does. The method filterDependentPicklist already suggests to you that it’s meant to filter a picklist. Same with displaySubgrid; it gives you the idea that it’s meant to display a subgrid.

displaysubgrid

 

I always make it a point to require the execution context as a first parameter of my methods. This is so that the code can get the event source where the method is attached to as an event handler. It is also quite handy in other situations.

execution contexts

 

The next parameter is the name of the control on the form that will be acted upon by the JavaScript method. Nothing special here; we are just introducing the control to the JavaScript method so that it can search for it by name.

name of control

 

And the last parameter is a jsonConfig that will contain the data needed for the JavaScript method to do what it’s supposed to do. It’s just an if-this-then-this configuration map. If this is the selected value from the picklist, then filter the dependent picklist with only the following set of values. Or if this is the selected value from the picklist, display the subgrid with this name.

jsonconfig

 

As you see, we removed all dependency from the JavaScript web resource and required the customizer to pass the necessary parameters. This will allow the JavaScript methods to be used on any control as long as the action needed from it and control type it supports are satisfied.

So, there you have it folks. I hope you’ve learned something from this blog post. If you have questions or any suggestions for my next blog post, please leave a comment and I’ll try my best to oblige. I’ll keep you posted, D365’ers.