Skip to main content

Overview

The OneSDK uses an event-driven architecture that allows you to listen for and respond to various events throughout the verification lifecycle. Every module and the SDK itself emit events that you can subscribe to.

Event Methods

All modules and the SDK context provide these event methods:

on(eventName, callback)

Registers an event listener for the specified event. Signature:
Parameters:
  • eventName: String or array of strings representing event name(s)
  • callback: Function to call when the event is emitted
Example:

off(eventName, callback)

Removes a previously registered event listener. Signature:
Parameters:
  • eventName: String or array of strings representing event name(s)
  • callback: The exact function reference that was registered with on()
Example:
Do not call off() without parameters on global event handlers. This removes ALL listeners and may break internal SDK functionality.

emit(eventName, ...args)

Emits an event with optional arguments. Available only on the SDK context (not on module instances). Signature:
Example:

Global Events

These events are emitted by the SDK context and are available on all SDK instances.

Common Events

Available on all modules and the SDK context:

SDK-Specific Events

Event Examples

Handling Errors

Monitoring Loading States

Telemetry Events

Telemetry events are used internally by FrankieOne for troubleshooting and diagnostic purposes. You generally don’t need to listen to these events in your application.

Network Status Monitoring

Configuration Events

Wildcard Event Listener

Capture all events for debugging:

Module Events

Each module has its own set of events. Subscribe to module events through the module instance:

Individual Module Events

Component Events

Dynamic components also emit events:

Event Patterns

Async Event Handling

Event Cleanup

Always clean up event listeners when components unmount:

Event Chaining

Chain events to create verification flows:

Error Event Details

The error event provides a structured error object:
Properties:
  • message - Human-readable error description
  • name - Error type identifier (optional)
  • payload - Additional error context (type varies by error)

Error Handling Example

Telemetry Event Structure

Telemetry events can be either a simple string or an object:

Telemetry Event Details

Telemetry events are used internally by FrankieOne for diagnostic and troubleshooting purposes. These events are not intended for use in your application logic or analytics.

Best Practices

  1. Always handle errors: Subscribe to the error event on all modules and the SDK context.
  2. Clean up listeners: Remove event listeners when components unmount to prevent memory leaks.
  3. Use specific events: Subscribe to specific events rather than relying on the wildcard (*) event.
  4. Avoid inline functions with off: Store function references if you need to remove them later.
  5. Don’t block event handlers: Keep event handler logic lightweight. Use async handlers for heavy operations.
  6. Monitor network events: Handle offline scenarios gracefully by listening to network events.
  7. Log telemetry in production: Use telemetry events to monitor SDK behavior in production.

Debugging Events

Log All Events

Event Timeline