When you hire someone to work in your home as a contractor, you make sure they have the right credentials and licensing. But when you’re hiring a Salesforce developer for custom work, it’s not always so easy to tell which credentials are important to look out for.
The following pattern is fairly common in other technologies:
try {
doSomethingRisky();
} catch (Exception e) {
logException(e);
throw e;
}
This won’t work in salesforce. By rethrowing the exception (assuming it’s
not caught further up the call stack), the database transaction will
be rolled back - that includes whatever insert or update ws triggered in
logException(e). So how do we ensure that the logging occurs in a separate
database transaction? The answer is a platform event!
If you’re writing custom Lightning components you’ll eventually need to get a confirmation from the user before proceeding with some action. Perhaps you’ll need to ask approval before deleting a record, or maybe you’ll need final confirmation before launching the missiles. Either way - it’s going to happen and Salesforce isn’t helping you get the job done.
Apex leaves much to be desired when it comes to mocking callouts to external services. Use of the HttpCalloutMock interface requires that a test author configure mock responses for ALL callouts made through the course of a test’s processing, and this can be quite unmanageable in large or complex projects. There must be a better way… Enter the HTTP Mock Registry.
Frustrated with messy tests and abstraction leaks, we’ve devised a utility that provides a intuitive interface for mocking callouts declaratively as well as a foundation for more modular test suites whenever callouts are involved.
When developing using an SFDX Package Development Model there may be situations where valid code generates an error. We’ll take one small Apex/SOQL example today and use a simple workaround to get this code into the package.
While it’s nice that the Lightning Framework provides a way for Aura components to invoke Apex methods, the code required is a bit verbose. We can do better.
Being able to invoke methods and pass data between parent and child components is critical when building an application structure that is both extensible and easy to use.
One of the basic features of Lightning Aura components is the ability to nest components (components containing other components). Communicating from a Parent Component to a Child Component is easy with Aura.
The ability to mock out components is essential to writing quality tests, especially when you’re dealing with integrations or external API invocation. And let’s face it - the out-of-the-box Stub API provided in Apex is just plain awful. Here’s a lightweight utility I threw together to simplify mocking.