Making the move from Aura to LWC is an important step that everyone should be doing already. It will bring you a ton on benefits, while the effort is not that big. If you want to do some more reading about this topic, take a look at the following blog post. Bear in mind it’s targeted for an architect’s mindset. If you’re a video person, take a look at the next video – with more detail, more suitable for developers:
The 13rd of December this year, Salesforce announced the release of Lightning Web Components (LWC). This is something in which Salesforce has been working very hard, and which is surrounded by an aura of mystery. Because of that, in this blog I will try to explain the keys of this announcement.Continue reading “Lightning Web Components – and now what??”
When thinking about good quality software we must always have very present that tests automation is a must. There is a full list of tiers and tools that can be used to ensure that your software behaves as expected, bugs typically introduced by refactoring are prevented, and interconnected systems behave well together, as for example your code together with a Salesforce upgrade. In this post I want to focus on how to write unit tests for Lightning Components using Lightning Testing Service (LTS).Continue reading “Unit testing aura components with Lightning Testing Service and Mocha”
Lightning Pages are a concept introduced by Salesforce to allow creating and customizing pages in Salesforce with simple drag & drop, for Lightning Experience and Salesforce1. In this post I want to explain how these pages behave in a managed package environment.
Last week I discovered something about Lightning Components I didn’t know about: aura:action. This is an attribute type that you can use to pass actions to a child component, in addition to the other supported attribute types, and it can be specially helpful if you want to decide at component instantiation which actions should the child component perform.
When working with Lightning Components framework it is very important to understand how the different components are rendered by the framework, which possibilities do we have to interact with the component lifecycle and how will the framework react to certain events as for example a change of an attribute. Want to know more? Continue reading!
A typical use case when creating records is to populate some fields in advance, and then let the user fill in the rest of required fields. Let’s say that we want to create account records, having a pre-populated description, like this:
Today I want to take a look at the data binding possibilities that exist for Lightning Components attributes. We will see how attributes can be referenced using bound or unbound expressions, and which implications will these bindings have in our application.
Last week I was exploring the options to show a context sensitive pop-up in record detail pages. The pop-up needed to use the sObject name of the record that was being visualised in the detail page. I wanted this functionality to be available in classic and Lightning Experience. So I spent some time exploring the options that we have to do this. Are Lightning Components ready to fulfil my requirements?