feat(core): forward params to named onSuccess/onError actions - #307
Merged
Conversation
Named actions in onSuccess/onError only received their name, so params never reached the handler. Forward the whole binding through the core executor and every renderer bridge so a named handler receives params the same way top-level bindings do. Closes #301
Contributor
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
ActionOnErrorSchema omitted the optional params field, so onError action params were silently stripped during Zod validation even though the type allowed them. Mirror the onSuccess form and add schema-level tests for both.
The Svelte ActionProvider bridge rebuilt the sub-binding from the name only, dropping params, same gap as the other renderers. Its component script block is type-checked more loosely, so it passed CI while wrong. Forward the whole binding and add integration tests that named onSuccess and onError handlers each receive their params.
Core always passes the resolved binding to the executeAction context callback, so the string half of the union was false back-compat. Drop it to (binding: ActionBinding): the runtime change becomes a compile error for anyone with a custom renderer bridge instead of a silent break, and every bridge collapses to execute(binding).
ctate
approved these changes
Jul 8, 2026
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.
onSuccessandonErrorcan run a registered handler by name via{ action: "<name>" }, but only the name was forwarded, soparamsnever reached the handler. A chainedonSuccess: { action: "toast", params: { message } }silently fell back to the handler's defaults, even though top-level bindings already resolveparams. This closes that gap.Params were dropped in three places, now all fixed:
paramsfrom the{ action }form during validation, on bothActionOnSuccessSchemaandActionOnErrorSchema{ action: name }from that name (react, solid, vue, react-native, react-pdf, react-email, ink, svelte)The fix forwards the whole binding:
paramsis added to the{ action }form in both schemas and their hand-written types, and the executor passesaction.onSuccess/action.onError.The
executeActioncontext callback is now typed(binding: ActionBinding)instead of(name: string). Core always passes the resolved binding, so this makes the contract honest and lets every renderer bridge collapse toexecute(binding). This is a breaking change for anyone implementing a custom renderer bridge that expected a bare string, now surfaced at compile time rather than silently at runtime.navigateandsethandlers are unaffected.Tests: core unit tests cover the executor and both schemas; react and svelte integration tests render a real component, fire the event, and assert the named onSuccess and onError handlers receive their
params. Each was verified to fail without the fix.Closes #301