Learn MOAR with Winter ’20 Release Highlights for Devs

Discover Winter ’20 Release features! We are sharing release highlights for Developers (and Admins), curated and published by Salesforce product experts, as part of Learn MOAR. Complete the trailmix by October 31, 2019 to receive a special community badge and unlock a $10 contribution to FIRST®.

Release Readiness Live is only about an hour long, and there’s no way we can cover all the things developers care about. So in the finest listicle style, I’d love to tell you about my five favorite developer-focused items from the Winter ’20 release. Ready to count off?

1. So long and thanks for all the UI, Aura

After years of faithful service, Aura components in the UI namespace are retiring. With a heartfelt thanks, let’s wish them a happy retirement! In their place, use their corresponding components in the Lightning namespace. Thus, UI:button (or Ui-Button) becomes Lightning:Button (or Lightning-Button) and so on. Now it’s not our style to just turn off things, so we’ve arranged for their retirement to begin in Summer ’21. After Summer ’21, they’ll still be present, but unsupported. We’re sad to see them go, but happy to report the Lightning namespace components are more than up for the task.

2. CSS components (also known as “dry up your CSS”)

If you’ve ever copy/pasted CSS from one Lightning Web Component to another, raise your hand. You too, eh? Well, now there’s a better way: starting in Winter ’20, you can create Lightning web components that contain reusable CSS rules. Here’s your roadmap to using this technology successfully:

Step 1. Create a Lightning Web Component that includes only the .css file. Put all your CSS in there. For example, let’s call our component ‘AmazingStyles’.

/* AmazingStyles.css */

h1 {
    font-size: xx-large;
}

Step 2. In any other component, when you want to use those styles, simply import them into the component’s .css file like this:

/* MyNewComponent.css */

@import 'AmazingStyles.css';

Step 3. There is no step three. No, really, it’s that simple. Once you’ve imported the CSS you can reference the styles the same way you would anywhere else. Even though MyNewComponent’s css file doesn’t define h1, the fact that it imports AmazingStyles.css that does, means it’s defined for your .html template to use. No more copy and pasting CSS around. Not for nothing, but this is another way in which Lightning Web Components are embracing web standards! For more details on the specifics of Lightning Web Component’s CSS components check out this documentation!

3. Do not pass go, do not collect $200; go straight to Sales

New in Winter ’20 is the ability for developers to use the navigation mix-in to direct users to an App, or a page specifically within an app. Developers have always had the ability to create buttons that took users to various parts of Salesforce. For instance, you could have a button that took users to their home screen. Another could take you directly to the Files or Chatter home pages. Now we can jump from one app to another. For instance, you could have a button that takes a user out of Sales and into Service, looking at the history of that account’s cases. Here’s the JavaScript for making just such a button:

import { LightningElement } from 'lwc';
import { NavigationMixin } from 'lightning/navigation';

export default class NavToApp extends NavigationMixin(LightningElement) {
  navigateToApp() {
    // Use the built-in 'Navigate' method
    this[NavigationMixin.Navigate]({
      type      : "standard__app",
      attributes: {
        appTarget: "Sales",
      }
    });
  }
}

The magic here is that you can now specify a type of standard__app and provide an appTarget key with the name or ID of the application ID. If you’d like, you can even go a step further, combining an appTarget and a pageRef to take users directly to a page within an app. For instance, this code would take you to a record page inside the LightningSales app:

{
  type: "standard__app",
  attributes: {
    appTarget: "standard__LightningSales",
    pageRef: {
      type: "standard__recordPage",
      attributes: {
        recordId: "001xx000003DGg0AAG",
        objectApiName: "Account",
        actionName: "view"
      }
    }
  }
}

4. .stripInaccessible();

If you’re a user of the static code analysis tool PMD, you know all about the warning to check Field Level Security (FLS) and Create/Read/Updated/Delete (CRUD) permissions before making a query.

You should definitely still check CRUD permissions, but with Winter ’20 we’ve added a new Security method, called stripInaccessable that will take care of clearing out fields that the executing user cannot see.

Here’s how it works: Calling Security.stripInaccessable takes two parameters — an AccessType and a collection of records. It returns a clone of the collection, with inaccessible fields stripped out. You can access the CRUD and FLS safe version of the collection by referencing the output’s getRecords() method.

public List<Account> demo() {
  List<Account> accountsWithContacts = [
    SELECT Id, Name, Phone,
      (SELECT Id, LastName, Phone FROM Account.Contacts)
    FROM Account
  ];

  // Strip fields that are not readable
  SObjectAccessDecision decision = Security.stripInaccessible(
                                            AccessType.READABLE,
                                            accountsWithContacts);
  return accountsWithContacts;
}

So why would you use this? Simply put, you want to write more secure applications that ensures a bug in your Apex code doesn’t accidentally leak sensitive information. By utilizing stripInaccesable() you can be rest assured that fields the current user doesn’t have access to via FLS will never be surfaced to the user.

5. Insights into Einstein Predictions

Once Einstein has created a prediction, Winter ’20 brings new information about how and why that prediction was made. Not only that, but when a prediction is made, Einstein fires a AIPredictionEvent platform event. If you write a trigger or create a process that fires on that event, you can attach additional logic to predictions. For instance, you might create a trigger on AIPredictionEvent so that when an opportunity is predicted to be at risk the AIRecordInsight records are inspected and, where business logic dictates, product specialists are added to the opportunity team.

What will you build?

I can only imagine what kinds of things the developers of our community will end up building with these features. I’m sure, however, that it’ll be made with DRYer CSS, FLS aware queries and beautiful, complex automated insights. We’d love to hear more about what you’ve built with these and other Winter ’20 features. You can always reach out to us via @salesforcedevs on Twitter and let us know what you’ve built! In the meantime, check out this new Trailhead content to get ramped up on other Winter ’20 features.

Leave your comments...

Learn MOAR with Winter ’20 Release Highlights for Devs