Guest Post: Daniel Peter is a Lead Applications Engineer at Kenandy, Inc., building the next generation of ERP on the Salesforce Cloud. You can reach him on Twitter @danieljpeter or www.linkedin.com/in/danieljpeter.
So far in this series, the examples have had Salesforce IDs hardcoded in them. For displaying a report, being able to navigate to it by browsing or searching would be nice! Also, when displaying a record with a Salesforce ID, being able to navigate to its detail page by tapping it would be nice too. That’s where Lightning Component events come in.
Autocomplete List of Available Reports
First, add another method to the Apex controller to query for the report names and IDs:
The reportList attribute is new. Also, there is code that iterates over reportList and passes each report to another subcomponent. This builds up the unordered list that jQuery mobile automagically converts to an autocomplete.
Here is the new reportSearchComponent.cmp subcomponent that renders each <li>. It might seem like overkill to create a component just for this, but it comes in handy for handling events:
Next, add code to the helper and controller to wire the Apex controller method to the reportComponent:
Now when the page loads, there’s an autocomplete list of reports to choose from instead of a loaded, hard-coded report:
Creating a Lightning Event
Now create an event that loads the report when clicked. There are two types of Lightning events: Component Events and Application Events. This example uses an Application Event. Events are central to developing with Lightning, and a major difference from Visualforce development. They take some getting used to.
Go to File -> New Lightning Event in the dev console and create reportLoadEvent.evt:
The report attribute will be set to the single Report sObject, which is clicked/tapped.
Here is the code for reportSearchComponentController.js:
When clicked, the link gets the individual report that was loaded for the clicked subcomponent. It then gets the created event, and sets the report parameter on that event to the clicked report. And then my favorite part… fire()!
Loading a Report
For the main component to load a report when the subcomponent fires an event, add a handler to it:
To display the report, the controller calls a slightly modified version of the original code in the helper method. It’s no longer called when the page is initialized with a hard-coded reportId. It’s doing it on the click event with a dynamically selected ID:
Notice how it uses event.getParam from the event passed into it to get the selected report, sets the reportId param as the Report sObject’s ID, and passes that to the Apex controller’s getReportResponse method so it can load the correct report ID.
Clicking the Phone Numbers report loads it:
Navigating to Records in the Report
To navigate to a record within the report, leverage the new data structure created to build hyperlinks in the reportRowComponent.cmp. In many cases, the reporting API gives a Salesforce ID as the value in the response. A quick hack in the Apex controller shows if it is a valid ID and if so, set the isHyperlink to true:
Next, create a new Lightning Component to create and navigate to the hyperlinks. This component will be more generic than the report app. Use it for any app to have a hyperlink for navigating to an sObject detail page:
Finally, add conditional logic to reportRowComponent.cmp to use the sobjectHyperlink.cmp component if there is a valid hyperlink, or standard rendering if not:
Loading a report with hyperlinks now allows for drilling into the object details:
Fragment Identifiers: jQuery Mobile and Salesforce1 Lightning
The Lightning Component framework URLs make use of the “#” fragment identifier:
Read more about URL-Centric Navigation here.
jQuery Mobile also uses the fragment identifier to navigate within a page, such as the column toggle popup:
This creates some navigation challenges. Since that fragment is already being used in the URL, you can’t hyperlink to a fragment within a page in Lightning the same way as in a traditional page. This is a big clue as to how the Lightning framework works behind the scenes. Navigation is significantly different from Visualforce. As Lightning matures and more developers start working with it, a good solution can hopefully be found for this issue. More about this in a future article.