Aura Archives - Michael Soriano

How to create simple Pagination using Lightning components and Apex

Michael Soriano — Wed, 17 Apr 2019 21:37:17 +0000

Let’s build something every web application needs in their results page: Pagination (aka Paging). This technique is necessary so we don’t bombard our users with all the items in our result page. Instead, we show them in “chunks” or “sets” of results. This is a very simplistic example – all we’re doing is a set of buttons that have page numbers on them. Once clicked, it will go ahead and fetch the results in that page.

A peak at what we’re building is shown below:

Disclaimer: I’m assuming you know how to work with Lightning components. I also hope you know JavaScript and HTML. There’s no downloadable code – you just simply have to follow along.

Currently, there are no built in lightning component for this type of functionality. Instead, we’re using lightning:radioGroup with type “button”. This will setup our page links nicely in a row, with clickable links and active/inactive states already added.

Ready to get started? Let’s begin.

Our Apex methods

First and foremost, let’s start with the backend. If you guys are familiar with SOQL – which is Salesforce’s version of SQL, you know that we have the 3 necessary keywords for our paging to become possible: ORDER BY, LIMIT and OFFSET.

ORDER BY – allows us to determine the order of our results. This makes it so that our result set will always follow a standard sort. This will make our paging deterministic and predictable.

LIMIT – allows us to limit the results in the page. So when we click a page – we will only show these number of records.

OFFSET – allows us to “skip” the records that we will not show. We’re “skipping” these records and start from the first record after our offset.

I’m building a method that I can call from my lightning component. Note the “@auraEnabled” keyword. The function then takes 2 arguments: ofst and lmt. What it returns is simply our queried object, with the results using SOQL.

@auraEnabled
public static List getNewHires(Integer ofst, Integer lmt){
	List onBoardingList = [SELECT
						Id,
						Name,
						FROM
						OnBoarding_Data__c
						ORDER BY Name DESC
						LIMIT :lmt
						OFFSET :ofst
						];
			return onBoardingList;
		}

Now we need another method to find out the total number of records there are in the database.

@auraEnabled
public static Integer getTotalItems(){
	Integer total = 0;
	String query = 'SELECT Id ';
	query += 'FROM OnBoarding_Data__c';
	List onBoardingList = Database.query(query);
	total = onBoardingList.size();
return total;
}

The above simply queries our same custom object, returning the total number of records.

My application uses a custom object for “on boarding” employees – so you will see OnBoarding references all through my sample code.

Our simplified Apex is ready. Let’s move to the front end.

The HTML

In our HTML, we’re setting up 4 attributes that we need for our pagination. You should be able to tell from their names what they’re for. We’re also setting the default values in them. Note the “pagesArray” attribute – is an array that will house the page objects that we need for our paging system.

The above is the output of our code. You see div wrappers that have Lighting Design System classes, along with aura directives to process our code. Such as our use of the aura:if – which checks the length of our pagesArray. Meaning – we’re only showing paging if there are pages to show.

You see our use of lightning:radioGroup. We also pass in “value” and “options” – which corresponds to our attributes we defined above.

We also have an onchange attribute calling our “doPaging” handler. We haven’t built this yet, but is coming up.

Let’s move on to our JavaScript.

The JavaScript

Let’s get down to business. We have our markup, we have our Apex waiting in the back end. All we need to do is tie them all up together. We do this with JavaScript – ideally in our helper file.

First, we create a “buildPaging” method. This method ideally fires on page load. But you can also call this method if you have some kind of filter mechanism.

buildPaging : function(component,event, helper){
		helper.callServer(component,'c.getTotalItems', function(response){
			var ttl = response;
			var lmt = component.get('v.limitPerPage');
			var pages = Math.ceil(parseInt(ttl) / parseInt(lmt));
			var pagesArray = [];
			for(var i=1; i<=pages; i++){
				var obj = {};
				obj['label'] = i.toString();
				obj['value'] = i.toString();
				pagesArray.push(obj);
			}
			component.set('v.pagesArray',pagesArray);
		},{});
	},

First thing you’ll see is our helper.callServer() method. This is basically our means of calling our Apex code above. To find out more about callServer() – see the post “Call Apex from Lightning“.

So from our total records, we can build our pagesArray. We call our getTotalItems from the backend, then we grab our “limitPerPage” attribute. We divide the total by the limit, and we’re doing a “ceil()” on it. This is so that we get a whole new page, even though there’s only 1 item in it.

Lastly, we’re building our pagesArray – but passing in the label and the value as an object.

Note the “toString()” method it. This is due to a bug with
lightning:radioGroup. It can only process strings. If you pass an integer – you would have to click it 2x to take effect! Whatever.

Let’s move on to our handler.

