feat: unify runtime function scheduling#8
Closed
V3RON wants to merge 1 commit into
Closed
Conversation
Replace separate headless task dispatch with scheduled runtime functions. Add call/schedule APIs across JS, native bridge, Nitro, examples, and docs so awaitable and fire-and-forget work share one registration model.
riteshshukla04
added a commit
that referenced
this pull request
Jun 14, 2026
Main's new docs tree (docs/), skills/, and the rewritten README documented the headless-task API that PR #8 removes. Rewrite them to the unified model: - registerThreadedHeadlessTask(...) -> runtimeFunction.named(...) (handler now receives args directly, not a { payload, runtimeName, taskName } context). - ThreadedRuntime.runHeadlessTask(...) -> schedule(fn).on(runtimeName)(...). - Native dispatchHeadlessTask(...) -> ThreadedRuntime.schedule(...) / nativecompose::threadedruntime::schedule(...); payloadJson (single object) -> argsJson (JSON array of the function's arguments). - "headless task" concept copy -> "background work" / "scheduled runtime function"; the schedule-resolves-on-dispatch caveat now applies to schedule(). Page slugs and internal links are unchanged to avoid nav/link breakage. Verified: no removed-API symbols remain in README/docs/skills; fumadocs-mdx compiles all content with no errors. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Collaborator
|
This had conficts . I solved it here #32 |
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
2 participants
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.
Why this matters
Runtime functions and headless tasks represented the same product idea: run registered JavaScript on a named runtime without mounting UI. Keeping them as separate concepts made the API harder to teach, harder to type, and harder to mirror consistently across JS and native callers.
This PR unifies that model around runtime functions. A runtime function is now the single unit of background work, and the caller chooses whether it needs a result or only needs the work accepted/queued. That gives app authors one registration model, one Metro discovery path, one native queue, and one mental model for cross-runtime work.
New API structure
The JS API now has two primary invocation shapes:
call(...)is awaitable and returns the runtime function result.schedule(...)is fire-and-forget from the function-result perspective. Its promise resolves when native accepts or queues the work.schedule(...)is typed to accept only runtime functions whose resolved return type isvoid.callsemantics.runOn(...)for awaitable calls andscheduleOn(...)for scheduled calls.Native callers now use the same vocabulary:
C++/Objective-C++ scheduling uses:
nativecompose::threadedruntime::schedule(runtimeName, functionId, argsJson);Summary of changes
scheduleto the JS public API, native modules, Android/iOS runtime queues, C++ dispatcher, and Nitro runtime-function surface.callandscheduleon a shared per-runtime queue so dispatch order is preserved.schedule(fn).on(runtime)(...)compiles tofn.scheduleOn(runtime, ...).Verification
bunx tsc --noEmit -p example/tsconfig.json./gradlew :app:compileDebugKotlin./gradlew :react-native-runtimes_core:externalNativeBuildDebugschedule(runtimeFunction(() => 1))is rejected.bun test:harness --harnessPlatform=iosbun test:harness --harnessPlatform=android