Wired Service is not invoked if Getters are used for configuration object properties

[SteffenBaumann]

Describe the bug Wired Service is not invoked if Getters are used for configuration object properties

This issue seems related to reactivity of Getters not being honored properly in the local DEV server when used along with a Wired Service. The documentation is clear about getter/setter pairs being allowed to populate dynamic and reactive changes to wired services:

You can designate these types of configuration object properties as dynamic and reactive.

• Private properties
• Properties defined by a getter-setter pair
• Properties decorated with @api

To Reproduce Steps to reproduce the behavior:

1. Start a local DEV server
2. Import the attached issueReport component
3. Run the component as-is
4. Select a value from the combobox
5. Observe nothing is happening (not even a network callout)
6. Modify the sample by replacing $selectedField with $_selectedField (from getter to property)
7. Run again and select a value
8. Observe a callout is happening and data gets displayed

Optional:

9. Deploy the failing component (using $selectedField) to an Org
10. Select a value from the combobox
11. Observe data getting retrieved as expected in the Org

Expected behavior The local DEV server should honor reactivity of Getters as documented and happening in the Org.

Screenshots n/a - reproduction sample provided

Desktop (please complete the following information):

• OS: Windows 10
• Browser Chrome
• Version 91.0.4472.124

Additional context During troubleshooting the behavior, following observations have been made:

Adding a Setter helps, but doesn't solve the reactivity problem of the Getter. Adding the below Setter

  set selectedField(value){
    this._selectedField = value;
  }

AND using it in the event handler, causes the local DEV server to proceed:

  handleChange(event){
    // remove the _ from _selectedField to use Setter instead of property
    this.selectedField = JSON.parse(event.detail.value); 
  }

The above works in simple situations, but fails if multiple Getters are chained:

  @track _selectedField;
  get selectedField(){
    return this.parsedValue;
  }
  _value = '{}'
  get parsedValue(){
    return this._value;
  }
  set parsedValue(value){
    this._value = JSON.parse(value);
  }
  handleChange(event){
    this.parsedValue = event.detail.value;
  }

Whereas the above is quite an abstract sample, a rather common approach might be retrieving Status picklists of multiple Case RecordTypes by changing between specific Records from a combobox. Without a proper Getter reactivity, this is getting way more complex. Also chaining Getters is quite common to fully leverage the reactivity of the framework, e.g. if the selected value drives more than one operation like additional validation of a value being selected at all.

Marking the Getter/Setter pair as API doesn't help either.

Checking the behavior on the Org confirms, the issue is with the local DEV server, not honoring reactivity of the Getter correctly. Hence, it seems like a sever bug in terms of wired services and would need to get addressed soon, as it complicates local development a lot. issueReport.zip