5

I found several unexpected behaviors while writing Lightning web components.

  1. Cannot have local name on imported decorator
import { LightningElement, api as a } from "lwc";

export default class MyComp1 extends LightningElement {
  @a
  prop1;
}
// => bad result: TypeError: Cannot read property 'referencePaths' of undefined 
  1. Cannot re-assign the imported wiring function to variable
import { LightningElement, api, wire } from 'lwc';
import { getRecord } from 'lightning/uiRecordApi';
import ACCOUNT_NAME_FIELD from '@salesforce/schema/Account.Name';

// re-assign the reference to another var
const getRec = getRecord;

export default class Record extends LightningElement {
  @api 
  recordId;

  @wire(getRec, { recordId: '$recordId', fields: [ACCOUNT_NAME_FIELD] })
  record;
}
// =>  SyntaxError: /home/sfdc/tools/lwc/1.1.13-224.8/myComp1.js: LWC1098: @wire expects a function identifier to be imported as first parameter.

When considering ECMA standard, both cases should behave identical to the officially provided examples.

Maybe the platform compiler needs this restriction to detect dependency in static analysis, but is there any document that clearly says the LWC JS has the part against the spec ?

It may seems subtle and can be easily avoided, but many tools are assuming the output would be compliant to the ECMA standard so these simple renaming may happen when doing pre-processing the source code.

4

The compiler does a lot of "magic" to ensure compatibility and Locker API consistency across all browsers. For example, decorators are experimental, so to provide a consistent experience, it applies a patch to make them work. As a side effect of that example quirk, the only decorators allowed are @api, @track, and @wire. You cannot write a custom decorator at this point.

At some point, all of this will be supported in native code, thus reducing the footprint of Aura/LWC runtime. However, LWC isn't there yet, as it has to be compatible with existing browsers. I don't know of any documentation that goes out of the way to explain limitations that are this specific. However, there's a pretty easy solution. If you don't find a particular syntax in the documentation, it is probably not allowed, or at least caution is advised.

Here's the documentation describing compatibility. Note that it doesn't have limitations such as the one you've noticed. This is not a permanent situation, but for now, you should presume that the Salesforce documentation perfectly describes what the platform supports, while ES6 describes what the future browser support should look like. After IE 11 Extended Support sunsets at the end of the year 2020, there should be a lot more ES6 compatibility, since they will no longer need to depend on patches/transpiling.

  • I understand custom decorators are not available in platform LWC yet, and decorator spec itself is not in released stage in ES. However, the import syntax is defined in ES modules (in ES6), and variable assignment to behave identical is assured in early JavaScript. It is not the matter of browser compatibility, and it is caused by some kind of philosophy of LWC. If we cannot use the syntax that are not described in LWC doc, who can write a code without ES spec ? Even if for loop or if branch is NOT described in LWC document. – stomita Mar 23 '20 at 1:10
  • @stomita It just sounds like you're trying to nitpick. The point is that things you find in the documentation WILL work, but the stuff you find in ES6+ docs "may not" work. Again, this is a limitation of the compiler for compatibility reasons, as far as I can tell. In the future, it's likely you'll be able to do that kind of stuff, but it's just not possible today. – sfdcfox Mar 23 '20 at 2:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.