Written by Matthew Ekenstedt, | Mar 29, 2018
If you develop on Salesforce, then you know that Lightning is here and it’s here to stay—which means that all of us developing on Salesforce need to think about building for the Lightning Experience first and Visualforce second. We’ve had a couple of years to ramp up, and now we need to adjust our design and development methodologies to match the way Lightning Components work if we want to provide the best experience for our end users. Here at CloudCraze we’ve been working through those methodology changes, so I’d like to share my experiences with you.
For years—maybe even decades— we’ve been making large-scale, top-down experiences on web technologies like Visualforce. It’s comfortable to stick with what you know. And often the problems you can solve with the new technology can also be solved with the old. We’ve all been treating websites like a collection of components anyway, right? Frameworks and templating languages exist for the explicit purpose of allowing other developers, further down the line, to customize our web products to their own specifications. But with Lightning components, we have a standard way of giving individual Salesforce Admins the power to customize their own experience, to a high degree, at practically no cost to them. When you choose to develop components, you choose to give your customers more agency. When your customers have more agency, they’re happier with your product.
The Old Mindset
Let’s talk about web applications again for a minute, like something you’ve written in Visualforce, React, Angular, or any other web technology. I mentioned earlier that we as developers have been trying to componentize web pages for years. That’s really only partially true. In most cases, what we’re actually doing is trying to make our code reusable. We see a bunch of similar-looking things and the engineer part of our brain goes, “That should be instances of a common object.” While this is true, those aren’t self-contained components. Some function might interact with other sections of the page or navigate us to another page entirely.
This exposes some of the problems we run into as web applications get bigger and more complex. Each piece of the application is usually hardwired into the other parts of the application. To understand what exactly your piece of the application does, you need to understand the application as a whole.
What’s So Great About Components Then?
Here’s where component-based development can help us. While a well-designed component can work well within a more complicated system, it still needs to be self-contained. This goes back to some of the old CS 101 Object Oriented concepts. If we’re working within the Lightning community designer, for example, each component that you can drag into the page should not– in any way–rely on or modify another component existing on that page. From a traditional web development point of view, these might look like restrictions, but they aren’t. They merely enforce component-based design, keeping the internal workings of a component actually internal. When a component can load its own data, and handle its own user interactions, a Salesforce Admin can put it on any page that makes sense in their business. This means that you, the developer, don’t have to think about what that context might look like ahead of time. Better for everyone!
Here’s another piece of advice for your components: remember how to write stateless code. Way back in the day, the web was entirely stateless, then server sessions, cookies, etc. made us lazy. Of course, you’re not going to write entirely stateless code, because if you’re in a community with a logged in user, you know about that logged in user. What I’m referring to is more about the bigger “Where am I in this web application?” state graph. In a traditional web application, a developer has a lot of control over that, so we write code with that in mind. However, in a Lightning community we don’t know where someone might have dropped our component. It might be on the home page, in step 4, or some other process. But if you can write your component in a way where it doesn’t need to understand the state of the application as a whole (aside from the user information), it will provide a better experience for your clients, Salesforce Admins working with the components, and ultimately their customers as well.
The metaphorical cheese has moved at this point, and I’ve seen a lot of resistance from developers to move on. Those people are too worried about the changes to see the possibilities. I encourage you to give Lightning Components a shot. Things don’t quite work the way they used to in web application development, but they aren’t all that different either. And once you have your entire development team thinking in components – from design and architects to QA – you’ll amaze yourself at what new and interesting ideas come out of it to better serve your clients and customers.