Shim window.xnft.solana to window.xnft in `xnft-cli` if `--shim` flag is set

coral-xyz / backpack

🎒 Next level crypto wallet

https://backpack.app

GNU General Public License v3.0

1.33k stars 798 forks source link

Shim window.xnft.solana to window.xnft in `xnft-cli` if `--shim` flag is set #1321

Open hkirat opened 1 year ago

hkirat commented 1 year ago

More context here - https://discord.com/channels/985994296337498182/1011846320677462137/1035620244129071124

hkirat commented 1 year ago

This would be useful to port existing dapps directly over to xnft without any effort

tj-dispatch commented 1 year ago

Okay, so @hkirat -- I don't think we'll be able to do it with a flag, unfortunately. Or maybe at all! So here's the number 1 bad boi that is making this impossible:

https://github.com/coral-xyz/backpack/blob/master/packages/provider-core/src/provider-solana.ts#L59

Problem is, it's the right thing to do. You wouldn't want an app to be able to change the provider object that was injected into the window (for, you know, very obvious reasons when you see it typed out like that haha).

So what do you think the reason is for having the L1 providers and the xNFT providers separate and not the xNFT providers inheriting from the L1s? If it's to be, you know, the provider that works with the Backpack wallet, then maybe we don't need separate providers for L1s and xNFT?

hkirat commented 1 year ago

I think one of the reasons of having them separate is that window.solana can be owned by a wallet that don't support xnft constructs (opening up a popup inside the xnft to sign a transaction). So this would break very often for people who have more than one wallets in their browser.

hkirat commented 1 year ago

The way I was thinking of it was that we introduce a change at the ReactXnft level to replace all window.solana calls with window.xnft.solana when bundling the xnft if --shim is set to true.

tj-dispatch commented 1 year ago

Oh yeah, of course -- but maybe I'm making the wrong assumptions here. My assumptions are:

The xNFT providers implement the same interface as the other providers (EIP1193 or the Solana equivalent)
The xNFT providers are backwards compatible with the others (bc they implement the same interface)
That we'd only be merging the providers inside of the Backpack extension

Can you elaborate a bit more about the ReactXnft one? Were you thinking that on build (or watch or dev) we'd regex replace the js we read in? That still wouldn't really work for iFrame'd xNFTs though.