[BUG] useAccount hook only returns mainnet stxAddress

[Xzirez]

Description: When logging in using testnet the useAccount hook will only return the mainnet stxAddress.

Steps to reproduce:

1. Initialize a new microstacks template project
2. Login using a test net account
3. Observe account address

Im attaching some images from the microstacks template app:

[aulneau]

The address will change depending on if you put mainnet or testnet in the client provider in the example. Make sure you're on the latest versions for each, as there was a change recently that made this behavior more explicit.

@Xzirez let me know if this doesn't work for you, or if you have a repo I can look at :)

[Xzirez]

@aulneau Thank you for the insight. I put testnet in the network prop, but the useAccount hook still gives me the mainnet stxAddress. I am on version 1.0.4. I can make a minimal reproduction of the issue?

I will share some of what I notice in the source code. Keep in mind im new here and mostly worked with EVM.

1. I see that there is a testnet class, but it does not seem to implement all the fields compared to the parent class. Mainnet implements much more and testnet just inherits. Does it need to implement them as well or are they kinda standard for both?:

2. I noticed this config file which looks similar to the web3 library for EVMs config solution. However, in EVM I can pass this object to the provider, with the configurations I need. Is there any reason for not giving me this flexibility? Maybe there are not as many options with stacks?

3. Then I am wondering and this might be a super stupid question, but where are the tests for the repo? I wanted to just write a short unit test to confirm if there is an issue or not, but could not locate the folder.

In case I seem picky, I just wanna mention the library is really clean. Super good job. Just trying to understand some stuff here :)

EDIT: I found the client prop so question 2 is obsolete i suppose.

[aulneau]

Wonderful, thank you for all the questions/comments! I love when folks really dig in, so you don't seem picky to me at all :)

for question one, you can see here: https://github.com/fungible-systems/micro-stacks/blob/d1aad3931e324a020124f0b99ce30d83b133fa08/packages/core/src/network/index.ts#L155-L162

The StacksTestnet and StacksMocknet are basically the same as StacksMainnet/StacksNetwork, but with the version, chainId and url changed to the defaults for each.

Then I am wondering and this might be a super stupid question, but where are the tests for the repo? I wanted to just write a short unit test to confirm if there is an issue or not, but could not locate the folder.

The tests are spread about, there are many tests for the primary library micro-stacks found in packages/core. there are few if any tests for the framework specific integrations, or the client library. I would absolutely love some help with testing if you'd like to contribute. We use vitest for our tests, and you can check out the core package to see how to add some if you're interested.

EDIT: I found the client prop so question 2 is obsolete i suppose.

can you share more about your use case with this question?

[Xzirez]

The tests are spread about, there are many tests for the primary library micro-stacks found in packages/core. there are few if any tests for the framework-specific integrations, or the client library. I would absolutely love some help with testing if you'd like to contribute. We use vitest for our tests, and you can check out the core package to see how to add some if you're interested.

I would like to contribute yes. It's super nice if I can start with some tests. I will check if there is an issue/bug here :)

can you share more about your use case with this question?

It was more a question of DI for testing. If I cannot pass the client/config directly through props it would be harder to test. The more flexibility in composition the easier.

For the classes "StacksTestnet" and "StacksMainnet". Im not sure if the testnet inheriting from the mainnet is a good idea. Will there only be two net classes at all times? In EVM the handling of nets and tokens became very complex over time since more and more L2/L3s were introduced. It's one of the main challenges with EVM packages. To support an ever-increasing and changing variety of L2s. I feel it would be wise to keep everything that can change depending on a different token isolated from each other. Again this could be completely redundant, im trying to create some discussion is all. I believe the nets all will follow a similar protocol.

[aulneau]

I would like to contribute yes. It's super nice if I can start with some tests. I will check if there is an issue/bug here :)

Awesome, that would be great, please let me know how I can help :)

It was more a question of DI for testing. If I cannot pass the client/config directly through props it would be harder to test. The more flexibility in composition the easier.

In the case of @micro-stacks/react, it is the case that all props for ClientProvider are the parts of the ClientConfig type, you can either pass them directly as props, or singularly as client, see https://github.com/fungible-systems/micro-stacks-examples/blob/334676cdc23ad10f1eccb45b895fbe5e33c18fe7/examples/with-nextjs/pages/_app.tsx#L23-L27

For the classes "StacksTestnet" and "StacksMainnet". Im not sure if the testnet inheriting from the mainnet is a good idea.

Yeah, I would agree that over time it might be better to do something else, but for now, the keys that differentiate a network are:

• chainId
• version
• networkUrl

Everything else should be generally the same :) as subnets come online, it will likely be good to rethink how this works.

[Xzirez]

Hi again,

Can i message you somewhere else?

I Started testing the useAccount hook, but i likely need some general helper methods to test this efficently, which is where i need some pointers :(

[aulneau]

Sure -- i'm in the stacks discord under the username aulneau#8426, feel free to friend request :)