<< Previous | Home

Salesforce week 25-27 and finishing this weekly thing...

Wow!! A half year has gone by. Half a year... Where did the time go? Over the last weeks I've gradually noticed that my view on being with Salesforce has shifted from being "something new" to being "how things are". On feeling at home in the organisation and that I know my place. Does new things come up sure but it's feeling less and less like every day brings something new, a new badge or a new process. I've settled into the #Ohana. This is also why I've decided to stop writing these weekly posts and go back to writing "normal" blog posts. I still have a V2MOM goal of blogging once a week on average over my first year and I'm no track to meet that goal.

That being said being part of the organisation has also taught me just how much we need more people - the right people. I think it's safe to say that we are constantly hiring so if you're looking for something new reach out to me and I'll be more than happy to talk and discuss what Salesforce is, which positions are open and how it's like working for Salesforce.

In 3 weeks I'll be heading off to my first off-site where the entire Salesforce CSG EMEA North will meet up in Barcelona for 3 days of training, networking and fun. Should be very nice disregarding that I'm flying out at 7am on Sunday and will probably go directly to the airport from a major party. Oh well - there's time to sleep on the plane.

Top 5 from my first 6 months

  • Develop on the new Salesforce Lightning and become quite good at it
  • "Master" Salesforce and become 5 times Salesforce certified
  • Bootcamp in San Francisco
  • Delivering real business value at my customer and doing it with Lightning
  • Working with very nice and talented people

Status after this week

Trailhead points: 85325
Trailhead badges: 100
Certifications: 5 (Salesforce Certified Administrator, Salesforce Certified Platform App Builder, Salesforce Certified Advanced Administrator, Salesforce Certified Sales Cloud Consultant, Salesforce Certified Service Cloud Consultant)

Tags :

Salesforce Lightning Component API change

As we get closer to Summer 17 we start using difference versions across production instances and sandboxes. This of course also leads to opportunities for differences in API's... I just found one such difference as I'd been developing some Lightning components on Summer 17 and got errors when trying to run them on Spring 17. In Summer 17 you can do the following in a client-side event handler to get the DOM element of the source component:

({
   react: function(component, event, helper) {
      const elem = event.getSource().getElement();
   }
})
This doesn't work in Spring 17 as the getElement method is not available. So find another way to accomplish whatever you are doing there...

Using component.find in Salesforce Lightning Components

When developing Salesforce Lightning Components you very often use the aura:id attribute on components to tag them and component.find to find them again. This works very well and is documented nicely in the documentation (Finding Components by ID). If however you tag a component using aura:id in an iterator you may not know how many resulting components will be on the page. The component.find method may return undefined (if no matching components), a component instance (if a single match was found) or an array of component instances if multiple components with a matching aura:id was found. This is fine but if you want to loop over any found component Javascript may give you a headache as the resulting variable may contain an array or an object instance. Hmmm... You can either using Vanilla Javascript to figure out whether it's array (or cheat and use $A.util.isArray) and write code for the array case and code for the single instance case --- or you can take the short route.

I always take the short route...

Say you had markup like this using an aura:iteration component to loop over a variable containg 0, 1 or many values.

<aura:iteration var="item" items="{!v.items}">
	<lightning:input type="checkbox" label="{!item}" aura:id="mycheckbox" />
</aura:iteration>

Contrast the approach using "isArray"

const cmps = component.find("mycheckbox");
if (!cmps) return;
if ($A.util.isArray(cmps)) {
    cmps.forEach(cmp => {
        // do stuff...
        cmp.set("v.checked", true);
    })
} else {
    // do stuff on the instance
    cmp.set("v.checked", true);
}
...to the approach of simply concatenating into an array... I find this much nicer, cleaner and it avoids the duplication of code between the single instance and array case. If I know there would always be at least one component it could even be done on a single line i.e. loose the undefined check on the second line. Javascript terse-ness heaven!!
const cmps = component.find("mycheckbox");
if (!cmps) return;
[].concat(cmps).forEach(cmp => cmp.set("v.checked", true));

! vs # in Salesforce Lightning Components

Often when you read tutorials on developing Salesforce Lightning components they all contains expressions when passing data and variables into other components. Like say you have an attribute as an array and would like to iterate over the elements:

<aura:attribute name="arr" type="string[]" default="['foo', 'bar', 'baz']" />

<ul class="slds-list--dotted">
<aura:iteration items="{!v.arr}" var="item">
    <li>{!item}</li>
</aura:iteration>
</ul>
Now this is a very simple example but it shows the point. This component shows a simple bullet list with items - when the array attribute ("arr") changes the list will recalculate and update. Often this is what you want but sometimes the array will never change. A better way to do this - especially with arrays as Javascript has not easy / performant way to see if an array actually changed - is to use # instead of ! in your expressions. # means that the expression will not automatically update when the attribute is changed which may speed things up considerably when there are many attributes and many components on the page. Fewer attributes to monitor for changes by the framework leads to better perfornance.
<aura:attribute name="arr" type="string[]" default="['foo', 'bar', 'baz']" />

<ul class="slds-list--dotted">
<aura:iteration items="{#v.arr}" var="item">
    <li>{#item}</li>
</aura:iteration>
</ul>
Another reason for using # instead of ! could be to control the data binding between parent and child components.

There is a nice article on the matter in the Salesforce documentation - Data Binding Between Components.

Salesforce week 24

Last week was all about getting the next component for my customer into production. For one of their business lines they had some very specific requirements for a search so we built a search from scratch. Now Salesforce comes with a built in fulltext search functionality but the customer only wanted results from a specific object type and a specific record type at that. So that's what we built. The solution was deployed on Thursday and have been running since. Main hickup in the deployment was some weird "cannot access childNodes of null" errors that kept surfacing from the Lightning component I built to display what search filters were in place. The component was basically just a wrapper around a number of arrays showing the filters as pills and showing a filter count. The markup was basically like this (c:Pill is simply a wrapper component for the pill):

<div class="filters">
    <div>{!v.filtersCount} filters added</div>
    <div aura:id="filters_expand" class="">
        <aura:iteration var="filter" items="{!v.accountDisplayObjects}">
            <c:Pill displayText="{#filter.displayText}" object="{#filter}" colorClass="orange" />
        </aura:iteration>
        ...
        ...
        <aura:iteration var="filter" items="{!v.geoDisplayObjects}">
            <c:Pill displayText="{#filter.displayText}" object="{#filter}" colorClass="lightorange" />
        </aura:iteration>
    </div>
</div>
We kept however getting the errors and I narrowed down the issue to being with the aura:iteration components and if multiple subsequence display object arrays were being changed after one another. The fix turned out - as always - to be very simple. I simply wrapped each aura:iteration component in its own span-tag.
<div class="filters">
    <div>{!v.filtersCount} filters added</div>
    <div aura:id="filters_expand" class="">
        <span><aura:iteration var="filter" items="{!v.accountDisplayObjects}">
            <c:Pill displayText="{#filter.displayText}" object="{#filter}" colorClass="orange" />
        </aura:iteration></span>
        ...
        ...
        <span><aura:iteration var="filter" items="{!v.geoDisplayObjects}">
            <c:Pill displayText="{#filter.displayText}" object="{#filter}" colorClass="lightorange" />
        </aura:iteration></span>
    </div>
</div>
Oh well another bug bites the dust and another lesson learned...

Besides this we got a new team member as another one of the existing team members is graduating into management. So now we also have a Salesforce Business Architect from the UK office. Nice.

What did I learn

  • Span your aura:iteration components
  • Troubleshooting Lightning Style
  • There is a reason for having a staging environment but make sure it contains representative data...

Status after this week

Trailhead points: 85325
Trailhead badges: 100
Certifications: 5 (Salesforce Certified Administrator, Salesforce Certified Platform App Builder, Salesforce Certified Advanced Administrator, Salesforce Certified Sales Cloud Consultant, Salesforce Certified Service Cloud Consultant)

Tags :

Salesforce week 20-23

Wow I'm behind on these... I'll have to sum up the last 4 weeks and get better at doing these.

At the end of March I made Trailhead Ranger! I'm very happy that the ambitious goal of making Trailhead Ranger by the end of March was accomplished. On the Wednesday night in the bar of my second home (Radisson Hotel in Stockholm) I earned the last badges to bring me over the line. Great! I hurried over to my V2MOM to complete that measure on my FY18 V2MOM. Check! Next up is getting started on my Certified Developer I certification.

I also received emails about certification renewal. Oh well...

Last week was of course the terrorist attack in Stockholm :( The truck hit the building just 100m or so from one of the Salesforce offices. So sad and frustrating why people cannot just agree to disagree....

What else? I've been head down in work finishing of the first release at my customer I have been a part of and working on new existing stuff. I already had one big component deployed to production and on next Tuesday my next big contribution is being rolled into production and I'm really excited about it. Both are Salesforce Lightning components and they are pretty slick. Really shows what can be done. Once these are out I promise to record a video and post it. I also have loads of experiences and new stuff about Lightning development to share here on this blog.

On a more sad note my on-boarding buddy Rasmus got a new role inside Salesforce and will be switching teams. I'm really excited for him but I'm sad to see him leave our team and my current project. He's really a nice guy and a super competent architect. Glad he's still part of the Ohana though.

What did I learn

  • Lightning, Lightning, Lightning
  • More Lightning
  • Funky quirks about picklists from SOQL now that all picklists contains both an alias and a value
  • APEX performs really really well

Status after this week

Trailhead points: 85325
Trailhead badges: 100
Certifications: 5 (Salesforce Certified Administrator, Salesforce Certified Platform App Builder, Salesforce Certified Advanced Administrator, Salesforce Certified Sales Cloud Consultant, Salesforce Certified Service Cloud Consultant)

Tags :

Case in point - why we have API limits

This week the customer I'm working for went live with the next phase of their Salesforce rollout. The phase includes a Contact Sychronization feature where Salesforce contact objects are synchronized to users mobile devices using their Google Account. The contacts are flagged either in bulk or specifically using a Lightning Component on the Contact Page, has Salesforce1 integration to allow users to perform and manage sync on the go as well as a delegation feature to allow other users to manage their synchronization settings on their behalf. Think managing partners etc...

Anyway we went live on Monday morning and Tuesday morning the news hit. We had hit the API limit. The API limit is a hard upper limit on the number of API calls any customer may do towards Salesforce from external applications. There are a number of factors deciding the actual limit such as user count, license types etc. but in this case the limit was 500.000 calls in a 24 hour rolling period. We were at 555.593! Not good and and it was only 9am. Hmmm what could be wrong?

After looking into the matter we found out that the culprit was - you guessed it - the Contact Sync. The actual sync component that does the reads from Salesforce and writes to the Google Accounts of the Contact Sync feature was set to run every 10 seconds and not every 15 minutes as planned. At this rate the customer would hit an estimated 20.000.000 (20 million) API calls in a 24 hour window. Not good. A simple reconfiguration and we were back on track.

Talking to the friendly people at Salesforce Support we were even given an extra allowance of API calls for the day and the customer were back in business.

But case in point - this is exactly why there are (API) limits. If you hit the limits you are probably doing something you shouldn't. Well hopefully that's why you hit the limit.

Tags :

Salesforce week 19

Another busy week where all focus was on getting our customer ready for the launch of their next release on 3 April. Again I've been a bit optimistic about my estimates but all it good and the customer is happy. They just signed an extension to our contract so we will probably be here until the end of the year. Great testament to the value we are providing. Next week I'm going to be two days in Stockholm and 3 days the following week in the week of the release. After that we have a short sprint of 2 weeks to complete a custom search component - again entirely in Lightning. Cool. Cool. Cool.

On the personal front I felt great joy when talking to my former employer. The last thing I did before I left them in November was deliver a project integrating the OnTime Group Calendar for Microsoft with the Danish national system for sending SMS reminders called NemSMS. Intravision is getting ready to sell the solution to the second customer which is great by itself but the potential customer has been in contact with the existing customer to gather experience with the system and their only comments were: "simple to use" and "just works". Great!! I have to make a mental note to do a write up of the solution.

What did I learn

  • Another busy week
  • Writing your work V2MOM makes you want to do it on a personal front but it may ruin my procrastination

Status after this week

Trailhead points: 80150
Trailhead badges: 82
Certifications: 5 (Salesforce Certified Administrator, Salesforce Certified Platform App Builder, Salesforce Certified Advanced Administrator, Salesforce Certified Sales Cloud Consultant, Salesforce Certified Service Cloud Consultant)

Tags :