doPaging : function(component, event, helper){
		var lmt = component.get('v.limitPerPage');
		var val = event.getSource().get("v.value");
		var offset = parseInt((val-1) * lmt);
		component.set('v.curpage',val);
		component.set('v.offset',offset);
		helper.callServer(component,'c.getNewHires', function(response){
			if(response.length > 0){
			component.set("v.newhires", response);
				}else{
					console.log('no records');
				}
		},{'ofst' : ofst, 'lmt' : lmt});
	},

So first you see, lmt – which is static (set in our attribute). Then you see “val” – which is what was clicked. We get that number and multiply by the limit – so we get our offset.

We then call our Apex method with those parameters:

{'ofst' : ofst, 'lmt' : lmt}

Inside our callback, we simply set our response to the newly fetched data from our server.

Conclusion

And that’s about it. We’ve just built ourselves a very simplistic pagination using Lightning and Apex. There are many things we can do to enhance our code – like having a “previous” and “next” buttons – but I’ll leave that up to you.

Feel free to comment below.

The post How to create simple Pagination using Lightning components and Apex appeared first on Michael Soriano.

Repeating Inputs in Salesforce Lightning Components

Michael Soriano — Fri, 23 Nov 2018 01:40:14 +0000

What we’re building: An input field that can be duplicated (repeated) as part of a form. This is particularly useful when you want to capture information that you want to separate in different lines, and you don’t really want to use a textarea.

This way, we’re forcing our user’s to enter a value per input. In this scenario, we’re trying to grab a list a set of File Paths.

We’re using Lightning components, which is the framework Salesforce is using for their UI. A screenshot showing the pieces of what we want to accomplish is shown below.

See that we have inputs, a “More” link, and a “minus” sign – so we can remove the input directly.

Ready to build? Let’s begin.

Let’s start by defining an attribute in our .cmp file. Let’s call it “fileShares”, and its a “List” type. In Salesforce – a “List” is a an array in JavaScript. Here is how it looks

Our array will hold a set of Objects, which reflects each of the input that we’re building.

Now we’re ready to create our markup. We’re using lightning:input – which is nothing but an “input” in HTML. We give it several attributes, which is defined below:

aura:id with a value of fileShare.id
value – with a value of fileShare.value
label – with a value of fileShare.label
class – with a value of “fileShares” (nothing to do with our object, but simply for styling)

We also want to wrap it inside a DIV with a class of “fileSharesItem“.

Now let’s wrap it inside a aura:iteration tag, which is how you loop through items in Lightning.

Notice that we’re looping through v.fileShares – which is the aura:attibute we first defined. We prefixed it with a “v.”, because in Lightning – this means “value provider”. We also have two important attributes in our iterator: var and indexVar. Our variable “fileShare” declared in “var”, while “indexVar” holds the index – we’re calling “iVar” (the counter).

Let’s move on to our controller. This is the JavaScript file, that we first initialize the value of v.fileShares. Add the code below (ideally inside an initialize method during load).

component.set('v.fileShares', {'label': 'Enter Path', 'value': '','id': 'fileShare1'});

See that we’re using component.set() – and passing two parameters. The first is the property to set, then the value. In the case above, we’re setting up the ‘v.fileShares’ with an object. This means that we want just one field to show when the page loads.

Adding an Input

Let’s add the button that when clicked, a new input will be added to our form. Lighting supports data binding. This means that since we’ve binded our loop, all we worry about is the data. Remember our aura:iteration tag?

addMoreShareHandler : function(component, event, helper){
	var inputs = component.get("v.fileShares");
	var id = inputs.length+1;
	var obj = {
		'label': '',
		'value': '',
		'id': 'fileShare'+id}
		inputs.push(obj);
		component.set("v.fileShares", inputs);
},

Try it out and you should see our input repeated. Pretty neat right? How about removing the input? Let’s tackle that below.

The Remove Button

Let’s create an anchor tag – with a custom click handler. Also, let’s add a couple of attributes – so we know which one to remove. These attributes have to start with data- which is also known as “data-attributes“. I’ll explain more in our handler.





Now in our handler, we simply start with event.preventDefault() – which stops the link from behaving like a normal link. We don’t want the page to jump and refresh upon clicking.




Next, we grab the event, along with a property called currentTarget. What the currentTarget holds is information about what anchor tag was clicked.




So to access “data-idtoremove“, we do “dataset.idtoremove“



