Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] useAccount hook only returns mainnet stxAddress #162

Open
Xzirez opened this issue Sep 8, 2022 · 7 comments
Open

[BUG] useAccount hook only returns mainnet stxAddress #162

Xzirez opened this issue Sep 8, 2022 · 7 comments

Comments

@Xzirez
Copy link

Xzirez commented Sep 8, 2022

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:

Screenshot 2022-09-08 at 19 47 58

Screenshot 2022-09-08 at 19 48 35

@Xzirez Xzirez changed the title [BUG] useAccount only returns mainnet stxAddress [BUG] useAccount hook only returns mainnet stxAddress Sep 8, 2022
@aulneau
Copy link
Contributor

aulneau commented Sep 13, 2022

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
Copy link
Author

Xzirez commented Sep 13, 2022

@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?

Screenshot 2022-09-13 at 20 16 17

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?:

Screenshot 2022-09-13 at 20 19 39

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?

Screenshot 2022-09-13 at 20 18 44

  1. 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
Copy link
Contributor

aulneau commented Sep 14, 2022

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:

export class StacksTestnet extends StacksMainnet implements StacksNetwork {
version = TransactionVersion.Testnet;
chainId = ChainID.Testnet;
constructor(networkConfig: NetworkConfig = { url: HIRO_TESTNET_DEFAULT, fetcher: fetchPrivate }) {
super(networkConfig);
}
}

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
Copy link
Author

Xzirez commented Sep 15, 2022

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
Copy link
Contributor

aulneau commented Sep 15, 2022

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
Copy link
Author

Xzirez commented Sep 22, 2022

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
Copy link
Contributor

aulneau commented Sep 22, 2022

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

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

No branches or pull requests

2 participants