feat(frontend): New derived store currentBtcAddress

[lmuntaner]

Motivation

The address within ETH or IC doesn't change, but in BTC, there is a different address per network. However, I still want to reuse the components across those three networks.

In this PR, I introduce currentBtcAddress which returns a btc address (or not) depending on the current selected network which comes from networkId derived store.

Changes

• New derived store currentBtcAddress.

Tests

Used and tested in #2528

[lmuntaner]

@peterpeterparker @AntonioVentilii-DFINITY please review

[AntonioVentilii-DFINITY]

IIRC, we decided to start creating tests for derived stores. Can you please provide one if possible?

[AntonioVentilii-DFINITY]

Performance-wise, is it more efficient if conditions or a mapper? Honest question

[lmuntaner]

I don't know, but I don't think it matters much the performance difference if any in this case.

[peterpeterparker]

For which feature exactly do we need this derived store?

Context: I think we have too many derived stores. Generally speaking, our goal is also to use more contextual stores and replace some global stores. That's why, for example, the token is deprecated. I'm just asking to ensure there is a use case that absolutely requires another derived global store.

[lmuntaner]

For which feature exactly do we need this derived store?

Context: I think we have too many derived stores. Generally speaking, our goal is also to use more contextual stores and replace some global stores. That's why, for example, the token is deprecated. I'm just asking to ensure there is a use case that absolutely requires another derived global store.

It's for the bitcoin integration. To use in the send modal for btc and probably in the receive modal or wherever we use it.

@AntonioVentilii-DFINITY I also added tests.

But since we are on a tight deadline, could I ask to avoid changing patterns now and stick to simple ways? I'm all-in to add tests in general, but I'm not sure the moment to start doing it is when we have a deadline.

[peterpeterparker]

To use in the send modal for btc and probably in the receive modal or wherever we use it.

If I'm not wrong, in the "Receive" modal we don't display just one address but all Regtest, testnet and prod Bitcoin address separatly.

In the send modal we use a context and avoid the usage of global store.

Are you sure we need this global derived store?

[lmuntaner]

To use in the send modal for btc and probably in the receive modal or wherever we use it.

If I'm not wrong, in the "Receive" modal we don't display just one address but all Regtest, testnet and prod Bitcoin address separatly.

In the send modal we use a context and avoid the usage of global store.

Are you sure we need this global derived store?

I meant the Receive modal in the transactions page. Isn't there one?

I used a different send modal. My idea is to create a new BtcSendTokenWizard.

And inside there I reuse some components.

I use this derived store to pass the source to SendSource, both for IC and ETH you use a global store. That's why I decided for a global store.

Is there another way to align the code than doing it and then reviewing in a PR? I feel I lose quite some time back and forth with multiple small PRs.

[peterpeterparker]

I meant the Receive modal in the transactions page. Isn't there one?

I mean the Receive modal on Chain Fusion on the main page

I used a different send modal. My idea is to create a new BtcSendTokenWizard

We should probably avoid using a global store in this particular "Send" modal, assuming that, similar to ETH/ERC20, we might reuse it for both Bitcoin and IC. For instance, when the user converts BTC to ckBTC and ckBTC back to BTC. This may be far off, but we faced difficulties refactoring ETH when we needed to, so I think it's worth anticipating any potential challenges.

Furthermore, our existing IC and ETH modals use a SendContext, this new "Send" modal should use the same pattern.

That being said, if there are indeed two or more uses of the same store, I agree it makes sense to add a derived store. Once again, my original point is that we should be cautious with these kinds of stores. If you are sure it's the case, then so be it.

I feel I lose quite some time back and forth with multiple small PRs.

I'm definitely not going to rush PR reviews when it comes to core features.

[lmuntaner]

We can accomplish the same functionality without a global store. Therefore, closing this PR.