Salesforce Lightning Web Component

LWC Pros

• Modern js framework: modules, imports, inheritance, decorators, Shadow DOM. All of these elements enforce writing clear code, division into components, use of composition, Lightning Data Service.
• Access to Lightning/ui*Api and methods such as: getRecord, createRecord, getObjectInfo, getPicklistValues and so on. And that’s what Lightning was missing. Thanks to these, much more can be done without any backend intervention. I was able to easily extract record (defined fields) and download field labels.
• Some methods can be called only by marking them as @wire. When trying to call on demand, the error appears: „Imperative use is not supported”. Unfortunately, it firmly reduces the possibilities of usage, e.g. there will be no call chain when one of the elements is getRecord.
• Importing references to fields. To indicate which fields are to be retrieved by, for example, getRecord, we can conventionally give the list of strings as [„Account.Name”, „Account.Id”] or retrieve fields as: import ACCOUNT_NAME_FIELD from ‚@salesforce/schema/Account.Name. Thanks to reference to a field, we are able to retrieve field and labels data etc. in a more transparent way.
• Calling backend methods. To call methods, you have to retrieve references (just like object fields) import apexMethod from ‚@salesforce/apex/Namespace.Classname.apexMethod.

Thanks to reference, we can easily call methods. Comparing it with Lightning, it’s definitely a step forward. As it comes to Lightning, it could happen that the name of the method for backend was just the same as the controller method and still, it worked. This call attempt did not cause an error, only weird code behavior. From experience I know that we lost a lot of time to analyze errors like this.

•  The same component library as in Lightning.

Thanks to this, we certainly reduce entry threshold for people who know Lightning.

LWC cons

• No support for: Lightning Out, Lightning Components for Visualforce, Standalone Apps, Salesforce Console (Navigation Item API, Workspace API, UtilityBar API), URL Addressable Tabs, Flows, Snap-ins Chat, Lightning for Gmail, Outlook Integration, EMP API, Conversation Toolkit API, Omni Toolkit API, Quick Action API, Standard Action Overrides, Custom Actions (from project’s point of view, it’s the most painful one), Global Actions, List View Actions, Related List View Actions, Chatter Extensions.
• We write most of custom code as Quick Action. casein such a case, LWC can-not be used directly. My way to avoid this was to use a Lightning component as a container for LWC. It is possible to use LWC in Lightning, however not Lightning in LWC.
• The lack of possibility to service standard events force:refreshView, light-ning:tabFocused, lightning:tabRefreshed etc. basically precludes autonomous usage of LWC on websites demanding interaction with standard components like for example Record Detail.
• The lack of $A and thereby blocking many essential methods e.g. $A.get(‚e.force:refreshView’).fire(). Most of these issues can be avoided with applying Lightning container. Everything that LWC is unable of doing, could be done in a container that can be then communicated with LWC, but a created web can be quite big. Besides, some workarounds in the future Salesforce re-leases might stop working. It happened many times in our complex projects. After a few first versions of interface, we had to correct many mistakes and re-write the code.
• Oneway data binding. This is something I totally cannot understand. Data bind-ing between the view and container is only in the form of: container -> view. In order for the changes, e.g. from the simplest input, to be in the container, we have to add: onchange={handleChangeValue}. An archaic way that creates a lot of additional empty code. Also, it is possible that it will preclude applying some outside libraries and components.
• The lack of possibility of dynamic creation of components (without $A there’s no $A.createComponent()). All of the components have to be included on the layout. It can be avoided with the use of ifs, but still, it’s another workaround.
• A very long time of deployment of LWC to sandbox. I don’t know what is the reason, but it’s irritating. The deployment of one component can last a few minutes. In contrast, Lightning components are deployed in a few seconds without any problems.

LWC – a good direction, but…

Lightning Web Components is an interesting technology meeting expectations of the frontend world. It solves many issues of default Lightning, adds new possibilities (e.g. @wire) and takes over the right standards. Unfortunately, at times it restricts a programmer too much. As an example, there are methods that can be called only by marking as @wire. It would be much more flexibly to use the getRecord method where we want, not only with using @wire.

A simple framework can be a plus. Writing code took me four days. I spent two days reading the whole documentation and two days writing a code. At the same time, it is a minus, because it means that there’s no more advanced functionalities.
In LWC’s case, I have similar feelings as in the case with the Salesforce console. Just like when we started writing a code after the first release, still in the beta version. At that time it was an unpolished product, it missed basic functionalities (e.g. Work-spaceAPI, necessary to bookmarks management, which came out nearly a year later).

At this point, I do not recommend using LWC in extended projects. The lack of pos-sibility to communicate with the default version will make a lot of issues and the ne-cessity of creating workarounds that might all of a sudden stop working at any time. On the other hand, isolating components would be certainly a plus.

I look forward to further Salesforce releases and new features implemented to LWC. I hope that framework will be efficiently developed and soon it will replace current so-lutions. For sure, it is the right direction of development and a big step forward.