New Actions type is overly restrictive

[moatra]

Describe the problem

I took a stab at upgrading to SvelteKit post #5748. There's a fundamental regression of capability with the Action type compared to how POST page endpoints worked previously. Before 5748 landed, the returned body of the POST handler would be layered on top of the body of the GET handler. This allowed the POST handler to influence the rendering of the page component by providing additional data.

The Action type allows something similar by returning the error value, but it's limited to the Record<string, string> type which doesn't allow passing complex data back to the page component.

Describe the proposed solution

I'd suggest replacing error with form_result (action_result?) and loosening the type from Record<string, string> to something like Record<string, any> or the old JsonValue.

Alternatives considered

Alternative 1: Serialized JSON Hack

Theoretically you could pass serialized json as one of the string values in error: Record<string, string> but that obviously feels like a hack counter to the spirit of what error is supposed to represent.

Alternative 2: External Data Passing

The developer can externally store the complex data somewhere and manually look it up the next time the page's load function is invoked. (Think cookies or memory store). This external storage method adds complexity to the form handling process.

Importance

would make my life easier

Additional Information

This "pass data from the POST handler to the page component" functionality is important for how I've implemented the "form-local actions" I described in #5875 (comment)

[moatra]

This is meant as a short-term fix until whenever the result of #5875 lands. Ideally that solution also accommodates this use case.

[dummdidumm]

The types are relaxed. I'm having a hard time figuring out if this is two issues in one. Could you clarify if the things you mentioned are solved?

[moatra]

The main issue (regression in capability) is fixed.

I'm guessing you're looking at the s/error/form_result as the possible second issue. It's definitely not a blocker and not something I'd push for changing right now, especially considering 5875 is coming down the pipe. My thinking there is that since the Action type allows for setting the status (including possibly a 2xx code), error is not the semantically correct name - after all a 2xx status does not imply an error.

If that's a change the maintainers are interested in pursuing, I'd be happy to open another issue for tracking. Otherwise I can work with a 2xx returning an error as long as I can pass complex data types through

[dummdidumm]

Thanks for the answer, closing then. After the form discussion proposal is finalized and implemented, you can revisit this and open an issue if you like.