One of the most frustrating things that can happen when developing any type of software is when you’ve got the code correct but, due to it being in the wrong place, it doesn’t work as you’ve expected. A recent question on the community forums highlights the importance of putting your JavaScript in the right place.

Background

In my series on where you can (and should) put your HTML, CSS, Liquid and JavaScript I covered the various places where you can put code. In general, I like to put in the most specific place possible – for example, if you write some JavaScript for your Entity List, use the Custom JavaScript attribute on the Entity List as opposed to the one on the Web Page you are putting the list on. However there are cases where it isn’t so straight forward to figure out where to include your required JavaScript.

Authentication-Related Pages

Let’s say you want to use JavaScript to modify the appearance of the Sign In page. All of the authentication pages are created using ASP.NET MVC, and don’t follow the Web Page paradigm. This means there is no Web Page record that you can put your JavaScript into the Custom JavaScript attribute. So where do you put your code?

In this case there are magic snippets you can create to add your own code to the authentication-related pages (including JavaScript):

  • Account/SignIn/PageCopy
  • Account/Register/PageCopy
  • Account/RedeemInvitation/PageCopy

Keep in mind that these are generic snippets that will get dropped in the HTML, so you need to wrap any JavaScript in <script> tags.

Other Functionality Built in MVC

There are other areas in the Portal that are also built in MVC where you can’t put code in a Custom JavaScript attribute. For example, you won’t find Web Page records for Discussion Forums.

In this case, a technique I’ve seen people use is to put the JavaScript in the header or footer, and then look at the URL of the page to determine if they want their JavaScript to run or not. This is not ideal since then the JavaScript needs to be processed on every page load, although admittedly it’s not a huge performance hit, and you don’t have a lot of other options, since magic snippets don’t always exist.

Not All Web Templates Are Created Equal

In the forum post that originally inspired me the original poster wanted to customize the appearance of the search results page.

To do this, they wrote JavaScript (that was completely correct), and placed it in the Search Web Template. Nothing happened.

Well actually, something happened – a JavaScript error. Specifically, $ is not defined. This tells us that jQuery isn’t defined, or at least not defined when we tried to use it. Power Apps Portals includes jQuery, so why would we get this error? Because of where jQuery is included.

jQuery is included after the Header Web Template. And guess where the Search Web Template is rendered? That’s right – as part of the header. The name is a bit deceiving – you might think the Search Web Template is used to render the search results, but instead it is used to render the search box that appears in the header.

So once the original poster moved the code into the Custom JavaScript attribute of the Search Results Web Page, it worked as expected.

So the lesson here is that if you need jQuery, don’t include your JavaScript in the header.

The post Power Apps Portals: Where You Put Your JavaScript Matters appeared first on Engineered Code.