Add utility to get configured network

[gregsantos]

FCL Scripts might rely on and import deployed contracts.
We need a reliable way to get configured access node network for use in importing
contracts conditionally based on this network.

There is an issue in the pipeline to add an endpoint to the configured access node which will return necessary info.
We should implement a temporary fix that can be used throughout the lib and replaced asap.

It can be based on the current pattern, which checks for flow.network in FCL config and throws if not set.

It might include a call to a known account on a maininet (FLOW Token Address), and fall back to testnet if account doesn't exist.

const network = await config.get("flow.network")

invariant(
  network,
  "FCL configureDependencies Error: Missing configuration value for 'flow.network'"
)

[bluesign]

I would go with script, something like:

pub fun main(): String {

  var networkCodeWords = {
    "MAINNET": UInt64(0x0),
    "TESTNET": UInt64(0x6834ba37b3980209),
    "EMULATOR": UInt64(0x1cb159857af02018)
  }

  for network in networkCodeWords.keys{
    if getAccount(Address(UInt64(0xe467b9dd11fa00df) ^ networkCodeWords[network]!)).balance>0.0 {
      return network 
    }
  }

  return "UNKNOWN"
  
}

[gregsantos]

Thanks @bluesign !
We like this approach as well.

What addresses are you using in your example script?

[bluesign]

Those are network codewords, by xoring with 0xe467b9dd11fa00df you get the account at index 1. which is Service Account

This depends on FVM behavior, though I don’t think it will change. ( just incase I cc @janezpodhostnik )

[bluesign]

There is also simple network addressing. ( which is not covered here ) used in playground as 0x1 0x2 etc

[gregsantos]

@huyndo @chasefleming We should also send the connected network as part of the execService config for use by the wallet.
Maybe a new issue, but would be nice to get in next release if this is completed

[chasefleming]

@gregsantos @huyndo Send it in the Discovery API call to in discovery/services.js as well. I could see it being useful there. For example, if you wanted to call a generic Discovery endpoint without specifying the network on the url path and it is smart about figuring out which to return based on that. Some of these should probably come from one place so we don't forget to keep updating both. Maybe a shared function for pulling client config.