In the JS library creating the client only creates the object, it does not attempt to connect to the App Config instance. You will not know if a connection was successful until you try to retrieve data. This is a departure from the .NET SDK, which is usually setup to load all values into the environment variables as part of startup. You could do something similar in your JS application. If you use it as-is with values retrieved on demand, you could create a wrapper that implements the failover at the time you retrieve the value. That would also give you a place if you wanted to implement some form of value caching- instead of loading all values at startup, cache them in memory when each is retrieved so you still only have to request the value from the store once instead of every time they are used.
The most common reason for a failed connection during initial setup is misconfigured authentication. After that is working, network issues between your application and Azure could cause the connection to fail. The third reason I can think of is an outage within Azure itself. Having the secondary endpoint pointed at a different Azure region won't cover 100% of possible scenarios, but it will greatly reduce the chance of connection failure for both stores. To cover the case of a significant outage that prevents connections to both stores, a final fallback might be to keep something in the environment variables that can keep your application running until you are able to connect to one of the regions.