chore(advanced-logic): use currency manager instance

[kevindavee]

Description of the changes

Context

Initiating a CurrencyManager is expensive. I was debugging the computeRequestId function. I'm sharing the logs of my test.

Based on my test, computeRequestId is executed for 130ms. I'm using a M1 Macbook Pro. External network calls (API/DB calls) only take around 20ms (from verifying signature input until signed). So, we still have 110ms of processing time, and it's all local execution. I suspected two things: for loops or a computing-intensive operation such as signing/hashing/encrypting, etc. But apparently, the process that takes much time is CurrencyManager.getDefault(). You can see on the logs there are several .getDefault() calls, and it takes approximately 15ms. A total of 6 calls contribute 90ms from the 110ms local execution 🥲

Change

Inject instantiated currencyManager. I think we should re-use the currencyManager that has been instantiated in the AdvancedLogic class and pass it down to the payment networks unless there are specific reasons why certain payment networks can't use the currencyManager from the AdvancedLogic class.

[KolevDarko]

Good idea, I see there are a lot of for cycles when preparing the currencies.

Another way would be to store a static field the CurrencyManager itself, that way you would modify just one file. But this also works.

[kevindavee]

I think this test was inaccurate. Previously, the AddressBasedPaymentNetwork initialize it's own currency manager; hence the request can be created. Suppose that we only have _TEST currency in the currency manager.

[benjlevesque]

I don't understand what you mean? I don't think this was inacurate, why do you need to add ETH?

[kevindavee]

We need ETH to validate the address.

[benjlevesque]

ah got it. It worked before because the default currency manager was instanciated?

[kevindavee]

Yep. So the instantiated one contains _TEST currency only, and we have another currency manager that uses default list.

[coveralls]

coverage: 87.089% (-0.009%) from 87.098%
when pulling beb5c1d on feat/use-injected-currency-manager
into fc215bf on master.

[benjlevesque]

strange. why is this empty?

[kevindavee]

Yeah, not sure 🤷

[MantisClone]

It's strange that this near-native.ts appears here in this PR. It lives in the near/ directory.

[kevindavee]

Maybe we forgot to delete it 😬 It's there since a while.
https://github.com/RequestNetwork/requestNetwork/blob/master/packages/advanced-logic/src/extensions/payment-network/near-native.ts

[benjlevesque]

I don't understand what you mean? I don't think this was inacurate, why do you need to add ETH?

[alexandre-abrioux]

I agree with @KolevDarko , I think it would be easier to save the default instance after the first call to getDefault(), directly in the CurrencyManager like so:

export class CurrencyManager {

  private static defaultInstance: CurrencyManager;

  /**
   * Returns a default instance of CurrencyManager based on default lists
   */
  static getDefault(): CurrencyManager {
    if (this.defaultInstance) return this.defaultInstance;
    this.defaultInstance = new CurrencyManager(
      CurrencyManager.getDefaultList(),
      CurrencyManager.getDefaultLegacyTokens(),
    );
    return this.defaultInstance;
  }

}

This way, we don't have to change any other code. What do you think?

[kevindavee]

That would work as well @alexandre-abrioux @KolevDarko . However, I still think we have inconsistency issues across payment networks (some are using injected currencies, some are not). And for another reason, to remove dependency with the currency package, as what Benji suggest.

[KolevDarko]

That would work as well @alexandre-abrioux @KolevDarko . However, I still think we have inconsistency issues across payment networks (some are using injected currencies, some are not). And for another reason, to remove dependency with the currency package, as what Benji suggest.

Ok, that's a good benefit, to decouple the packages.

We could do both then, or at least add a comment in the getDefault method that it's heavy

[alexandre-abrioux]

@KolevDarko @kevindavee I agree lets do both then

[benjlevesque]

I've open #1269 for another (middle/long term) approach to this issue