[BUG] config() race condition related to top-levelsetChainIdDefault() call

[jribbink]

Current Behavior

This "issue" is a bit trivial since it affect end behaviour, but... If you are to run the following code you will notice a bunch of console errors.

import * as fcl from '@onflow/config';
setTimeout(() => {
  fcl.config({
    'accessNode.api': 'https://rest-testnet.onflow.org',
  });
}, 0)

However, if you run this code, you will notice no errors appear.

import * as fcl from '@onflow/config';
fcl.config({
  'accessNode.api': 'https://rest-testnet.onflow.org',
});

This is because we have a race condition. (i.e. if we are not to set the configuration until the call stack/job queue has emptied, we will see this error). This becomes an issue in something like a react app where we configure fcl in a useEffect hook which is not run immediately.

The specific culprit is this line of code which runs at the top-level (thus right when fcl loads).

fcl-js/packages/fcl/src/default-config.js

Line 19 in 2e5ca45

setChainIdDefault()

While this bug exists, it does not affect app behaviour because ultimately the chainId is always accessed through getChainId() within fcl & in this function the chain ID is always resolved if it doesn't know it already.

fcl-js/packages/fcl/src/utils/getChainId.js

Line 37 in 2e5ca45

export async function getChainId() {

However, the error can throw developers off, so it is probably best to get rid of.

Expected Behavior

Don't show this error at startup if config hasn't been set 😎.

I suggest one of the following:

1. Just ditch the top level function (but this will slow down first fcl request)
2. Do a naive check in setChainIdDefault of whether config.get("accessNode.api") is defined, don't attempt to resolve chainId if it has not been (still imperfect, basically as performant as soln. 1 unless user configures fcl @ top level)
3. Resolve chainId on accessNode.api change or even just any config change is good enough. (this would be ideal solution)

Steps To Reproduce

Shown above.

Environment

- OS: MacOS Monterey 12.6.5
- Node: v16.18.1
- npm: 8.19.2

What are you currently working on that this is blocking?

Nothing. Bug does not affect application behaviour.