React Native to Go connection

From Status Wiki
This is the approved revision of this page, as well as being the most recent.
Jump to: navigation, search

Function calls

All status-react to status-go calls are centralized in StatusModule (android) or RCTStatus (ios). General structure of methods is:

  • caller provides a callback
  • check for availability of current Activity
  • if available: call a static method on StatusGo via an ExecutorService (or sometimes a Thread) and use its result as callback payload
  • else: ivoke callback with false as payload

From RN perspective calls do not block, result is provided through callback execution. StatusGo is a C library generated from go cade embeded in Status apps. On android it is packaged as a JNI aar (generated using xgo).

StatusGo directly expose status-go methods marked for exportation. Those methods are defined in cmd/statusd/library.go and marked as export. go side calls are then dispatched to geth/api then geth/jail Data is provided to the go layer as primitive types and retrieved RN side as JSON.


status-go can directly send events that will be received RN side. It achieves that by directly calling signal-event using some JNI glue.

StatusModule is also used as a react context listener that emits event to the RN layer.

status-react listens to those events via gethEvent then dispatched by a re-frame handler.

Go to React Native Signals

Intention of Signals

Signals allows the notification of status-react about asynchronously happening events in status-go. Normally during the interactive usage of the frontend it makes calls to the backend. Some of them get synchronous answers, others due to the nature of the technology can only answer later while the frontend shall not be locked. Here the status-go sends signals containing more detailed information about the event. Registered handlers in status-react receive and process these signals.

The following signals are currently in use.



transaction.queued is triggered when an incoming transaction is enqueued.


transaction.failed is triggered by the transaction response handler in case of an error.


node.started is triggered when the underlying node is started.


node.ready is triggered when the underlying node is fully ready. This considers the backend to be fully registered.


node.stopped is triggered when the underlying node is fully stopped.


node.crashed is triggered when the underlying node crashed. chaindata.removed


chaindata.removed is triggered when the underlying node's chain data is removed.