txnlab / use-wallet Goto Github PK

I propose the addition of returning the value 'isReconnecting' from the useWallet hook.
There are various use cases where this might be useful, but the most glaring one that comes to mind is the following:

• there is a page X that can only be visited after authentication, and only address Y is authorised
• if the user visiting page X is not address Y, then a redirect is made to another page

however, suppose that:

• the user with address X has previously made the wallet connection on the site
• the user directly accesses the url of page X (not from client-side browsing, but directly by entering the url in the browser bar)

In this scenario, as soon as the user lands on the page, a check will be made to see if the address with which the user is connected is authorised.
But since the reconnection takes an arbitrary amount of time, most likely at the time the check takes place, the reconnection has not yet taken place and so the redirect is made to another page.
In such a circumstance, a variable such as 'isReconnecting' is required to have control.

I am using walletConnect to connect another blockchain via (rainbowKit with wallet-conenct option) while enabling walletConnect in use-Wallet for algorand as well,

This cause an error of Failed to execute 'define' on 'CustomElementRegistry': the name "wcm-button" has already been used with this registry, seems like its caused by the @walletconnect/modal-sign-html when initializing the wallet-connect registering something twice..

Any idea how can i solve this?

Add a new client to support the KMD wallet interface

This is a holdover from the original MyAlgo implementation (pre ARC-0001) that only supported signatures by a single account per group.

NFDomains requires signatures from two accounts to verify a linked address, so our solution was to return the entire group (not just the signed transactions) so a second signing request could be initiated.

This is no longer necessary, and adds unnecessary complexity to the library's signing logic. It also breaks with the ARC-0001 SignTxnsFunction type signature by returning unsigned transactions.

Description

Upon installation of the package, if user wants to only use N out of M total supported providers (for example only pera, defly), use-wallet fails to load on the error below if other peer wallet providers aren't installed:

Steps to replicate

1. Clone https://github.com/subtopia-algo/subtopia-js-examples/tree/main/NextJS
2. Exclude myalgo wallet from package.json
3. do yarn install
4. do yarn dev and observe error

Allow SupportedLedger or string name for network during connect call to pass to the wallet
https://github.com/TxnLab/use-wallet/blob/main/src/clients/algosigner.ts#L93

⚠️ If you're using create-react-app and webpack 5 (most newer React projects), you will need to install polyfills. Follow these directions.

This link is broken. Can you update the polyfills instruction?

The js-sdk defines a TransactionSigner interface to be passed to TransactionWithSigner and ATC method calls, it'd make a great addition to this package

Definition here:
https://github.com/algorand/js-algorand-sdk/blob/develop/src/signer.ts#L15-L18

One implementation here:
https://github.com/algorand-devrel/beaker-ts/blob/master/src/web/session_wallet.ts#L130-L144

Issue description

Using Exodus and AlgoSigner wallets in the same Chrome browser causes a conflict

Steps to reproduce the issue

