Skip to content

Logger refactor: improvements and more polishing - #13

Merged
EmilianoSanchez merged 9 commits into
logger_refactor_baselinefrom
logger_improvements
Mar 25, 2021
Merged

Logger refactor: improvements and more polishing#13
EmilianoSanchez merged 9 commits into
logger_refactor_baselinefrom
logger_improvements

Conversation

@EmilianoSanchez

@EmilianoSanchez EmilianoSanchez commented Mar 19, 2021

Copy link
Copy Markdown
Contributor

Javascript commons library

What did you accomplish?

Changes:

  • move logger.category to logger.options.prefix.
  • optimization of _shouldLog method.
  • support boolean and string values for config.debug.
  • updated some imports in InLocalStorage modules to avoid circular dependency warning in bundlers.
  • renamed constants to more descriptive names

How do we test the changes introduced in this PR?

Added UTs.

Extra Notes

@EmilianoSanchez
EmilianoSanchez changed the base branch from development to logger_polishing_log_messages March 19, 2021 21:13
@EmilianoSanchez EmilianoSanchez changed the title Logger refactor: improvements and more polishing [WIP] Logger refactor: improvements and more polishing Mar 19, 2021
Comment thread src/logger/index.ts
ERROR: 4,
NONE: 5
};

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the fact that we are using TS, you could implement this Object as a const enum

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact ... I'm not sure about this but you are basically rewriting this. and you are doing something similar here.
Maybe what you could do is remove the String Literal typing from the types.ts and replaced with a Const Enum definition there. Let's discuss this in a call

@EmilianoSanchez EmilianoSanchez Mar 23, 2021

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a great idea using const enums, but after trying it, found a few places where I needed to access enum values dynamically and was not possible to use it.

Comment thread src/logger/index.ts Outdated
const formattedText = this._generateLogMessage(level, msg);

console.log(formattedText);
_log(level: LogLevel, msg: string | number, args?: any[]) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since it's not private anymore, is there any reason to use the _? (I'm assuming we use the convention of adding the underscore only for private vars)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you are right. putting back into private. we don't want to access it directly, accept for a special single case during validation where we want to force a log message no matter the log level.

Comment thread src/logger/index.ts Outdated
Comment on lines +77 to +78
if (format) msg = _sprintf(format, args);
else msg = `Message code ${msg}${args ? ', with args: ' + args.toString() : ''}`;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use Ternary operator here to avoid the if else statement:

msg = format ? _sprintf(format, args) : `Message code ${msg}${args ? ', with args: ' + args.toString() : ''}`;

Comment thread src/logger/index.ts Outdated
function sprintf(format: string = '', args: any[] = []): string {
// exported for testing purposes only
export function _sprintf(format: string = '', args: any[] = []): string {
var i = 0;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use let instead of var

} else if (typeof debugValue === 'string' && isLogLevelString(debugValue)) {
return debugValue;
} else {
return undefined;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there an scenario where undefined is a valid case? If not, maybe the 'last resort' return should be the NONE logLevel (I may be missing a lot of context, but usually you try to avoid returning an undefined value).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

returning undefined is the way the getLogLevel "validator" tell us that the provided input (debugValue param) is invalid.
Other validators, in the case of invalid input, either: (a) logs a message and return a default value, or (b) throws an error. In the getLogLevel case, the former was not possible (it doesn't have the logger instance to log the error), and the later I think is overkill in terms of extra code.

@emilianofant-split emilianofant-split left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@EmilianoSanchez
EmilianoSanchez changed the base branch from logger_polishing_log_messages to logger_refactor_baseline March 25, 2021 18:58
@EmilianoSanchez
EmilianoSanchez merged commit 0d08ebd into logger_refactor_baseline Mar 25, 2021
@EmilianoSanchez
EmilianoSanchez deleted the logger_improvements branch May 20, 2022 15:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants