chore: error during development when using use:enhance with +server - #13197
Conversation
🦋 Changeset detectedLatest commit: 9400deb The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
If I may, I do think this will leave SvelteKit at a significant disadvantage compared to other frameworks like Remix, which support this use case. (This is particularly/especially true when it comes to things related to auth -- which is a core need in many web applications.) Would it be possible for Would SvelteKit be able to do something similar? If not, would SvelteKit at least be able to add documentation on how to enhance Footnotes
|
If we do decide to support non-SvelteKit actions, this error should still be helpful in the meantime (until support is added). |
That's fair. If the Svelte team decides that it's worth pursuing this at some point (even if it's in the more-distant future), could #10855 be unlinked from this PR? (I understand that the team may not have made a decision on this yet.) |
dummdidumm
left a comment
There was a problem hiding this comment.
let's go with this but keep the issue open
|
If this works as I understand it, I do think this warning has to be reverted. It's a common pattern in Superforms to use an endpoint with a form that's in the layout (like a login form displayed on every page). It's used in numerous projects already and works very well, with the helper function for returning an ActionResult from an endpoint: https://superforms.rocks/api#actionresulttype-data-options--status |
|
Now I see that it's not a warning but an exception, I'm quite sure it must be reverted, as it is a breaking change for many sites. I've already had the first report on Discord about it. The recommendation for now is to stay on 2.15.3. |
|
@ciscoheat sorry for the late response, I just got back from a holiday. I've created #13397 to revert the change |
This PR reverts #13197 since it cause an error for users that used SuperForm's helper that made +server responses compatible with use:enhance.
…non-ActionResult error response (#16308) closes #15737 Submitting a `use:enhance` form that trips the CSRF origin check does nothing visible. The 403 response is right there in the network tab: ```json { "message": "Cross-site POST form submissions are forbidden" } ``` but it has no `type`, so it isn't an ActionResult and every branch in the submit handler and `applyAction` skips it. Non-JSON responses already become `{ type: 'error' }` through the catch around `deserialize`, so JSON that isn't an ActionResult was the one shape that failed silently. Error responses without a recognized `type` now throw into that same catch and render the nearest `+error.svelte`. A body shaped like an `App.Error` becomes `page.error` as-is, the way an `error(403, { message })` body does. Anything else goes through `handleError`, which #16162 routed this catch through, so the hook keeps seeing these failures and `page.error` keeps its declared shape. 2xx responses are untouched. PatrickG suggested rendering the error page in the issue. teemingc flagged the same gap in #10464 with a server-side shape fix in mind; doing it on the client also covers proxy and middleware responses that kit's server never shaped. #10855 reports the same class of unhelpful failure for non-action endpoints; the non-2xx half of it is covered here. Responses that do parse as an ActionResult pass through regardless of status, which keeps the pattern that prompted the #13197 revert (#13397) working. The docs line that revert added says posting to a `+server.js` endpoint results in an error; with this change that error surfaces instead of failing silently. The test mimics the CSRF response with an endpoint, since the real check can't fire same-origin in Playwright. It fails on `version-3` and passes with this change, in dev and build. The hook suffix in two of the assertions is `handleError` running. --- ### Please don't delete this checklist! Before submitting the PR, please make sure you do the following: - [x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs - [x] This message body should clearly illustrate what problems it solves. - [x] Ideally, include a test that fails without this PR but passes with it. ### Tests - [x] Run the tests with `pnpm test` and lint the project with `pnpm lint` and `pnpm check` ### Changesets - [x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running `pnpm changeset` and following the prompts. Changesets that add features should be `minor` and those that fix bugs should be `patch`. Please prefix changeset messages with `feat:`, `fix:`, or `chore:`. ### Edits - [x] Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed. --------- Co-authored-by: Nic Polumeyv <nicolas.polum@gmail.com> Co-authored-by: Rich Harris <rich.harris@vercel.com>
Related to #10855 (If we have no plans to extend
use:enhanceto work with non-SvelteKit form actions then this closes that issue entirely).This PR adds an dev-only error if someone uses an enhanced form and POSTs to an internal API handler. It makes it more obvious they shouldn't be used together compared to "Unexpected end of JSON input" when it fails to parse a response body.
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm testand lint the project withpnpm lintandpnpm checkChangesets
pnpm changesetand following the prompts. Changesets that add features should beminorand those that fix bugs should bepatch. Please prefix changeset messages withfeat:,fix:, orchore:.Edits