1. Chrome Version 107.0.5304.110 (Official Build) (arm64)
2. Both extensions for Exodus and AlgoSigner are installed and active
3. Visit https://gabrielkuettel.github.io/use-wallet-example/
4. Connect to Exodus and see the account shown in the app
5. Connect to AlgoSigner and the Exodus account will appear under AlgoSigner instead of the account from AlgoSigner (this is most obvious if you use different accounts in Exodus/AlgoSigner

What's the expected result?

Connecting AlgoSigner should not be picking up the account from Exodus wallet; it should return the account that AlgoSigner has.

What's the actual result?

The Exodus account will appear under AlgoSigner instead of the account from AlgoSigner

Additional details / screenshot

If the Chrome extensions are disabled so that only one is active at a time, they will work fine on their own.

The order of the array of providers passed to useInitializeProviders should determine the order of providers returned by the useEffect hook in-app.

The code I used that had setup for connecting Defly wallet previously worked, but suddenly it's not executing the correct behavior. I cannot connect my app to a Defly wallet anymore.

Let me know if there are any fixes in the works.

Similar to its algod client, the WalletManager can create an indexer client that is optionally configurable and updates when the active network changes.

First Off I wanted to thank for at least attempting to build out this library - It's something the Algorand ecosystem desperately needs.

However currently while using remix.run the plugin in unusable with many errors - remix uses Esbuild.
I kept getting build errors that I needed to install dependencies which are marked as peer dependencies in your app
algorand-walletconnect-qrcode-modal and @blockshake/defly-connect even when I install those
I keep getting process is undefined when importing anything from your package in the browser leaving my application unusable.
const NODE_SERVER = process.env.NODE_SERVER || line 14
I tried to set the environment variable but to no avail it breaks no matter what

Also I cloned your repo and in order to run the storybooks - I needed to install webpack as well
Let me know if I can help out in anyway - I think it's a great project to have and hope it becomes the "raindbowkit or web3modla" of algorand.

Hey. I had trouble getting the signer method to work.

https://github.com/TxnLab/use-wallet/blob/main/src/hooks/useWallet.ts#L191-L201

Should this method be filtering the transactions before signing using indexesToSign, rather than after? e.g

const signedTxns = await Promise.resolve(
  signTransactions(blobs.filter((_, idx) => indexesToSign.includes(idx)))
);

I am not sure what the implications are of signing all transactions rather than those specified by indexesToSign.

There are cases when there is a need to perform rekeying back to original addresses, in such cases signer is the current address to which it was rekeyed. However txn fields such as sender, receiver and rekeyTo are all set to original address.

Defly and Pera have an ability to pass authAddress to SignersAccount on their respective signTransactions function. In use-wallet though behaviour is rather implicit and varies depending on wallet provider.

Would be great to have an ability to select which txns in txn group has to be signed by a different signer and cover that in documentation.

The wallet provider clients for Lute Wallet, Kibisis, Exodus and WalletConnect use the Node.js Buffer API to convert byte arrays to/from base 64 strings in their signing methods.

To use Buffer in a browser environment, a polyfill like the buffer NPM package is needed. While Next.js applications support this out-of-the-box, other frameworks (like Vite + React) do not. Without the polyfill, attempting to sign transactions with these wallet providers will fail.

Instead of requiring consuming applications to install the polyfill, wallet provider clients should instead use the native JavaScript methods atob and btoa, which are available in the browser.

See the equivalent fix in v3: #153

Just a suggestion, but for performance purposes (reducing bundle size) would be great if package had a lower footprint. Showing 206k 👍

Thanks for releasing this package! I'm new to the Algo eco, and although the tooling/documentation appears to be thorough, I was getting concerned that I wasn't able to find an existing JS package that abstracts connecting & transacting via the various wallet softwares behind a common interface.

🎁 hiii

i do believe the following function works nice for groups with a single signer or with multiple consecutive, liike:

• txn0: signerA

or

• utxn0: signerA
• stxn1: signerB
• stxn2: signerB

is returned as-is

but in case of non-consecutive, it returns duplicated txns and while duplicating misses the txn on each replaced index, liike:

• utxn0: signerA
• stxn1: signerB
• utxn2: signerA

is returned as:

• utxn0: signerA
• stxn1: signerB
• stxn1: signerB

(note utxn2 is lost and replaced by a duplicated stxn1)

(note² in the examples, signerA will sign a txn, and signerB already signed it so will not sign nothing on this request)

thank you for your awesome work'¡

The library uses ES6 classes with private methods, which Safari started supporting in v15. Older versions of Safari will throw:

SyntaxError: Unexpected private name #<method name>. Cannot parse class method with private name.

Using @rollup/plugin-babel older browsers can be targeted with polyfills.

I can't seem to use useWallet in safari browser, it only works in latest version of safari. i keep getting these errors "SyntaxError: Unexpected private name #composeTransactions. Cannot parse class method with private name."

I would love an alternative approach or solution to this issue thanks.

Here it is set by default to false:

Originally the default is set to true:

https://github.com/perawallet/connect#options

Why asking?

Previously I had a single line of code and I was happy:

const walletProviders = initializeProviders();

Then I've realised that Pera doesn't trigger the popup and I need to manually initialise it.

BUT

Passing an empty array as the first argument enables all of the default providers.

Configuring Pera caused other wallets to disappear and as a consequence I need to add all other wallets manually.

import { PROVIDER_ID, pera, myalgo, kmd, algosigner, defly, exodus, walletconnect } from "@txnlab/use-wallet";

const walletProviders = {
  [PROVIDER_ID.PERA]: pera.init({
    clientOptions: {
      shouldShowSignTxnToast: true,
    }
  }),
  [PROVIDER_ID.MYALGO]: myalgo.init({}),
  [PROVIDER_ID.DEFLY]: defly.init({}),
  [PROVIDER_ID.KMD]: kmd.init({}),
  [PROVIDER_ID.ALGOSIGNER]: algosigner.init({}),
  [PROVIDER_ID.EXODUS]: exodus.init({}),
  [PROVIDER_ID.WALLETCONNECT]: walletconnect.init({})
};

(passing empty clientOptions to use defaults)

Ideally there should be an option to keep the defaults + configure individual wallet.

All wallet connections work, and connections can return a balance amount with provider Id.

The getClient function returns client not found error when signTransactions is called

Error happens with: const signedTransactions = await signTransactions([encodedTransaction]);

Next.js (React) and Nuxt (Vue) examples demonstrate using the library's framework adapters in SSR apps with client side hydration. Now that the SolidJS adapter has been added, it would be helpful to include a SolidStart example app as well.

https://docs.solidjs.com/solid-start

The common issue for React Native projects to adapt React libraries is that some of the libraries have some other React dependencies and react-native doesn't have a corresponding peer.
For example, js Algo SDK has a dependency which I think is crypto and the react-native project cannot directly use the one provided for React.
Hope we can have a react native version (expo preferred)

In v3, if a wallet client requires an SDK/lib to function, its dependency is dynamically imported when the connect method is called. This reduces the overall bundle size of the library, and only loads the (sometimes very large) dependencies if/when they are needed.

Hot module reloading in local development will sometimes reset the active wallet client to its initial state (depending on the HMR implementation). When you try to sign after a hot reload, a "client is not initialized" error is thrown.

The straightforward solution is to re-initialize if the SDK is not detected instead of throwing the error. But I'd also like to investigate why this happens, as I would expect HMR to preserve state between reloads.

My use case involves leveraging a hot wallet to sign some transactions in a group. The sender needs to sign some other transactions, but the group cannot be signed when using the WalletConnect client. Note - it does work when using the Pera client.

I was encountering these errors:

Someone else posted on Discord:

Source: https://discord.com/channels/925410112368156732/1039592016704721019/1051855605003984938

Better error message

AlgoSigner:

Exodus:

It's not really an error, someone does not have an extension installed, first thing that comes to mind:

console.warn("AlgoSigner not initialised. Reason: no extension installed.")

Something that would explain what is happening rather than sea of red in the console.

Related to #152 which fixed this for the wallet clients' public methods

I have tried to do npm install but it has failed with errors

Could not resolve dependency:
npm ERR! peer algosdk@"^1.23.2" from @blockshake/[email protected]

Then i upgraded defly connect, and got

Could not resolve dependency:
npm ERR! peer algosdk@"^1.23.2" from @perawallet/[email protected]

.. many other packages are not updated in the packages.json, so i did ```npm i --legacy-peer-deps`` but audit shows

23 vulnerabilities (22 high, 1 critical)

i am not able to run npm update --save because of

Could not resolve dependency:
npm ERR! peer rollup@"^2.28.2" from [email protected]

Then i did yarn install and it has passed, but yarn audit shows

Severity: 63 High | 14 Critical

Hello,

I am trying to send a transaction and got the following error:

RangeError: offset is outside the bounds of the DataView
readU8 Decoder.ts:550
readHeadByte Decoder.ts:430
doDecodeSync Decoder.ts:210
doDecodeSingleSync Decoder.ts:124
decode Decoder.ts:120
V decode.ts:58
decode encoding.ts:66
decodeSignedTransaction transaction.ts:1360
sendRawTransactions index.js:147
sendTransactions index.js:3831
startTxn Transactions.tsx:107
handleShippingSubmit Store.tsx:136
React 29

The line causing the issue is:
await sendTransactions(stxn, waitRoundsToConfirm);

And stxn is a UintArray:

preSignedTxn
Uint8Array(321) [ 131, 164, 115, 103, 110, 114, 196, 32, 130, 195, … ]
​
[0…99]
​
[100…199]
​
[200…299]
​
[300…320]
​
buffer: ArrayBuffer { byteLength: 321 }
​
byteLength: 321
​
byteOffset: 0
​
length: 321
​
: Uint8Array.prototype { … }
Transactions.tsx:106

Is there anything I am missing here? Is the length wrong?

Following the steps in the readme, i've added wallet providers to app:

  const providers = useInitializeProviders({
    providers: [
      { id: PROVIDER_ID.DEFLY, clientStatic: DeflyWalletConnect },
      { id: PROVIDER_ID.PERA, clientStatic: PeraWalletConnect },
      { id: PROVIDER_ID.DAFFI, clientStatic: DaffiWalletConnect },
      { id: PROVIDER_ID.EXODUS }
    ],
    nodeConfig: {
      network: 'testnet',
      nodeServer: 'https://testnet-api.algonode.cloud/',
      nodeToken: '',
      nodePort: '443'
    }
  })
...
  return (
    <WalletProvider value={providers}>
      <RouterProvider router={router} />
    </WalletProvider>
  )

Then, on a page i have:

import { useWallet,
  DEFAULT_NODE_BASEURL,
  DEFAULT_NODE_TOKEN,
  DEFAULT_NODE_PORT } from '@txnlab/use-wallet'
const algodClient = new algosdk.Algodv2(DEFAULT_NODE_TOKEN, DEFAULT_NODE_BASEURL, DEFAULT_NODE_PORT)
...
const { activeAccount, activeAddress, signTransactions, sendTransactions } = useWallet()

const suggestedParams = await algodClient.getTransactionParams().do();
const ptxn = algosdk.makePaymentTxnWithSuggestedParamsFromObject({
        from: activeAddress,
        suggestedParams,
        to: constants.receiveWallet,
        amount: algosdk.algosToMicroalgos(total/algoInUsd/1000),
        note: new Uint8Array(Buffer.from(noteKey)),
      });
try {
      const encodedTransaction = algosdk.encodeUnsignedTransaction(ptxn)
      const signedTransactions = await signTransactions([encodedTransaction])
      const waitRoundsToConfirm = 4
      const { id } = await sendTransactions(signedTransactions, waitRoundsToConfirm)

      console.log('Successfully sent transaction. Transaction ID: ', id)
} catch (error) {
      console.log("Couldn't sign txn", error);
}

Testing with Pera connected using Pera Web, and when signing that tx i'm sent to Pera which shows TESTNET since i have the node set to testnet, i get:

Network mismatch
Your wallet is connected to a different network to this dApp. Update your wallet to the correct network (MainNet or TestNet) to continue.

Is there something i'm missing or overlooked? I have connected to Pera using essentially the demo code (with ui formatting), with testnet set, and restarted the app a few times but i cannot gewt it to connect to testnet.

Any help is much appreciated.

I am seeing the following error when attempting to disconnect a Pera client:

Unhandled Runtime Error
TypeError: Cannot read private member #client from an object whose class did not declare it

Call Stack
Object.disconnect [as callback]
node_modules/@txnlab/use-wallet/dist/esm/index.js (1127:0)
eval
node_modules/@walletconnect/core/dist/esm/events.js (41:0)
Array.forEach
<anonymous>
EventManager.trigger
node_modules/@walletconnect/core/dist/esm/events.js (35:0)
WalletConnect._handleSessionDisconnect
node_modules/@walletconnect/core/dist/esm/index.js (633:0)
WalletConnect.killSession
node_modules/@walletconnect/core/dist/esm/index.js (418:0)

The error only appears to happen when the webpage is reloaded after the client is set as active.

If someone wants to use the default configuration for localnet it should work by simply setting network: NetworkId.LOCALNET and not requiring a custom algod configuration.

Just a suggestion for cases when it's not possible to fully e2e test things like perawallet or myalgo, a simple in-browser mnemonic account is useful for e2e tests in tools like cypress, selenium, playwright because it's easier to automate input of a mnemonic phrase rather than automation real providers.

Can function similar to the existing KMD provider - on select it asks for a passphrase of an account and that's it. Related documentation or warnings can be supplied that it's only recommended in testing/dev environments.

Let me know if more examples of how this provider can be useful for ui testing just let me know. Also if you'd agree that this is useful i can try the initial pr draft myself - i believe it should be relatively easy to implement.

the is a way to reinitialize the providers? without recompiling the project for switching networks on the fly like testnet mainet, I was trying to do it but I guess "useInitializeProviders" don't support this behavior thanks!

Suggestion 1 - Turning repo into more generalist utility that isn't locked to react hooks only

Just had a case recently when using this inside a vue project could have been extremely helpful but since the main way to interact with the library is via useWallet and its all react hooks based - how hard would it be to make it generic to be able to work with other frameworks?

At the end of the day - walletconnect, algosigner, peraconnect, myalgo and etc are all stack agnostic and aren't locked to react only.

@gabrielkuettel @pbennett what do you guys think about potentially morphing the repo into more generalist utility that can work with vue composition api, other frameworks and generally not be tied to use via react hooks only.

Suggestion 2 - Vite support

Vite is pretty fast and performant tool that lots of project prefer over things like webpack these days. They seem to have this ideological preference to avoid using node specific packages in frontend projects. Because of that walletconnect has tons of issues with it out of the box. Just as a minor suggestion - might make sense to validate whether there are no out of the box issue with vite if any react based projects using that would like to use use-wallet hooks.

Hi, I noticed that on mobile, some users get double transactions, therefore get an overspend error sometimes, and it throws an error. How can I get some logs about that ?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• chore(deps): update dependency eslint to v9
• chore(deps): update dependency release-it to v17
• chore(deps): update dependency rollup to v4
• chore(deps): update dependency rollup-plugin-dts to v6
• chore(deps): update dependency sass-loader to v14
• chore(deps): update dependency style-loader to v4
• chore(deps): update dependency typescript to v5
• chore(deps): update storybook monorepo to v8 (major) (@storybook/addon-actions, @storybook/addon-essentials, @storybook/addon-links, @storybook/builder-webpack5, @storybook/react)
• chore(deps): update typescript-eslint monorepo to v7 (major) (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• fix(deps): update dependency immer to v10

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update all non-major dependencies (@babel/core, @babel/preset-env, @babel/preset-react, @babel/preset-typescript, @magic-ext/algorand, @rollup/plugin-commonjs, @testing-library/react, @types/node, @types/react, css-loader, eslint, eslint-plugin-react, eslint-plugin-react-hooks, magic-sdk, postcss, react, react-dom, rimraf, sass, zustand)
• chore(deps): update dependency @magic-ext/algorand to v23
• chore(deps): update dependency @testing-library/react to v15
• chore(deps): update dependency css-loader to v7
• chore(deps): update dependency magic-sdk to v28
• chore(deps): lock file maintenance
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Apps that have installed https://github.com/TxnLab/use-wallet/releases/tag/v2.6.0 or https://github.com/TxnLab/use-wallet/releases/tag/v2.6.1 will encounter build failures if @magic-ext/algorand is not installed, even if they are not configured to support the Magic.link provider.

Although the Magic SDK is passed to the useInitializeProviders configuration object via the clientStatic or getDynamicClient properties, the Algorand extension is directly imported by the Magic provider client, making it a required dependency.

It must also be passed to the configuration object:

const getDynamicMagicSdk = async () => {
  const Magic = (await import('magic-sdk')).Magic
  return Magic
}

const getDynamicAlgoExtension = async () => {
  const AlgorandExtension = (await import('@magic-ext/algorand')).AlgorandExtension
  return AlgorandExtension
}

const providers = useInitializeProviders({
  providers: [
    {
      id: PROVIDER_ID.MAGIC,
      getDynamicClient: getDynamicMagicSdk,
      getDynamicExtension: getDynamicAlgoExtension,
      clientOptions: { apiKey: '<API_KEY>' }
    },
    // ... other provider configurations
  ],
})

The library should not import any SDKs/dependencies for wallet providers (besides type imports). This should be handled by the consuming application on an opt-in basis, depending on which wallets it supports.

Apps that support the Magic.link provider are unaffected, since they must install its dependencies for it to work.

authAddr is required for a rekeyed account.

Here is their spec:
https://github.com/PureStake/algosigner/blob/develop/docs/dApp-integration.md#transaction-requirements