Thoughts about this module architecture

[aiinkiestism]

This is just my current thought.
As a premise, this module is utilized as a button or onClick hook for buttons. Besides, this module and its providing UIs should support as many chains as possible, though there are some exceptions.

spec

• Users can use the function as a onClick hook with buttons of any UI frameworks. Plus, it's callable within business logic, not just about event-driven.
• Users can use the button with the function, and customize it
  base will be raw button element?

behavior of the function

first of all it really depends on the chain and wallet... but I assume

if it's a specific chain which famous wallet wrappers still haven't integrated

• detect wallet
• if it's not detected connect
• call the function

if it's supported by some famous wallet wrappers like WalletConnect

• call some wallet connection UI or/and logics, or pass state
• call the function

[aiinkiestism]

my first actions will be

• decide which chain (and wallet wrappers) and write logics
  this is the top priority
• create button base(s) since it won't be not difficult and I want to be aware of UI

[aiinkiestism]

the button should have the onClick behavior, but some users should include other logics in onClick behavior not just about this module function.
For this use case, the button's onClick must accept function. By default if it's not passed, onClick function will be only this module behavior, but if it's passed with before or after option, each function is called by the order, which means the button should have at least function order option.

[aiinkiestism]

would implementing major frameworks' buttons be better than implementing only pure button?
or implement both?

implementing vue and react buttons means I should break dnt-based architecture in some way.

[aiinkiestism]

just module would be more customizable and maintainable, so no pure button (vue and react buttons are nice-to-have but almost necessary)

[aiinkiestism]

done a little research
EVM-compatible network wallet connector = Wallet Connect (Web3Modal) or RainbowKit

first go from EVM-compatible Rainbow, and go to Cosmos(Keplr?), Bitcoin, Solana, Polkadot and Kusama, ...

UX change because detecting multiple networks is ... bluh.

• first users choose a token or network
• then connect or if the user already connected in the app, pass the wallet state and functions to button
• users fill in the parameter, like amount
  I'm thinking the default maximum amount is set, though it is changeable by developers *
• transfer start being called
• finish modal or toast

other specs

• buttons need to know recipients' addresses of each network
  if not provided, users cannot choose the network nor its corresponding token
• (optional) *

[aiinkiestism]

ethers-io/ethers.js#2892

[aiinkiestism]

rainbow is heavily dependent on wagmi and react...

[aiinkiestism]

Web3Modal of WalletConnect feels fine!

[aiinkiestism]

These days I kind of got the feeling that this module should have wallet wrapper layer itself, if I should put my 100 percent efforts to this project.

[aiinkiestism]

default testnet

[b-bot]

Don't EVER call me a junior.