@civic/common-gateway-react

Publising @civic/common-gateway-react

1. Bump common-gateway-react version and add -betaX
2. Publish this version to npm
   • yarn publish --tag beta
3. Set this as the version in the RC
4. PR and have it tested
5. When all good, remove -betaX and release a formal version
6. Set this as the version in the RC
7. PR this so it can go out in the next release
   • This will not be released unless an explicit ‘rc’ tag is added i.e. solana-rc-0.9.1

Orchestration: the token creation flow

The main orchestration logic for creating a token is in the 'useOrchestration' hook:

1. when a wallet is connected, a useEffect adds a 'createdOrChanged' listener for that wallet address. This means that when a gateway token is created or changed, a callback will fire
2. The callback onGatewayTokenCreatedOrChanged that fires dispatches 2 events tokenChange and civicPass_check_token_status. tokenChange sets the necessary state variables to handle the end of token creation and civicPass_check_token_status handles displaying the correct iframe screen, depending on parameters
3. The gateway token should be created at the end of a successful token-requested flow, where the transaction to issue the token on-chain has either been sent by the gatekeeper-api (civic-sends), or by the user.
4. In case the there was a problem sending the transaction (in both cases, the tx can seem to have been sent but hasn't actually got through to chain, depending on the state of the network, validator etc.), then the orchestration handles this by initiating a timeout, then showing an error with retry if the token hasn't been found on-chain within this time. In the case where there is no listener for token creation, a polling mechanism is used using the chainImplementation findGatewayToken. In the case where a created listener does exist, then if a gateway token comes into the state at any time during the 'expect token' interval, the timer is cancelled.

Allowed GatewayStatus transitions

The React component needs to take into account 3 external statuses when deciding what the gatewayStatus should be, and what transitions should be allowed. Where the gateway status can be thought of as a combined single value that clients can use to display something to their users

1. the on-chain state: we now emit a 'fetching' status when we start the on-chain lookup, and have a 'complete' status when the check is done. This is stored in the state as fetchOnChainStatus
2. the GK-API state: when we begin the GK-API lookup we emit a getGatekeeperRecord event that sets the gatekeeperRecordState to REQUESTING, the http status code and payloads determine the value on response
3. the iframe data-collection state: if the iframe detects that a validation process exists, it posts a message with this status. The RC stores this state as dataCollectionStatus. The gatewayStatus only takes this status into account if we're still in the data collection phase, i.e. a token request hasn't been made and the gatewayStatus is NOT_REQUESTED