Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Android] useRive remains null when loaded event is delivered before subscription

オープン
  • 何か問題がありますか？
#448 コメント 2 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
react-native, typescript
領域
mobile

調査の方向性

Start by inspecting the useRive() hook and its loaded-event subscription in the v9.8.5 source, then compare its lifecycle with the awaitViewReady() path in @rive-app/react-native. Reproduce the Android timing sequence if possible, including detach and re-attach, and verify that the hook exposes a ready handle when loading precedes subscription without leaving stale listeners.

索引モデルが issue の本文から書いたものです。

説明

Description

On an Android physical device, useRive() can remain null indefinitely even though the native animation is loaded and playing. We observed RiveReactNativeLoaded:<viewTag> being dispatched by the JS event emitter with zero listeners, followed by useRive() subscribing 224 ms later.

As a result, effects guarded on riveRef never apply initial data-binding values. Navigation/re-entry can change the outcome.

Environment

  • rive-react-native: 9.8.3 (runtime reproduction)
  • React Native: 0.83.4, Hermes, New Architecture / Bridgeless
  • Expo: 55 development build
  • Android: 14 / API 34, Samsung SM-A135N physical device
  • StrictMode enabled
  • Remote .riv URL, auto-bind enabled
  • Android Rive SDK override: 11.6.1
  • Existing local patch validates downloaded bytes and uses File + setRiveFile instead of setRiveBytes; diagnostic-only logging was added to native load/emit and JS ref/subscription callbacks. This is not an unmodified-package reproduction.

Observed sequence

Same native view, viewTag=13066. Times relative to native load start:

Time Event
0 ms Native load starts
144 ms Downloaded bytes received
195 ms Native configuration finishes
196 ms Native emits RiveReactNativeLoaded:13066
200 ms JS RCTDeviceEventEmitter.emit executes; listenerCount(eventName) === 0
403 ms Ref callback receives an object without internalNativeEmitter
424 ms First useRive() subscription registered
560 ms Another subscription registered for the same tag
Later No loaded callback received; two waiting listeners remain

We temporarily observed the JS emitter by wrapping emit, recording only loaded-event names, timestamps and listener counts, then invoking the original method. No artificial delay or event replay was introduced in this reproduction. The observer was removed afterwards.

Native emit timing alone is insufficient evidence because delivery to JS can be delayed; another view successfully received an event emitted before its JS subscription. The zero-listener observation above is at actual JS dispatch.

In an earlier occurrence, manually replaying the loaded event for the affected view caused the hook to expose its ref and the existing binding effect to apply successfully. No server state or asset change was needed.

Relevant implementation

useRive() registers the listener only when its ref callback receives a Rive handle, and calls setRef(node) only inside that listener. It does not check whether loading has already completed. A late subscriber cannot recover the missed notification.

There are two associated lifecycle observations:

  • The forwarded ref is attached both to the outer View and to useImperativeHandle, explaining the callback receiving a non-Rive object before the Rive handle.
  • The loaded subscription is removed only on receipt. Detach/re-attach can leave duplicate waiting subscriptions. In the observed failure, the first event was already missed before the subsequent re-attachment.

Reproduction scope

This was captured in an existing app by entering a screen with a remote Rive preview and initial data-binding setters, then navigating away and entering again. It is timing-dependent. We do not yet have a standalone public reproduction project or a redistributable asset.

Conceptual usage (not a standalone verified repro):

const [setRiveRef, riveRef] = useRive();
useEffect(() => {
  if (!riveRef) return;
  riveRef.setNumber('acc_head', selectedValue);
}, [riveRef, selectedValue]);

return <Rive ref={setRiveRef} url={assetUrl}
  artboardName="main_artboard" stateMachineName="main_state_machine"
  dataBinding={AutoBind(true)} autoplay style={{width: 250, height: 250}} />;

Expected behavior / question

The hook should expose a ready handle even if native loading completes before the JS listener is attached. A retained readiness result / an await-ready API, or subscription followed by a current-readiness check, could avoid relying on a transient notification. Detach and stale responses also need handling.

Is there a supported solution in the legacy runtime, or is migration to @rive-app/react-native and its awaitViewReady() path recommended?

Related: #333 (initial binding issues), #216 (onLoad API). This report specifically concerns the Android loaded event delivered before subscription sequence.

We inspected v9.8.5's source and found the same hook structure, but have not yet runtime-tested 9.8.5. We will follow up with that result separately.

主要言語
TypeScript
スター
785
フォーク
81
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

rive-app/rive-react-native のほかの issue

rive-app/rive-react-native の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。