In my last post, I wrote that "there's a new, alternative style of coding available for building custom reporting/data-entry screens inside Salesforce ("Lightning Components" instead of "Visualforce"). Our web developers don't write either right now, but if they did, they'd be happy to know that the new option is more modern-web-development-ey than the old option.
I've been slowly reading the thick book about Lightning Components that I picked up at Dreamforce.
After getting through chapter 2 ("quick start"), I thought, "I should take an existing Visualforce page I've written and rewrite it in Lightning Components as a programming exercise.
Most Visualforce pages I've written are simply a way of displaying the results of an SOQL query to an end-user, so they weren't going to be very exciting.
The most "interactive" one I've written prompts the user for a date and plugs that into an SOQL query whose results are displayed to the end-user. Some of the fields in the display allow their values to be changed, and there are Save/Cancel buttons for all changes made so far on the page. This seemed like my best candidate for a conversion.
Unfortunately, even this isn't a great candidate for conversion, as far as I can tell. Here's why.
Step 1: Think of everything a user of your VF/LC app "does" to the page as a "browser event."
Here are all of mine:
- User fills a date in the date-picker box
- User clicks the "submit chosen date and refresh page with data from server, showing event attendees for that date" button**
- User fills in an "attendance status" picklist with a given value
- User clicks the "save changes to server and refresh page with latest data from server" button**
- User clicks the "discard 'attendance status' picklist-value changes made in browser" button*
Step 2: For each "browser event," ask yourself two questions:
- Does it actually make any substantial changes happen, besides what the user expected?
(If "user clicks a checkbox" is the "browser event", then "checkmark toggles inside checkbox" is NOT a "substantial change," but "text next to checkbox changes color" IS.) - Does the "substantial change" depend upon the Salesforce.com server being contacted?
("...saves changes to server..." or "...gets data from server..." DO require the server to be contacted. "...Text next to checkbox changes color..." DOES NOT.)
In my case, the "user fills in" items don't do anything "substantial."
My "substantial changes" (marked with at least 1 asterisk & boldfaced) occur when the user clicks buttons.
Of those 3 "substantial changes," 2 are completely dependent upon the Salesforce.com server being contacted (marked with 2 asterisks).
Only the "discard" button's behavior could be done without contacting the server, if you had been saving "old values" in the browser's memory as the user made changes.
Even there, though, it's probably much simpler to just ask the server to provide clean data.
From what I can tell so far, Lightning Components makes "substantial changes that don't have to talk to the Salesforce.com server" easier to write.
However, "substantial changes have to talk to the Salesforce.com server" involve writing way more code in Lightning Components than they require in Visualforce.
Although it has a few "sections" to it, not all of which are always visible, overall, my page is merely a single "editable SOQL query" user-interface with a few extra controls.
More importantly, I want it to behave "synchronously" with the server.
That is, once a user has clicked a button, I don't want them messing around with the clickable parts of the page until the data-refresh from the server is complete. I want them to lose any work they try to do between button-click and page-refresh.
I have never written a Visualforce page that includes any "substantial" results of users' "browser events" (e.g. button-clicks) that are easily handled entirely inside their browser with JavaScript (e.g. "change the color of the text").
Therefore, from what I can tell, my conversion will inherently involve a lot more code in Lightning Components than it involves in Visualforce.
(And more memory usage in the user's browser.)
Please correct me if I'm wrong!
Visualforce has a very efficient one-line syntax for communicating with the Salesforce.com server and refreshing the Visualforce page in response.
Lightning Components, from what I can tell (please correct me if I'm wrong!), makes you:
- Code a browser-event handler to fire LC-event-#1
- Code a LC-event-#1 handler to talk to the server and to fire LC-event-#2 upon response
- Register a listener for LC-event-#2
- Code a LC-event-#2 handler to refresh the page with data returned from the server
I still plan to do the conversion as practice, but I wonder if there's a way to get the best of both worlds for my apps: Lightning-Components-looking responsive styling coded in a minimal amount of Visualforce.
You're not alone on this topic by any means. We've been dealing with this at DCS too. Do I write my apps in VF or in Lightning components? For the most part, our development tends to be on the Visualforce side, because that's everyones comfort zone and bread and butter.
ReplyDeleteGenerally speaking, as Salesforce devs we're currently stuck in this confusing zone between the old MVC / "page centric" world of Visualforce and controllers and the "app centric" zone of Lightning Components.
However, if you've been paying any sort of attention at all, you've likely noticed a big focus on Single Page Applications or SPAs for short. You can find SPAs in products like LEX, Community Builder, and eventually see it to take effect in Service Cloud and other products.
My advice to you is to continue with Visualforce if you want, but eventually you'll want to come out of the comfort zone and start learning about lightning component development before it's too late and you're stuck with having to ramp up on the new framework with little or no time to do so.
A short term bridge for transitioning from VF to Components might involve taking a small portion of your application and writing it as a lightning component, but utilizing it in Visualforce with the lightning out interface.