.png)
.png)
JavaScript is the coffee-based (not really) programming language that forms one of the three fundamental magics underpinning all the websites we use daily and is responsible for the web revolution that has made things like Salesforce such an integral part of how we do business and lead our lives.
So JavaScript is an important part of the web, but what about Salesforce? What about our favourite platform, Salesforce, where can it be found? You may have heard about the client-side controller found in Lightning components (both Aura and LWC) and you’d be correct!
The primary place we write JavaScript on the Salesforce platform these days is within custom components, but it doesn’t stop there.
Visualforce probably is a place you’d think of, you’ve probably heard or written Apex controllers for those, so they don’t use JavaScript, right? Not so fast! Visualforce’s main technology is definitely the Apex controller, but JavaScript can be used to augment the user experience into something much more modern and enjoyable.
Think about your favourite AppExchange package, any Visualforce pages there are probably utilising JavaScript to give you the experience that gives it its place on your must install list.
Despite seeming like one of the simpler aspects of programming, proper variable naming can have some of the greatest impacts when producing code that won't induce hair ripping emotions in several months' time.
While these bullets may seem simple, mastering them is a very difficult skill. Don’t be afraid to ask a friend or colleague to double-check your names after you’ve written them, it’s a great way to practice!
You might be thinking, “right now I understand variable naming, so I should just apply the same to functions, right? Functions are just variables that do something after all” and you’d be right!
For functions, we want to follow the same basis as variable naming, but with an additional aspect thrown in. Our function names should start with an action e.g. submit Form.
This makes it much easier at a glance to identify a function and draws a mental separation between functions and variables, especially when you’re passing functions around as variables in callbacks!
Now that we’ve mastered variables and function naming, we move on to one of the more exciting parts of JavaScript and component design, events!
In case you think events are just things you drink at, in JavaScript land they are signals we use to alert other pieces of code that something has happened and that it should respond to it.
These signals play a key role in reacting to user interaction (e.g. clicking a button), or for other code to react to something that has occurred when building standalone components.
Aura and Lightning Web Components (and by extension Visualforce and the wider web) run on two different methodologies for sending and receiving events.
These are traditional events (component events in Aura) and Publisher Subscriber events (Application events in Aura).
While the result is the same, they have fundamental differences in how they're made and how they should be treated.
Traditional Events (Component): These events are used to communicate in a Child -> Parent manner and are highly predictable in nature. They should be named entirely in lowercase (e.g. on right-click).
You attach them to components and can prevent their propagation if something's not quite right (e.g. stop submitting an invalid form).
Publisher Subscriber events: Used when we want to communicate with sibling components - avoid using these where there is a child -> parent relationship.
Requires custom code to handle the communication and firing of event responses - take a look at this trailhead for a great starting module).
Handlers must unsubscribe when done - failure to do so can lead to unforeseen consequences when a component reacts to an event after it is no longer required to do so.
Example of a traditional event in a Lightning web component - This event could be handled with an on clicked event handler.
Comments in code are a hotly debated topic, with people saying you should add as many as possible and others saying they should be avoided entirely. In reality, the best practice is somewhere in between.
If you answer no to any of the above three questions, a comment may be a good idea! Now then, that comment should just reiterate what's going on in the code, that’s a bit pointless since we could just read that, instead, it should be a simple description of the why behind the code, not the what.
To put it another way, a good comment describes why something is the way it is and isn't just a description of what is there.It’s super important to remember that we don't write code for the computer to understand, we write it for our fellow humans, so keeping everything nice and clear without any ambiguity is key to writing good code.
Curly braces have a love-hate relationship with programmers, some love their verbosity and explicitness and others hate them for being too verbose!
In programming languages such as JavaScript, we always want to include them for any if statements or loops. Failure to do so is a surefire way to introduce a ticking time bomb into your codebase that will be a real pain to debug when it rears its head.
For a good explanation and examination of this, pop a quick search in for “Apple goto fail” which was a security bug caused by skipping some curly braces.
Sticking debug statements into our code is a really useful development and debugging tool for us developers while we are producing solutions.
Sometimes it's really useful to print something about our code to review at our leisure.While there is nothing wrong and is actually encouraged, with included debug statements while we develop, these should be removed from any code that goes into a production environment (NodeJs is an exemption to this!).
Sticking details about the inner workings of our code in an easily accessible format opens up the opportunity for somebody with nefarious intentions to get a good glimpse into how our components work, and how to exploit them.
For example in Google Chrome, it’s trivial to modify the code of Aura components on a page and our debug statements may provide inspiration for an attack vector.
Let’s keep things safe and use the browser’s debugging tools and breakpoints when in production (or use a custom logged if you’re feeling fancy!).
Another nugget of advice when using debug statements is to only log primitive values - so Strings and Integers, rather than objects as a whole. Without getting into the technicalities behind this, logging objects to the console creates a reference to the object that was logged.
This means that the rubbish collector (the thingy that clears up memory) will see a reference to the object and keep it around, wasting potentially valuable RAM!
As Well as that, in Aura components, it can prevent the component from being destroyed, keeping all of its event handlers active, those Application events powering your component can easily create a headache when they fire for no apparent reason due to a ghost component haunting you.
Hopefully, you feel empowered (pun intended) to write cool, clean JavaScript code going forward that saves you time in the future. Next time you review some code and think “This is pretty good!” and realise it’s your own, give yourself a pat on the back and share the knowledge you’ve learnt.
By Alexander Crisp, former Salesforce Developer at EMPAUA.
