Beta of new Lightning Component Library included in Winter ’18

Was pleasantly surprised to see the beta of the new Lightning Component library being included in the Winter ’18 release. Quoting from the release notes (see page 533):

Find components more easily with the searchable component library. Preview the look and feel of components with interactive examples. To explore the new component library, go to https://<myDomain&gt; where myDomain is the name of your custom Salesforce domain. You can also continue to use /auradocs/ in your org. And the Component Reference section in the Lightning Components Developer Guide continues to be available to you. …snip… Let’s look at some of the highlights. Gone are the days when you had to imagine how a Lightning component renders and behaves in your browser. Many components now have interactive examples and source code for common patterns. You can also learn about how a component is used through a list of examples.

The component library is really for the built in base components what the auradocs at /auradocs/ is for your custom components and with the additional of all the new base components in Winter ’18 this is a nice addition.

Websockets in an Express node.js app on Heroku

Last night I was having an issue with websockets and TLS in an Express.js node.js app. My websocket was working just fine when developing locally over plain HTTP but when I deployed the app to Heroku I received an error as that app runs over HTTPS but the websocket was still plain HTTP (using ws:// instead of wss://). Hmmm…. I started digging into websockets over TLS and how that would work without any luck. So I asked around but then it dawned on me and I answered my own question… Sometimes finding the answer is all about the question you ask 🙂

So the main realisation is that TLS connections are terminated by the Heroku router and forwarded to a web dyno hence there was no need to listen for TLS based websocket connections in my app. Also remembering how websocket connections are created is important. A websocket connection is a normal HTTP connection which is then upgraded to a websocket connection. So the real solution was to understand how a web dyno in node.js using Express could share it’s port with websockets using a HTTP server and that the same HTTP server would be used for both HTTP transport and websocket connections.

The solution was as follows:

const express = require('express')
const http = require('http')
const WebSocket = require('ws')

const port = process.env.PORT || 8080
const app = express()
const httpServer = http.createServer(app)
const wss = new WebSocket.Server({
    'server': httpServer

So in essence:

  1. Create the Express.js app (but do not set it up to listen in a port)
  2. Create HTTP server in node.js passing in the Express.js app
  3. Create websocket server agin using the HTTP server as the server
  4. Make the HTTP server listen on the port provided through environment variable

Dreamforce 2017 Playlist Generator

Looking for sessions from Dreamforce 2017 I found a list of sessions in a speadsheet and for fun I threw together a quick app to provider a better overview, allow me to filter the list easily and generate playlists on Youtube for select sessions. The app is written in node.js, is available on Github and is hosted on Heroku at After you authorize the app for Youtube it displays the list of sessions and you can generate playlists.

As a good friend of me always says – YMMV… Use at your own risk.


Today I’ve published my first plugin to the SalesforceDX CLI. The plugin is called sfdx-l18n-plugin and allows you to change localisation settings for the user in the scratch org you create. You can query the current values, list the available values from the org and set new values. The plugin can return values in plaintext or as JSON for automation. Changing the org to run in Japanese using Japanese locale and the timezone from Tokyo is as easy as:

sfdx l18n:user:set -u japanese --locale ja_JP --language ja --timezone Asia/Tokyo

You can now easily create a scratch org and change it to run with the required locale, language and/or timezone.

The plugin may be installed from npm or linked from source after cloning from github. The video below shows the plugin in action.

The best way to learn a platform is to use a platform

Wow what a week it’s been. First week back from vacation and I’m diving right into a sprint of stuff that needs to be delivered to the customer. My task for the week has been develop a connectivity layer between Salesforce and Dropbox using OAuth. This task has taken me on quite a learning journey.

Now I’ll call myself quite a seasoned programmer but ever since joining Salesforce 9 months ago I’ve had to relearn a lot of stuff. A new programming language in Apex, new framework technologies such as Salesforce Lightning Design System (SLDS) and the Lightning Platform and the entire underlying Salesforce Platform which is enormous. There are just different ways to do stuff… Previously I would have had my choice of any language, technology and framework to solve the issue but now those are kind of given.

Just this afternoon as I was putting the final semi-colons in the core OAuth layer (Apex), the Dropbox specific OAuth layer (Apex), the business specific facade class in front of those layers (Apex) and the management pages for the integration (Lightning) I was reminded of an old quote from an old biochemistry text book of mine: “The best way to learn a subject is the teach the subject”. And that continues to hold true and is equally true when saying “the best way to learn a platform is to build on the platform”. I’ve learned much stuff about Apex and Lightning in the past week. All the cool stuff you can do but also some of the crazy stuff that falls into that “you have have to know that”-category. But for all those things it holds true that you have to spend the time to reap the benefits.

For now I’ll just say that although the Apex language has it quirks and the compiler is definitely showing age (and Salesforce knows this – a new compiler is being developed or at least that’s what I heard in a Dreamforce 2016 session) there is still much so much power in the language. Is there stuff you cannot do? Sure! But there are cool interfaces like System.StubProvider which I read and hear little talk about. The built in support to unit tests and mocking of HTTP requests is awesome and allows you to quickly and easily stub out calls to external services. The runtime screams with performance and I’m pretty impressed about the speed with which my code runs.

Good stuff!

So in closing – I have my OAuth layer done, unit tested and commited. I’ll surely be blogging about how to chose to build it so others may learn from it if they want to spend the time and learn the platform.

Flip Chrome flag to easily inspect TLS certificates (from Chrome 60)

As a developer – or a security conscious user – you may want to inspect TLS certificates from time to time. However inspecting them in Chrome is hard as access to the certificate hierarchy dialog has been tucked away in the Developer Tools. Happily Chrome 60 has added a flag to add an easy to reach option back to the TLS dropdown in Chrome.

Please note that manually editing Chrome browser flags may mess up your browser – don’t say I didn’t warn you…

In the below video I show you how…

Developing Salesforce Lightning Components that are visible at design time but not at runtime

So this can clearly be labelled as a “Lightning Lesson from the Field”. As you start to develop more complicated Salesforce Lightning applications – and why wouldn’t you – you as I have done start seeing great power in hidden components. By hidden components I mean components that contribute code or does “something” but which does not have a UI. Thes are very easy to do but have a big drawback as they are also invisible at design time making them near impossible to find the Lightning AppBuilder. To work around this I’ve come up with a hack that has proven itself very useful.

By using a combination of two simple attributes and 3 lines of JavaScript I can make the component markup visible at design time but invisible at runtime. Or if I need to toggle it on for runtime as well using an attribute I can set from the Lightning AppBuilder.

The video below goes more in depth and illustrates the concept. Happy coding.