Create global logger service for frontend

[AllanOricil]

The current logger for lwc creates several logger objects instead of a single global object. If used in all components in a page, it can slow down page loads, and use unnecessary memory.

import { createLogger } from 'Nebula/logger'; export default class LoggerLWCDemo extends LightningElement { logger; async connectedCallback() { this.logger = await createLogger(); this.logger.info('Hello, world'); this.logger.saveLog(); } }

To solve this potential issue I thought that the lwc logger can be exposed as a global service component that listens to events from other components within the same page. It would behave like a global object. Developers would drag and drop this service component in the pages where they want to gather logs from. Then the createLogger implementation would return an object that uses the global service, if one is available in the page.

• this.logger.saveLog() would be handled in the global service

• components are responsible for emitting log events

• global service is responsible for processing and storing logs

[jongpie]

@AllanOricil as far as I'm aware, the existing approach isn't very resource-intensive (it's a very small JS class), so I don't think this is currently causing any major issues with page loads & memory usage.

Switching to a global component would also lead to other issues:

• If someone forgets to add the global component to a page, then logging data is lost.
• If someone adds the global component multiple times to a page, then there's additional complexity needed for handling logging data.
• If someone uses an LWC as a tab (as opposed to adding an LWC to a FlexiPage), then there's not a way to drag additional components onto the page, so the global component approach won't work in all situations.
• Using events would (probably) lose the ability to use a fluent API (provided in the current implementation).
• Using events would require developers/other components to do more work - they would have to explicitly provide more data in the event that is captured automatically by the current implementation (example: things like the stack trace would have to be passed in the event).

At least for now, I think the current approach is better than moving to a global component.