In any endeavour, you can code and code and code to your heart’s content, and then when you pop up your head you realize – huh – this is a mess.

Continuing off of Part 3 where we focused on deployments, I wanted to do some clean up with my code in how it was organized and how I called it in PowerApps.

One Build to Rule them All

I want to click a button, and have that button do it all. In Part 3, we spoke about using terser to minimize our code after we had it built – but that’s two commands to run and that’s two commands too many.

To make this more elegant, we are going to create a script that we deploy into package.json file that will run tsc and terser and give us a cute little message that we are good to go.

In the scripts section of your package.json create a new line and give your script a name (I called mine make).

The code itself is here…

“make”: “tsc && terser webresources/js/dist/app.js -o webresources/js/dist/app.min.js –compress –mangle –compress –mangle && echo ‘Finished'”,

Now, you can call npm run make, and your build will execute every time.

Namespacing and Classes

To date, we have been exporting only our functions, but that gets problematic with naming and who wants to have to update naming conflicts when we should be coding. I’m not going to delve into the concepts of Namespaces and Classes, you can find information on both of these constructs here.

We are going to wrap our code around a namespace, called Entities, and instead of marking our function as exportable, we are going to make our class exportable. In the below screenshot, you will also notice that I have marked the function as static. This is in part because of how we are going to call it from PowerApps without the class being instantiated itself.

Now the fun part, is when I go to the form itself, I am going to modify how I call our OnLoad function to include both the namespace and class declaration.

Doesn’t that look beautiful?

Okay, now that things are cleaned up we can go back to the coding.