Salesforce Lightning Components — Lesson Learnt
We’ve got two Salesforce Certified Technical Architects at SalesTrip, and both of us enjoy working at the bleeding edge of technology. This can mean as much frustration as excitement but we feel that it’s definitely worth it.
Lightning Components are by no means new but I feel that we’ve been using them in fairly advanced ways meaning that we’ve learnt lessons that few others have. I’d like to share some of those anecdotes with you here.
1. Client-side Logic
Client-side controllers should contain close to zero logic and instead just orchestrate logic across helpers and service components; helpers should contain logic specific to that component; shared business logic or “helper” libraries should be stuck into service components
2. Component Nesting
It can be very tempting to componentise every little area of your application, especially when your mission is to maximise DRYness and re-use. However, the more components you have, and the deeper they’re nested the more difficult you application becomes to understand. This increases the cost of maintenance as well as the risk of introducing errors. There is no single rule to say how far you should go when componentising your application, experience is the better teacher here. But remember to not feel too bad if you repeat an area of code for the sake of understandability.
3. Use Lax
Lax is a library that will reduce the amount of boilerplate Lighting Component JavaScript you need to write, whilst improving the readability of your code. It is particularly useful when creating service components.
4. Learn about Promises
Asynchronous JavaScript can be a tricky thing to get your head around, and even when you do there is the threat of having to manage CALLBACK HELL. Promises are a way to elegantly handle Async JS in a predictable way, and guess what — Lightning Components use JavaScript!
5. Use a Linter
Every company should document their design and coding standards, and once you have you can configure a linter to scan your source code for deviations from that standard. There is a DX-invokable linter for Lightning — it’s very easy to use, and can be triggered automatically. This should take at least some of the pain out of those pesky code reviews ;)
6. Use an IDE that works well with Lightning
Many developers use VS code for Lightning development, James and I are all about Illuminated Cloud. It’s a paid tool, but in my opinion saves you more than enough time (and pain) to easily justify the cost.
7. Server-side vs Client-side Logic
Deciding whether to stick your code server- or client-side can be difficult but as a general rule of thumb we suggestion:
- Server-side (Apex) logic should be used for non-trivial integrations, complex querying and DML
- Client-side logic should be used for just about everything e.g. coded business logic, basic querying and DML, simple integrations (e.g. Google Maps), single-page App statement management
I hope these are helpful, and if you have any lessons you’d like to share please let me know and I may add them to the list!