removeShareHandler : function(component, event, helper){
		event.preventDefault();
		var selectedItem = event.currentTarget;
                var idtoremove = selectedItem.dataset.idtoremove;
		var inputs = component.get("v.fileShares");
		for(var i=0;i




Then we loop through the inputs once again – by grabbing it from our component. We use .splice() to remove it from our array of objects.
Finally, let’s make the styles for our links.



The CSS:



For the remove link, we’re really trying to make it look like a “minus” button. We’re doing that with border-radius: 50%, along with a background color and a faint box-shadow. The rest of the CSS is mainly for positioning and sizing.



.THIS .slds-form-element.fileShares {
  margin-bottom:-5px;
}
.THIS .fileSharesItem {
  position:relative;
}
.THIS .removeShare {
  position: absolute;
  z-index: 999;
  right: -8px;
  top: 15px;
  border: 1px solid #ccc;
  width: 21px;
  line-height: 17px;
  padding: 0 0 2px 0;
  text-align: center;
  border-radius: 50%;
  font-size: 22px;
  background: #fff;
  box-shadow: 2px 2px 0 #e9e9e9;
}
.THIS .removeShare:hover,
.THIS .removeShare:active,
.THIS .removeShare:focus {
  text-decoration:none;
  background:#ebebeb;
}



Finally, we’re setting some hover styles by using :hover, :active and :focus also known as “pseudo selectors”. We simply want the cursor to change into a pointer, along with a subtle background change.
The final output:









So there it is. We just made a quick set of repeating inputs in Lightning. This also is a good crash course into Salesforce’s shiny new framework – which is gaining more popularity in the world of enterprise application development.




If you find this tutorial useful, or would like to see more – leave your comments below.
The post Repeating Inputs in Salesforce Lightning Components appeared first on Michael Soriano.



Let’s build a Map Application using Leaflet and Lightning Components
Michael Soriano — Sat, 15 Sep 2018 23:57:59 +0000

Salesforce’s Lightning component system is quite a robust framework where you can build full pledged single-page applications in a heartbeat. I especially like it’s built-in SLDS (styles), so all you have to really think about is the logic of your application. In this walk trough, we’re building a real life map application with Lightning. 



We’re using Google Places for our city lookup, as well as Leaflet for our map and finally Chatter for our chat component.




The goal is to have pins on the map – which is on the right side of our page. These pins are also shown in a list format on the left hand side of the page. Once a pin is clicked, the list on the left hand side is replaced by the pin details, along with the ability to chat about that specific pin directly below. When the “Close” button is clicked, the list re-appears, as well as the map zooms to its original view.




The same behavior is achieved when the pin on the map is clicked.









We also have a custom form, that allows us to add a pin right in the same page. The form has an auto suggest field for the cities.




Note that this is going to be a high level tutorial. You should be well versed in Lightning Components and JavaScript to follow along. A working knowledge of Salesforce is also needed.




Read to get started? Let’s begin.



Setting things Up



Before we can actually start coding, let’s back up and think about what we need. We will need a map software.  We need to store the locations in a custom object in Salesforce. And we need an Apex class to fetch these records for us. Seems simple enough? Let’s continue.




Static Resources




We’re using Leaflet – an open source map software which allows us to build a map on the page. All we need to do is pass it an array of locations (Longitude + Latitude) and Leaflet will populate magically. We also need LeafletMarkerCluster, an add-on to Leaflet, which allows us to bundle our pins together. This prevents the ugly grouping of many pins together.




So add these two zip files as static resources to Salesforce:



Leaflet
LeafletMarkerCluster








Custom Object




Each pin on the map is a record from a Custom Object in Salesforce. Let’s call ours “Pin”. Go ahead and build that custom object with the fields shown below.





You also might need to enter a few records. Since we’re dealing with coordinates, you will need to Google maps and grab this information. Don’t worry – this is just for the prototype. We are building our own custom form – that will take care of all this information for us.




The Apex Class




An Apex Class can behave sort of like a hash table that can hold our functions. This is how we’re going to interact with data from our Lightning components. Go ahead and create a class called “Pin”. Let’s add a method in there that grabs all of our Pins as well:



public with sharing class Pin {
    public static List getPins(){
        String sql = 'select Name, City__c, Lat__c, Long__c, Content__c, 
        Country__c, Region__c, Continent__c from Pin__c ORDER BY CreatedDate  
        DESC';
        List PinList = Database.query(sql);
        return PinList;
    }
}



Above is a class that has one static method “getPins“. This means that we don’t have to instantiate the class to use the method. The @auraEnabled declaration also make it callable directly from our Lightning components.




Component




Once that’s done, go ahead and create a Lightning component – let’s call ours “Pin“. Open pin.cmp and add the code below:





    
    
    
    




You will see that all we’re doing is setting our static resources up in our component file. We’re also doing controller=”Pin” in our component declaration. This means that we’re going to create an Apex class called “Pin”. We’ll get to that later.



Also note we have afterScriptsLoaded=”{!c.jsLoaded}” in our lightning scripts tag.  This is because we want the function jsLoaded to run as soon as our scripts are loaded. We don’t have this function yet – so loading the page will cause an error. We’ll get to this function soon.



Let’s continue building the markup.



Still in our .cmp file, after our scripts and styles – add our markup below :






        
            
            
        

        
            
        

 



The “aura:attribute” named “pins” is simply a holder for the pins we’re grabbing from the controller. 



More on this later.



The “aura:attribute” named “singlePin” is also a holder – for a pin that’s in focus. Again, more on this later.



This sets up our page. We’re splitting the page in two, one column is smaller (size_1-of-3) and the other bigger (size_2-of-3). We’re using built in Salesforce classes, with the prefix “slds”, stands for Salesforce Lightning Design System. In case you’re not familiar with it – it’s sort of like Bootstrap and React fused into a single framework.



The Map



So we’re ready to load the page and initialize our Leaflet map. We have our temp data in our custom object, we should have our component – along with the JavaScript files in place. Let’s write the jsLoaded() function (this is called when our scripts are done loading):



jsLoaded: function(component, event, helper) {
	var mapOptions = {
		zoomControl: true,
		zoomAnimation:false, //fixes the error when zooming in...
		markerZoomAnimation:true
	}
        var map = L.map('map', mapOptions)
        map.setView([48.85661400000001, 2.3522219], 2);
        map.scrollWheelZoom.disable();
        helper.map = map;
        L.tileLayer('https://server.arcgisonline.com/ArcGIS/rest/services/World_Street_Map/MapServer/tile/{z}/{y}/{x}', {attribution: 'Location'}).addTo(map);
        helper.callServer(component,'c.getPins', function(response){
        	component.set('v.pins',response);
        	helper.buildMap(component, event, helper, response);
        },{});
	}



Okay, a lot going on here. We’re setting some map default options (for more info on Leaflet, see their documentation).  We also have a very important helper function called “.callServer()“. This function is responsible for making the call to our Apex class, and returns our data. Note that I talk about callServer in a previous post. Simply add this function in your PinHelper.js file and that should be good to go.
Inside our callback we’re setting the v.pins in our .cmp file – which is an array of objects that came back from our server.



Right after we have a function called .buildMap() – which is a pretty big function and discussed in detail below.



The Map



So our pins our fetched from the server. I don’t know if you remember, that we are using a Leaflet add-on called LeafletMarkerCluster – which is what does the clustering of the pins – that are in the same proximity. What this does is – it creates a nice visual – the number of pins in a specific grouping, that you can click – and it will zoom in further to show the pins.



It also has a nice “spider” effect – for the clusters – which is really cool:




So what we need is a way to group our pins. Notice our custom object earlier – we have a field called “Region”. A region is similar to a “State” in the United States. So every pin that share the same region – will be clustered. Make sure your test data have pins that have the same region, and some that don’t.



Don’t worry – we don’t have to figure out what region our pins need to be – remember we’re building our own form.



The .buildMap() function



Now let’s dig in to the actual code that adds and groups the pins to the map. Open PinHelper.js and add the code below:



map : {},
mapLayers : {},
markerGroups : [],
markerList : [],
buildMap : function(component, event, helper, response){
        var map = helper.map;
        function onMarkerClick(e){
            //TODO: ADD LOGIC WHEN MARKER IS CLICKED
        }
        function onlyUnique(value, index, self) {
            return self.indexOf(value) === index;
        }
        function popupHtml(pinName){
            return '' + pinName + '';
        }
        var markerGroups = helper.markerGroups;
        for(var y=0; y




First, let’s set some variables in our helper (lines 1-4). These will act as a container as we pass them around from our controller to helper and vice versa.



Then the actual buildMap() function. We have gone through our pins and determined the unique regions and stuffed them into helper.markerGroups. Now starting in line 39, we loop through each of pin and add them to the map – according to their respective groups (region). Passing along the necessary options for each pin.



Your map should now load with the clusters and the pins.



The List of Pins (Left Side)



On the left side of the application – we show all of the pins – sorted by latest entry. Remember that we set our pins as a component attribute in our jsLoaded() function? Now all we need to do is loop through this in our component. But first, we have to check if there’s a singlePin – why you ask? This is to determine if we clicked on a marker on the map OR we clicked on any of the item in our list (which we’re still building).



We do this by using the aura:if directive.



The code below goes into the left hand section.




	
		Close
		 {!v.singlePin.Name}
		 
			{!v.singlePin.Region__c},  
			{!v.singlePin.Continent__c}
		 
		 
			 
		 
		 
		 
	
	
		Locations
		
		
			{!pin.Name}
			
				{!pin.Region__c} 
				{!pin.Country__c}
			
		
		
	




Let’s look at the singlePin scenario first – which is when an item is clicked. We are simply displaying some data from the singlePin – along with a button to close it (this .closeSinglePin() is not built yet). Then notice the use of  forceChatter:publisher and forceChatter:feed. These components are built in to Lightning – all we need to do is pass it a Id – and voila!



This will display our single pin nicely – along with a Chatter component right below it.









For the list, you see how we wrapped each pin as a lightning:button? That’s because we can click each item and something will happen. We have a c.markerClick handler on each item that we haven’t built yet.
The rest is simply markup of the pin details. Let’s create that handler.



markerClick : function(component, event, helper){
	var markerId = event.getSource().get("v.name");
	var marker = helper.markerList[markerId];
	var markerGroupId = marker['__parent']['_group']['_leaflet_id'];
	var parentChildCount = marker['__parent']['_childCount'];
	if(parentChildCount > 1){
		 for(var i=0; i




Remember, each item in our list – when clicked, will have the same behavior as clicking the pin (marker) on the map. So the above code is simply a trigger (using marker.fire()). But the check before that is to determine – if the marker is inside a cluster. If it is – we zoom to the layer first (using .zoomToShowLayer()), then fire.



Also, remember that we don’t have any behavior yet in when we click our pins (we have it as a TODO in our .buildMap() function above). Let’s go back and create that now.



function onMarkerClick(e){
	component.set('v.singlePin',{});  //resets to {}
	var id = e.target.options.alt;
	var latLong = e.target.getLatLng();
	if(e.target['_preSpiderfyLatlng']){
		latLong = e.target['_preSpiderfyLatlng']
	}
	map.setView(latLong);
	var pins = component.get('v.pins');
	for(var x=0; x




The handler above reset’s the singlePin to an empty object. Then we get the lat and long from the marker (we get it from “e” – or the event). We set the view on the map according to the coordinates.  Then finally – we loop through our pins – and set the v.singlePin into the one clicked.



Lastly, the .closeSinglePin() function:



closeSinglePin : function(component, event, helper){
        var map = helper.map;
        var defaultChatterFeed = component.find('defaultChatterFeed');
        var singlePin = component.find('singlePin');
        $A.util.removeClass(defaultChatterFeed, 'slds-hide');
        $A.util.addClass(singlePin, 'slds-hide');
        component.set('v.singlePin',{});
	map.setView([48.85661400000001, 2.3522219], 2);
        map.closePopup();
    },



The above simply hides our Single Pin and Chatter, resets the singlePin variable, then resets the map.



The Form



Finally, we come to the data entry section – where it will make it easy for us to add pins to our map. This form will have the necessary fields for our custom object – but most importantly, the auto-suggest field – that will auto populate the longitude, latitude, region etc.








I wrote a tutorial about this Auto-suggest field – using Google Places API, so I’m not going to get into that code. I’m simply going to go through the rest of the logic – that makes our form.



First off, we’re showing our form in a modal. Still in the same component, let’s add this to the lower section of our .cmp file:



Add New




	
		
			
			Add New Pin
		
		
			
				
				
				
					{!validationError}
				
				
				
				
				Content
				
				
				
					
						
							
							
								{!prediction.description}
							
							
						
					
				
				
				
				
				
			
		
		
			Submit
		
	







The lightning:button in the beginning, is what opens up the modal. It’s up to you how you want to show this button, and who to show it to.



The next three lines you’ll notice that we’re setting some new attributes. Again, these act as a containers for the variables we’re using in our component.



The SLDS dialog box contain a close button, a header, a footer  and a backdrop. The close button triggers a function closenewPin() when clicked. We’ll get to this later. Then we have a validation error list, then the form fields.



The “City” has an onchange handler called getCities() – which grabs the predictions from our Apex class. Again this was in a previous tutorial and find out how it’s done there.  The lightning:input fields that have a class “slds-hide” – are hidden fields. These fields are automatically filled – and will require no user interaction.



Finally, the lightning:button that takes care of saving the record.



Oh, we also have lightning:notificationsLibrary at the very end – which is Salesforce’s toast notification. We use this for messaging when successful.



Saving the Record



First let’s take care of the entering our record. Open the controller and add the method “saveRecord” below:



saveRecord : function(component, event, helper){
	var newPin = component.get('v.newPin');
	var str = JSON.stringify(newPin);
	//validation
	var errors = [];
	if(!newPin['Name']){
		errors.push('Name cannot be empty');
	}
	if(!newPin['City__c']){
		errors.push('City cannot be empty');
	}
	component.set('v.validationErrors', errors);
	if(errors.length > 0){
		return false;
	}
	helper.callServer(component,"c.savePin",function(data){
		helper.callServer(component,'c.getPins', function(response){
			component.set('v.Pins',response);
			component.set('v.newPin',{});
			helper.buildMap(component, event, helper, response);
			helper.closeModal(component, 'newPinModal');
			helper.showToast(component, 'success', 'A Pin has been added.');
		},{});
	},{"strsRecord" : str});
},



This function gets called as soon as the user clicks the “Save” button. First, we do some validation – and see if our required fields are filled in. If not, we set the validationErrors array up and exits.



Otherwise, we do a .callServer() twice. First to save the pin – and inside it’s callback, we do another .callServer() to get all of the pins. This is so that once we add a new pin – it grabs the new set of pins – so we can see it right away on the map. Remember I discussed about the .callServer() function in “Call Apex from Lightning components“.



This is the part that actually does the saving to the database. Add this to your Apex class – as another method:



@AuraEnabled
public static Pin__c savePin(String strsRecord){
	Pin__c strsRecord2 = (Pin__c)JSON.deserialize(strsRecord,Pin__c.class);
	try{
		if(strsRecord2 != null){
			insert strsRecord2;
		}
	}catch (Exception ex){
	}
	return strsRecord2;
}



Finally, we call .buildMap(), .closeModal() and .showToast(). You get what those functions are doing. Let’s add what’s missing in our helper. Open PinHelper.js and add the code below:



closeModal : function(component, modal){
	var cmpTarget = component.find(modal);
	var cmpBack = component.find('Modalbackdrop');
	$A.util.removeClass(cmpBack,'slds-backdrop--open');
	$A.util.removeClass(cmpTarget, 'slds-fade-in-open');
},
openModal : function(component,modal){
	var cmpTarget = component.find(modal);
	var cmpBack = component.find('Modalbackdrop');
	$A.util.addClass(cmpTarget, 'slds-fade-in-open');
	$A.util.addClass(cmpBack, 'slds-backdrop--open');
},
showToast : function(component, variant, msg){
	var toastSettings = {
		"title": variant,
		"message": msg,
		"variant" : variant,
		"mode" : "dismissable"
	}
	component.find('notifLib').showToast(toastSettings);
},



The helper functions above are pretty self-explanatory. For further explanation – especially about the utilities available in the $A object – refer to this question in StackOverflow.



closeNewPin : function(component, event, helper){
		helper.closeModal(component, 'newPinModal');
},
openNewPin : function(component, event, helper){
	helper.openModal(component, 'newPinModal');
},
closeSinglePin : function(component, event, helper){
	helper.closeSinglePin(component, event, helper)
},



Lastly, the above methods are in our helper, but we need to access them using our controller. Simply add the code below to our controller:



closeNewPin : function(component, event, helper){
		helper.closeModal(component, 'newPinModal');
},
openNewPin : function(component, event, helper){
	helper.openModal(component, 'newPinModal');
},
closeSinglePin : function(component, event, helper){
	helper.closeSinglePin(component, event, helper)
},



And after all is in place, our form should now be working:







Conclusion



There you have it. A cool map with events, clusters, a custom form – a good start of a real world application you can build inside Salesforce. Keep in mind these are mostly using Lightning – unless we had to build it ourselves. 



Next up should be filtering the results, adding a better Hover callout on the pins, maybe even having the latest chatter in the hover. The possibilities are endless.
The post Let’s build a Map Application using Leaflet and Lightning Components appeared first on Michael Soriano.



Let’s Build an AutoSuggest Lightning Component with Google Places API
Michael Soriano — Fri, 11 May 2018 22:18:19 +0000

I had the challenge of building an input form that brings up a list of cities as you type. One that has the coordinates of each city – because I’ll need to enter that into a map. An “auto-suggest” or “auto-complete” city input – inside a custom form inside Salesforce. It turns out, that it wasn’t so bad.



We’re using Google Places for our API and Lightning Components for our Front End. If you’re not familiar with Lightning, check their documentation.



Our component will look like below.







Ready to start coding? Let’s start.



API Setup



Let’s get Google going. Remember, each time a user type a character – it will ping Google for suggestions. Also, the suggestions does not contain coordinates for each item, so we will need to ping the API as soon as the user selects a place.



I’m going to assume that you know how to get an API key from your Google account. If not, here is their API documentation.



The first part is getting the suggestions. Below is the URL that we need for that:



https://maps.googleapis.com/maps/api/place/autocomplete/json?input=TERM&key=YOURKEY



Looking at the above, we’re passing in what the user is typing where it says “TERM”.
The second part is when the user selects an item:



https://maps.googleapis.com/maps/api/place/details/json?placeid=PLACEID&key=YOURKEY



The above shows a “placeid” parameter that we get from each suggestion. So when the user clicks – we pass the id to the above URL.



Now that we have our Places API setup. Let’s move forward to our Salesforce code.



Build the Apex Class



One thing to note is that our Lighting components cannot reach out to Places API directly. Google doesn’t allow CORS to their endpoints – so we simply cannot do this. Nor would we want to – because if we do this via JavaScript – we will be exposing our keys. So we need the server to do the calls. In Salesforce, we use Apex.



We also have to add “maps.googleapis.com” to the remote site settings in Salesforce. To do this, go to “Setup” > “Security” > “Remote Site Settings”.



Click on “New Remote Site” and add the required fields:







Now, let’s create our Apex Class. Copy the code below and add it to your Class:



@AuraEnabled
	public static string getSuggestions(String input) {
	    String url = 'https://maps.googleapis.com/maps/api/place/autocomplete/json?'
	            + 'input=' + EncodingUtil.urlEncode(input, 'UTF-8')
	            + '&types=(cities)' + getKey();
	    String response = getResponse(url);
	    return response;
	}
@AuraEnabled
	public static string getPlaceDetails(String placeId) {
     	String url = 'https://maps.googleapis.com/maps/api/place/details/json?'
	            + 'placeid=' + EncodingUtil.urlEncode(placeId, 'UTF-8')
	            + getKey();
	    String response = getResponse(url);
	    return response;
	}
	public static string getResponse(string strURL){
		Http h = new Http();
		HttpRequest req = new HttpRequest();
		HttpResponse res = new HttpResponse();
		req.setMethod('GET');
		req.setEndpoint(strURL);
		req.setTimeout(120000);
		res = h.send(req);
		String responseBody = res.getBody();
		return responseBody;
	}
	public static string getKey(){
		string key = 'xxxxxxxxxxxxx';
		string output = '&key=' + key;
		return output;
	}



Note the two methods that have @AuraEnabled: getSuggestions() and getPlaceDetails(). These are the two endpoints we will be calling from our JavaScript in our Lightning component. Both methods are quite explanatory, they simply accept parameters from our front end, go out to Google and return the results.



Don’t forget to add your API key to the method getKey().



Let’s move on.



Our Component



The component (.cmp file) will need a few things. First, we need a couple of attributes to hold our values. One for location and one called “predictions”. The location is the value that will be in our input, while the predictions is what will show directly beneath it – in an unordered list. Note that this is what comes back from our API.  So add that first to your component.








We’re using “lightning:input” for our form field. We add a label, name, an aura:id, a value and an onchange attribute. The label and name is pretty straightforward, the aura:id – is simply a way for us to reference it in our controller.



The value – binds the input to our attribute “location”. Which we show as “v.location“.



The onchange – we’re attaching to a function in our controller named getCities(), which we refer to as “c.getCities“.







We’re using an unordered list for our suggestions. So we use the code below:




 	
		
			
				{!prediction.description}
			
		
	




Notice we wrap it an “aura:if”  – which determines if our predictions object has more than zero length. Remember, predictions is coming straight from the API.



Then we have an “aura:iteration” for each prediction to show up in a list item > anchor tag. Each anchor tag has an “onclick” (which we’re attaching to getCityDetails()) and a “data-placeid” (I’ll explain later).



The Controller



So remember in our component we have 2 methods: getCities() and getCityDetails()? Those both go in our controller.



Our getCities() method is called every time we change the input field. Meaning – every time we type a letter, it calls this method.



First it sets up an object called “params“, which has one item in it called “input“. This is what we’re sending our Apex class through the use of helper.callServer(). This helper is explained in my previous post “Call Apex from Lightning“. Once our Apex responds with some suggestions – we parse it through JSON.parse() and set it to our component attribute called “predictions”.



getCities : function(component, event, helper){
	var params = {
	  "input" : component.get('v.location')
	}
	helper.callServer(component,"c.getSuggestions",function(response){
		var resp = JSON.parse(response);
		console.log(resp.predictions);
		component.set('v.predictions',resp.predictions);
	},params);
}



So our UL of suggestions will only populate if there’s a response from the server.



Finally, getCityDetails() get’s triggered when we choose an item from our UL (or click the anchor tag).
Remember the “data-placeid” attribute that we have for each anchor tag? This is where we will need it.



We grab the value of “data-placeid” (which is the Place Id required for our API) through the event.currentTarget. We then create the “params” object like we did above.



getCityDetails : function(component, event, helper){
	var selectedItem = event.currentTarget;
        var placeid = selectedItem.dataset.placeid;
	var params = {
	   "placeId" : placeid
	}
	helper.callServer(component,"c.getPlaceDetails",function(response){
		var placeDetails = JSON.parse(response);
		component.set('v.location',placeDetails.result.name);
		component.set('v.predictions',[]);
	},params);
}



We then do a helper.callServer() and when finished, we parse then set the v.location (the input value) and v.predictions back to empty.



I specifically needed the coordinates for the selected location, which can easily be grabbed from the response. You can do something similar.



The Final Product:



Below is a short screengrab of the final output. The lightning:input makes our field look better than just a regular input. Also, this is a “barebones” solution for an auto suggest field. You can greatly enhance by adding icons, additional description for each place, maybe some more events (like on tab, enter etc).





The post Let’s Build an AutoSuggest Lightning Component with Google Places API appeared first on Michael Soriano.



Call Apex from Lightning components
Michael Soriano — Mon, 07 May 2018 17:20:45 +0000

I’ve decided to do some write up on Salesforce – especially Lightning development. Lightning is basically Salesforce’s proprietary JavaScript and CSS Framework bundled into one. It’s a component-based system, mobile friendly, with the power of a server side language (Apex), just in case you need it.







In the following tutorials, you might see a “helper.callServer()” method – which I’m outlining below:



callServer : function(component,method,callback,params) {
        var action = component.get(method);
        if (params) {
            action.setParams(params);
        }
        action.setCallback(this,function(response) {
            var state = response.getState();
            if (state === "SUCCESS") {
                // pass returned value to callback function
                callback.call(this,response.getReturnValue());
            } else if (state === "ERROR") {
                // generic error handler
                var errors = response.getError();
                if (errors) {
                    console.log("Errors", errors);
                    if (errors[0] && errors[0].message) {
                        throw new Error("Error" + errors[0].message);
                    }
                } else {
                    throw new Error("Unknown Error");
                }
            }
        });
        $A.enqueueAction(action);
    }



If you’re ever going to do some kind of call to an Apex class – this is a must have in your helper. Think of it as sort of like jQuery’s $.ajax() method – but limited to a specific class.



Salesforce has the same exact code in this doc with some explanation, but I wanted to write it up in my own words. Let’s break it down below.



As mentioned, this is what we need to call an Apex class from our components. It is basically a wrapper to an XMLHttpRequest, along with other utilities to make our JavaScript easier.



Again, components are front end code – Apex sits in the server. This method is the communication between the two.



Set up Apex



First, you declare a class. This is done in our .cmp (component) file, way at the top – it looks like below:







Now we’re set up with an Apex class called “MyClass”. Let’s build that class, with a method called “doSomething()”:



public with sharing class MyClass{
   @auraEnabled
   public static string doSomething(String input) {
      return input
   }
}



Note the “@auraEnabled” declaration. This allows us to access it from our JavaScript.



With the our helper in place, all we need to do in our controller will be something like below:



helper.callServer(component,"c.doSomething",function(response){
    //INSIDE OUR CALLBACK
    console.log(response) //RESPONSE FROM OUR APEX METHOD
},{})



You see, our helper had arguments that looked like below:



callServer : function(component,method,callback,params) {…



Which is what we’re doing in our controller. The second parameter “c.doSomething” – is the method in our Apex class. The 3rd parameter “callback” – is an anonymous function that get’s triggered through “.apply()” in our helper. This is executed when our Ajax call finishes. And we’ll have access to the response.



Sending Parameters



You can send information to your Apex class by setting an object to the last parameter called “params”. In our example above, we’re simply passing an empty object “{}”. But in reality, you will most likely send something to the server.



Our method “doSomething” is expecting a string called “input”.



The object we can pass will look like below:



{
  "input" : "somevalue"
}



Notice the key “input” must match our server variable “input”.



If you would like to pass another value, simply add another key:



{
  "input" : "somevalue",
  "input2" : "somevalue2"
}



In our doSomething method:



doSomething(String input, String input2)



You can also pass multiple values as a JSON string, so in your controller:



var str = JSON.stringify({"input1":"somevalue","input2":"somevalue2"});
var params = {"strsRecord" : str};
helper.callServer(component,"c.doSomething",function(){}, params);



In your Apex class:



doSomething(strsRecord){
   List st = JSON.deserialize(strsRecord);
   System.debug('Here is the params:' +st);



“Promise” Style



In JavaScript, a promise is “an object that may produce a single value some time in the future“. So our helper above is a perfect example of this. Let’s rewrite it using a promise, so we can use it more efficiently, and elegantly.



By this, I mean avoiding “callback” hell. See, callbacks are okay if we’re dealing with a single call. But if we were to make multiple nested calls (especially one that needs relies on the first response etc), it gets ugly real fast like below: 



Callback hell:



helper.callServer(component,"c.doSomething1",function(response1){
     helper.callServer(component,"c.doSomething2",function(response2){
         helper.callServer(component,"c.doSomething3",function(response3){
               //THIS GETS UGLY...
          },{})
     },{})
},{})



So let’s convert it to use a JavaScript promise instead: 



callServer : function(component,method,params) {     //PROMISE BASED
        var promiseObj = new Promise(
            function(resolve, reject){
                var action = component.get(method);
                if (params) {
                    action.setParams(params);
                }
                action.setCallback(this,function(response) {
                    var state = response.getState();
                    if (state === "SUCCESS") {
                        var data = response.getReturnValue();
                        resolve(data)
                    } else if (state === "ERROR") {
                        var errors = response.getError();
                        console.log(errors);
                        reject(errors);
                    }
                });
                $A.enqueueAction(action);
            }
        );
        return promiseObj;
    }



As you can see above, there are no more callbacks being passed. All we need are the 3 parameters: “component”, “method” and “params”. 



Now we can use this like below:



helper.callServer(component,"c.doSomething",{}).then(function(response){
   console.log(response)
})



You see the use of “.then()”. We’re no longer restricted to a single callback function we were previously. We can even use multiple .then() methods all over our code:



var ajax = helper.callServer(component,"c.doSomething",{});
//first .then()
ajax.then(function(response){
   console.log('do something here');
})
//second.then()
ajax.then(function(response){
   console.log('do more stuff here');
})



We can also chain Promise methods like so: 



var ajax = helper.callServer(component,"c.doSomething",{});
ajax.then(function(response){
   console.log(response);
}).catch(function(error){
   console.log(error)
}).finally(function(){
   console.log('this always runs')
})



As you can see, the “Promise” style of the helper can help you write more efficient code. 



So keep this in your Lightning helper, in order to communicate with Apex. Its almost always guaranteed to be used at least once in your Salesforce applications. 
The post Call Apex from Lightning components appeared first on Michael Soriano.