feat: add multi explorer support

[arihantbansal]

Problem

gill only supports Solana Explorer right now. It's good to allow flexibility according to dev's personal preference of explorer.

Summary of Changes

Add a new optional parameter in getExplorerLink where user can specify the explorer they want to use for the link, defaults to Solana Explorer.

Fixes #

Solves #206

[changeset-bot]

⚠️ No Changeset found

Latest commit: 5ab5273

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[beeman]

One of the challenges here is that not all explorers have the same API for selecting different clusters. So while the examples in your tests may work for the mainnet link, it breaks when on Devnet.

Most notably solana.fm breaks the contract here:

This works:
https://explorer.solana.com/address/BEEMANuMhmSwTukEUhBbosH5zHpnaTeno9atgCfc5hgi?cluster=devnet
But this breaks:
https://solana.fm/address/BEEMANuMhmSwTukEUhBbosH5zHpnaTeno9atgCfc5hgi?cluster=devnet

I've suggested to fix this numerous times but solana.fm doesn't care about it.

[nickfrosty]

@beeman is absolutely right. This was one of the reasons that I did not add other explorers originally

[arihantbansal]

Ah okay - it seems like solana.fm uses cluster=devnet-solana for devnet. Maybe we could add that to EXPLORER_CONFIG and modify the URL generated without changing solana cluster moniker elsewhere

[nickfrosty]

That's definitely an option, either way some explorers need to have custom config for different scenarios. But that also bloats the function to handle these one offs. Most devs will always use the same explorer and not the others.

Part of me thinks it's a better idea to just have a different function for each explorer, but that also duplicates codes

[beeman]

In the previous iterations of the create-solana-dapp templates we shipped a getExplorerUrl function that would decide the cluster dynamically, based on what the app cluster was set to. One reason this was done is that it gives you a point to make changes like this.

https://github.com/solana-developers/template-next-tailwind/blob/2f824957c6541a0510d0884282d9576c61234a5a/src/components/cluster/cluster-data-access.tsx#L99-L117

However, I think having different functions for each explorer might be the best solution here. It's trivial to implement another one, and anyone will only bundle in only one of these functions. So independent of how many explorers are supported, any person will only pay the price for 1.

Having '1 function do 1 thing' also seems in line with the rest of Gill and Kit.

I think something like this is might be good:

function getExplorerLink() {}
function getExplorerLinkOrb() {}
function getExplorerLinkSolanafm() {}
function getExplorerLinkSolscan() {}

[nickfrosty]

Yeah, I'm game for this

[arihantbansal]

Should be good for review now @nickfrosty @beeman

[macalinao]

https://github.com/macalinao/grill/blob/master/packages/gill-extra/src/build-get-explorer-link-function.ts

I have a solution here that works a bit more abstractly so we don't have to keep supporting a ton of explorers manually in this library, let me know if you have thoughts

[nickfrosty]

https://github.com/macalinao/grill/blob/master/packages/gill-extra/src/build-get-explorer-link-function.ts

I have a solution here that works a bit more abstractly so we don't have to keep supporting a ton of explorers manually in this library, let me know if you have thoughts

@macalinao god no. there is no reason for all that complexity to create a link.

[GuiBibeau]

This is looking clean! I'd like to see a few things before this gets merged:

• add to the JsDocs comments the parameters of the functions

/**
 * Description of the function.
 * @param {Type} parameterName - Description of the parameter.
 */

• look into if moving a few stuff to constants since they are repeated in many places in the code. I know these URLs likely won't change much in the future due to the nature of an explorer but it's an easy win and good practice.

I will leave an approval since i don't think any of those two comments warrant further back and forth but i'd really appreciate if we do them before merging given they take 5 minutes to do.