feat(hooks): async useViewModelInstanceAsync (deprecate sync hook)#304
Draft
mfazekas wants to merge 5 commits into
Draft
feat(hooks): async useViewModelInstanceAsync (deprecate sync hook)#304mfazekas wants to merge 5 commits into
mfazekas wants to merge 5 commits into
Conversation
This was referenced Jul 1, 2026
The sync useViewModelInstance creates instances via deprecated runtime
APIs that touch the Rive runtime on the JS thread. Add
useViewModelInstanceAsync built on the non-deprecated `*Async` APIs,
returning a { instance, isLoading, error } discriminated union (mirroring
useRiveFile), with cancellation/disposal on deps change + unmount and
onInit applied before the instance is exposed.
Keeps `required` parity (throws once resolved to null; undefined while
loading). The sync hook is marked @deprecated but left working for
backward compatibility. Migrates the example screens to the async hook.
…ty, not just the view ref
On the experimental iOS backend the ViewModel instance and its properties
resolve asynchronously a short time after the view's hybridRef is assigned.
The test read `getViewModelInstance().numberProperty('ypos')` immediately
after waiting only for the ref, so on slower CI runners the property was
occasionally still undefined, failing at `expect(ypos1).toBeDefined()`
(~1 in 4 runs). Reproduced deterministically: at ref-callback time the VMI
is null 40/40, becoming ready shortly after.
Poll with waitFor until the `ypos` property is available before sampling it,
for both the initial mount and the post-switch reconfigure.
mfazekas
force-pushed
the
feat/use-viewmodel-instance-async
branch
from
fbcdf51 to
53b4aa0
Compare
…aphs The iOS harness suite OOMs the Metro dev-server node process on runs with many test files. Each test file is fetched as its own Metro bundle entry (`<file>.bundle?modulesOnly=true`), and Metro's IncrementalBundler caches one full dependency graph per distinct entry (for delta updates), freeing it only on server shutdown. The per-file flow never uses those deltas, so each file leaves a ~tens-of-MB graph behind → linear growth → JS heap OOM. Patch @react-native-harness/runtime (via yarn patch) to send an HTTP DELETE to the same bundle URL after each file finishes; Metro routes DELETE to IncrementalBundler.endGraph, releasing that file's graph and both revision-cache entries. Reusing the exact fetch URL guarantees the graph id matches (verified in Metro 0.82.5). Best-effort: a failed release only costs memory. Upstream: callstackincubator/react-native-harness#144 / #145.
…odel property Same race as 53b4aa0 (reconfigure test): the default ViewModel instance and its properties resolve asynchronously a short time after the view's hybridRef is assigned. The test read getViewModelInstance().numberProperty('ypos') right after waiting only for the ref, so the VMI was intermittently still undefined — `expect(vmi).not.toBeNull()` passed (undefined !== null) and the next line threw "Cannot read property 'numberProperty' of undefined". Poll with waitFor until the ypos property is available before sampling it.
The iOS harness job fails when the app crashes at launch (bridge never connects, 15-min timeout), but the existing debug step only dumps os_log — which comes back empty for an early-launch crash. Add a step that collects RiveExample crash reports (.ips/.crash) from the host and simulator DiagnosticReports dirs, prints them to the log, and uploads them as an artifact, so the actual crash stack is visible instead of an empty log.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds
useViewModelInstanceAsync, an async replacement foruseViewModelInstancebuilt on the non-deprecated*Asyncruntime APIs (viewModelByNameAsync,defaultArtboardViewModelAsync,createInstanceByNameAsync,createDefaultInstanceAsync,createBlankInstanceAsync). The sync hook creates instances via@deprecatedAPIs that access the Rive runtime on the JS thread; the async variant resolves off-thread.Why
Drops the deprecated sync creation path (the hook currently ships with
eslint-disable @typescript-eslint/no-deprecatedand a migration TODO), and avoids JS-thread runtime access — the same class of off-thread access behind the #297 data-binding races.API
Returns a
{ instance, isLoading, error }discriminated union mirroringuseRiveFile. Same overloads/params as the sync hook, includingrequired(throws once resolved tonull;undefinedwhile loading). Lifecycle usesuseState/useEffectwith a cancellation flag andcallDisposeon deps-change/unmount;onInitruns before the instance is exposed.Backward compatible: the sync
useViewModelInstanceis marked@deprecatedbut kept working. Example screens migrated to the async hook (dataBind={instance}unchanged).Verify
yarn tsc,yarn lint(0 errors),yarn jest(65 passed incl. 16 new async tests)useViewModelInstancehook suites pass; 9 unrelated pre-existing native failures (RiveLogger not registered,setValueAsyncnot implemented) are tracked separately.