Tag: slds

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.

Simplifying usage of Salesforce Lightning Design System using NPM and Express

Using Salesforce Lightning Design System (SLDS) is a great and easy way to add some super nice styling to your app. It comes with some nice defaults and a responsive grid system like other frameworks lige Bootstrap. Where SLDS really shines is of course if you are already using Salesforce (I assume you’re already on Lightning right?!!?!?) or if you are going to. And again who isn’t. Anyways… Using SLDS makes your apps really look like Salesforce which is nice for Salesforce Lightning Components or for an app using Lightning Out to host Lightning apps in external applications.

I often use SLDS for another use-case which is quickly doing a mockup for a new Lightning Component. Doing it in SLDS can often be way quicker than making by hand from scratch or attempting to draw the component using Powerpoint or other tool.

Previously I’ve been using the download option for SLDS ie. grabbing the package of the website, expanding and copying into my app. Today I tried out the NPM solution as I often use node.js and Express when I need to mock stuff up. Installing SLDS is as easy as doing a “npm install @salesforce-ux/design-system –save” and you’re all set. Mostly. Problem is of course that the assets you need end up in the node_modules directory which is not exposed outside the app. The way I get around it is to add a static-rule to my Express server.js as follows:

const app = express();
app.use('/slds', express.static(__dirname + '/node_modules/@salesforce-ux/design-system/assets'));

Then loading SLDS assets into my app is as easy as:

<link rel="stylesheet" type="text/css" href="/slds/styles/salesforce-lightning-design-system.css" />

This works great if/when you post your app to Heroku as well and has the additional benefit of easy version management using NPM and package.json.

Salesforce Lightning Design System (SLDS) Activity Component and z-index

For the Lightning Components I’m developing for a customer I’m using the activity timeline component to show a chronologic timeline of “stuff”. However when I added the markup to my Lightning Component and ran it inside Salesforce the vertical bars were missing. What to do? Crack open the Chrome Developer Tools and inspect – but hey! Then the bars were there… Close Developer Tools and the bars were gone again. Hmmm… Seems to be a viewport height issues. But then again not…

After quite a lot of tinkering I figured out that the issue was actually caused by a z-index issue of the layer showing the bar. I had to add the below CSS to my styling. Please note that I’m using the “event” sprites and coloring. But the most important thing to pay attention to here is the z-index of the :before psudo class for the slds-timeline__media classes and the slds-media__figure.

.THIS .slds-media__figure {
	z-index: 2;
}
.THIS .slds-timeline__media--event:before {
    background-color: #a9a9a9;
    z-index: 1;
}
.THIS .slds-timeline__media--event:before {
    background-color: #ff6600;
    z-index: 1;
}

YMMV…

Salesforce Lightning Components and image dependencies

I am developing some Salesforce Lightning components at the moment as while Lightning Components are great they have a major drawback in my mind. Some background first… Salesforce Lightning is our “new” component based UI based on HTML / Javascript and components are automatically mobile ready and responsive. A Lightning Component is not a single “thing” but rather a folder with stuff that is a number of files named using a predefined format. The component name is the name of the folder – e.g. MyComponent. The actual markup goes in the component file called MyComponent.cmp. Besides the markup there is the client side controller (MyComponentController.js), CSS styling (MyComponent.css) and that’s basically it. There are few more potential files but they are not important for this post. All is well described on the web. What’s not included in the component is graphics that may be used by the component.

The way graphics are added to components a either by using the sprites supplied with the Salesforce Lightning Design System (SLDS), by using custom graphics or you can use the classic icons which are supplied by Salesforce. The latter are really not ideal as do not look nice as they look old and the colors cannot be easily changed. The issue with using custom graphics or the SLDS sprites is that the resources are kept in Salesforce as static resources which is great for performance as they are automatically loaded through our CDN but they are outside the Lightning component. So now a component is no longer self contained but has dependencies to other metadata elements. To make it even worse these dependencies cannot be declared for the component that the normal dependency detection doesn’work eg. changesets will not detect the dependency. Not good…

To solve this I’ve started to use base64 encoded images as they can easily be used in img-tags and may be embedded in either markup or in JavaScript. An img-tag can use base64 instead of an image reference as below. This solves the above issue as images are now fully contained in the component code or markup so no external dependencies are required. An easy solution to a complicated problem.

&ltimg src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAABHNCSVQICAgIfAhkiAAAAAlwSFlzAAAL" />

This

On Mac (and Linux probably) getting an image as a base64 encoded image for easily done using the base64 command and I normally cut lines to 80 characters as the developer console doesn’t handle looooooong lines well. Combining with sed can add the quotes and pluses to make it easier to get it into Javascript. A little tweaking if required but it is faster.

base64 -b 80 -i ./picture1.png
base64 -i Downloads/gold_star.png -b 80 | sed -e 's/^(.*)$/"1"+/'