feat(hooks): async instance creation via useViewModelInstance({ async: true })#331
Open
mfazekas wants to merge 3 commits into
Open
feat(hooks): async instance creation via useViewModelInstance({ async: true })#331mfazekas wants to merge 3 commits into
mfazekas wants to merge 3 commits into
Conversation
…: true }) Port of #304 from feat/rive-ios-experimental to main. The instance is created via the *Async runtime APIs off the JS thread; the hook returns { instance, isLoading, error } and the sync overloads are deprecated per-overload. Natives main-hop the *Async lookups (Android riveMainScope, iOS Promise.onMain) and Android's getViewModelInstance() returns a main-thread-maintained snapshot instead of traversing the controller off-thread (issue #297 race class).
The ported comments compared "the new backend" to "the legacy backend", which only reads on feat/rive-ios-experimental where both exist. Reword so a reader of this branch knows the divergent behavior lives on the experimental backend and why the hook still handles it here.
lastKnownViewModelInstance survived dispose, so a JS caller still holding the view ref got the retained, already-released instance back (first property access throws "Cannot acquire a disposed object") instead of null. Clear it on the disposing detach, and resolve null from the main-thread read once willDispose is set so a refresh posted before dispose can't re-cache a released instance afterwards.
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.
Port of #304 (merged to
feat/rive-ios-experimental) tomain.useViewModelInstance(source, { async: true })creates the instance via the*Asyncruntime APIs off the JS thread and returns{ instance, isLoading, error }. The sync overloads are deprecated per-overload (they block the JS thread via deprecated runtime APIs);async: truebecomes the default in the next major. Overload/deprecation resolution is pinned with tsd (yarn typetest, gated in the CI lint job).Native side: the
*Asynclookups now hop to the main thread (AndroidriveMainScope, iOSPromise.onMain) since the legacy runtime has no internal synchronization (the #297 race class), and Android'sgetViewModelInstance()returns a main-thread-maintained snapshot instead of traversing the controller off-thread, without blocking JS.Porting notes:
legacy/sources map onto this branch's flat layout (android/src/main,ios/); thenew/-backend and expo57 harness changes from feat(hooks): async instance creation via useViewModelInstance({ async: true }) #304 don't apply here.src/hooks/useViewModelInstance.tsand the ported example files are taken from the experimental branch (re-run through main's prettier), which also brings a small pre-feat(hooks): async instance creation via useViewModelInstance({ async: true }) #304 improvement:createInstanceByNamefailures on the sync path nowconsole.warnand resolve null instead of throwing raw native errors.RiveFileFactory.getBackend()doesn't exist here) and adds thearbtboards-models-instances.rivfixture.Behavioral notes (worth a release-note callout):
riveViewRef.getViewModelInstance()is now eventually consistent off the main thread: it returns the last main-thread snapshot and schedules a refresh, instead of the previous unsynchronized live read (the iOS Crash: Occasional crashes #297 race). One-shot readers — including the deprecated syncuseViewModelInstance(riveViewRef)— can observenullwhere the racy read happened to catch a late auto-bind; theasync: truepath polls and is unaffected.useRive().riveViewRefnow starts asundefined(view pending) instead ofnull(failed/detached), mirroring theuseRiveFileconvention, and its type widens toRiveViewRef | null | undefined.nullsource now settles to a terminal{ instance: null, isLoading: false }instead of reporting undefined/loading forever.