Fix: adds missing log and improves typing

[lanterno]

Two commits:

1. cleanup and type improvements
2. adds a missing log

[ineiti]

Please put the target?: string back, or give a very good reason not to.

[ineiti]

Why this? When writing target?: string, it is already string | undefined, and you don't need to give the target argument to the method. So you can write:

addToLog('Creating connection QRCode', 'Verifier')

That simplifies the code a bit.

[lanterno]

I wanted to have "Wallet" as a default "target" but can be optionally set to null/undefined.

Using target?: string = "wallet" was what I wanted initially, but it turned out to syntactically incorrect. It's not possible to use ? with a default value.

[lanterno]

The alternative is to use target? : string without a default. But in that case, I'll have to put "wallet" everywhere, and I will not need to put undefined only in one place.

My solution above looked better for me, since I won't need to put "Wallet" everywhere, except for one place where I will need to put undefined

[ineiti]

I wouldn't accept your solution in production code, because somebody skimming over your code will not realize that addToLog uses wallet as the target by default. It will only get clear once you read the definition of addToLog.

[lanterno]

It will only get clear once you read the definition of addToLog.

Reading a function's signature is a requirement to understanding what it does. It only becomes bad if you need to read the implementation of the function to understand what it does.

Since the default value "wallet" is written in the signature, it's not bad.

[lanterno]

However, looking at it..

addToLog('message', 'Verifier') // [Verifier -> Wallet]
addToLog('message', 'Verifier', null) // [Verifier]

looks "counter-intuitive" to me.
This is why I felt uncomfortable as well. But since you strongly see it's not clean, I'll switch to the other approach, with the default being null, and wallet to be added where it's needed.

[ineiti]

When reading code, my preference is:

1. understanding what a method does by its name
2. include the context, comments
3. look at the signature, method comments
4. look at the implementation

When reading lots of code, even having to look at the context, or, worse, looking at the signature of a method, slows down a lot.

Of course this doesn't apply to important methods, where often it is needed to actually look at the method comments, or even the implementation.

But something trivial as addToLog should not need further investigation.

Now, addToLog could've been named addToLogDefaultToWalletDestination, but that's also slowing down reading a lot.

Anyway, as I wrote above, don't worry about this for the moment.

[lanterno]

That's a bit different from how I think about it. I would be happy to discuss that a bit further in person.

Anyway, as I wrote above, don't worry about this for the moment.

Does this equal a PR approval then?