Added new Apex method & JS function Logger.setField()

[jongpie]

New Apex Method Logger.setField()

Resolved #769 by adding a new static method, Logger.setField(). This gives Apex developers a way to set field(s) once per transaction, and the fields will be auto-populated on all LogEntryEvent__e records generated in that transaction.

• The setField() method has 2 overloads (same as the instance method overloads LogEntryEventBuilder.setField() that were introduced in release v4.13.14)

  1. Logger.setField(Schema.SObjectField field, Object fieldValue) - useful for easily setting the value for a single field
  2. Logger.setField(Map<Schema.SObjectField, Object> fieldToValue) - useful for setting the value for multiple fields

• The new method supplements the functionality introduced in release v4.13.14, as shown below:

  // 🥳New!
  // Set a custom field on all LogEntryEvent__e records in a transaction,
  // using static method Logger.setField()
  Logger.setField(LogEntryEvent__e.My_Custom_Log_Field__c, 'the value for some Log__c field')
  
  // ℹ️Existing - introduced in v4.13.14
  // Set a custom field on a single LogEntryEvent__e record,
  // using instance method LogEntryEventBuilder.setField()
  Logger.info('hello, world')
    .setField(LogEntryEvent__e.Some_Custom_Log_Entry_Field__c, 'the value for some LogEntry__c field');

New JavaScript Function logger.setField()

Added JavaScript support for setting fields once per component instance, using logger.setField(). This is the JS equivalent of the new Apex method Logger.setField() (above).

export default class LoggerLWCImportDemo extends LightningElement {
  logger = getLogger();

  connectedCallback() {
    // 🥳New!
    // Set My_Field__c on every log entry event created in this component with the same value
    this.logger.setField({My_Field__c, 'some value that applies to any subsequent entry'});

      // ℹ️Existing - introduced in v4.14.6
    this.logger.warn('hello, world - "a value" set for Some_Other_Field__c').setField({ Some_Other_Field__c: 'a value' });
  }
}

[jongpie]

@surajp I think the changes in this PR will handle the limitation that we discussed a few days ago with custom field mappings (issue #769). If you happen to have a some time to take a look at this, I'd love to hear your thoughts on the changes before I merge it.

[surajp]

@surajp I think the changes in this PR will handle the limitation that we discussed a few days ago with custom field mappings (issue #769). If you happen to have a some time to take a look at this, I'd love to hear your thoughts on the changes before I merge it.

That was fast and the changes look great! If I understand correctly, if I do Logger.setField(LogEntryEvent__e.My_Custom_Field__c,'value1') and add then logger.info('some message').setField(LogEntryEvent__e.My_Custom_Field__c,'value 2'), the log__c record will have My_Custom_Field__c set to value 2?

[jongpie]

@surajp at the moment, that scenario would have slightly different behavior, depending on when you use the setField() methods, and where the LogEntryEvent__e field is mapped

Example 1:

Logger.setField(LogEntryEvent__e.My_Custom_Field__c,'value1');
// This entry will have 'value1'
Logger.info('an entry that does not use the builder setField() method);
// This record will have 'value2'
Logger.info('some message').setField(LogEntryEvent__e.My_Custom_Field__c,'value 2');

In this case, the first entry would have value1 - and essentially, the first LogEntryEvent__e for a particular transaction ID is used to create the Log__c record. So if LogEntryEvent__e.My_Custom_Field__c is mapped to a Log__c field, then the Log__c would have value1.

Example 2

Logger.setField(LogEntryEvent__e.My_Custom_Field__c,'value1');
// This entry will have 'value2'
Logger.info('some entry that overrides the same field set via static method Logger.setField()').setField(LogEntryEvent__e.My_Custom_Field__c,'value 2');

In this case, since the first entry would have value2 - and then the Log__c field would also have value2

I think this behavior makes sense, but let me know what you think about it. At the very least though, I'll want to document the behavior so people understand how it works in these situations.

[codecov]

Codecov Report

Attention: Patch coverage is 81.48148% with 5 lines in your changes missing coverage. Please review.

Project coverage is 92.77%. Comparing base (2445dcb) to head (9d437dd).

Files with missing lines	Patch %	Lines
...-logger/core/main/logger-engine/classes/Logger.cls	84.21%	3 Missing ⚠️
...ogger/core/main/logger-engine/lwc/logger/logger.js	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #772      +/-   ##
==========================================
- Coverage   92.82%   92.77%   -0.05%     
==========================================
  Files          75       75              
  Lines        7203     7229      +26     
  Branches      190      191       +1     
==========================================
+ Hits         6686     6707      +21     
- Misses        498      503       +5     
  Partials       19       19              

Flag	Coverage Δ
Apex	94.21% <84.21%> (-0.04%)	⬇️
LWC	86.23% <75.00%> (-0.09%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jongpie]

@surajp I went ahead and released these changes in v4.14.14! I think the changes in this PR will help improve the functionality a good bit, and I'll continue to look into some of the other enhancements/changes we discussed for custom fields/field mappings. Thanks again for your help & feedback!