Actions: Add devalue for serializing complex values

[bholmesdev]

Changes

Standardize our Actions serialization strategy. This introduces devalue to allow complex values like Dates and Sets, and adds serialization to middleware results for edge middleware support.

• Abstract serialization and deserialization (with REST response metadata) to serializeActionResult and deserializeActionResult utils
• Pass serializable values from middleware locals to ensure edge middleware works as expected
• Update frontend fetch to user deserializer

Testing

• Add integration test for Date and Set
• Update expected headers and value checks to use devalue

Docs

N/A - should continue to work as expected. The RFC did not specify supported values

[changeset-bot]

🦋 Changeset detected

Latest commit: c4130c7

The changes in this PR will be included in the next version bump.

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

[bholmesdev]

Moved the getActionResult constructor to render-context. This ensures only serializable values are sent through locals for edge middleware support. It also simplified our code in the process by removing that nextLocalsStub utility!

[Fryuni]

Would URLs be a problem due to Rich-Harris/devalue#79?

[bholmesdev]

@Fryuni Yes it would be. I recall we special case this for content collections. I'll see if we can reuse that code.

Update: added! Pretty easy to do

[bluwy]

Should we also anticipate if body is not an object? Or if the property access returns undefined?

[bholmesdev]

Yeah that's a good call. We should add a check

[bholmesdev]

Update: I just realized this was the base case when an Action error code not be parsed. I decided to simply return INTERNAL_SERVER_ERROR for that case, since that is unexpected.

[ascorbic]

I wonder if we should abstract our special devalue usage so that it's consistent across the different places we use it.

[bholmesdev]

@ascorbic By "special devalue usage," do you mean for Actions specifically or Astro in general? I tried to consolidate everything into those serialize and deserialize functions for Actions.

[ascorbic]

@bholmesdev I mean in general. We're now using it in actions, content collection schema and it will also be used in the content layer data store. Not a blocker, but it would be good to not re-implement it every time.

[bholmesdev]

@ascorbic Got it, agreed. I noticed that we're using eval / uneval for content collections and stringify / parse for actions, which is a difference. This is because content collections outputs a JS module (so eval is safe) while actions needs to serialize over the wire (so eval is unsafe).

I'd prefer to keep using eval for content collections due to this note in the devalue readme:

Use uneval when you want the most compact possible output and don't want to include any code for parsing the serialized value.

Think it's best to keep separate for now. If you can abstract for content collections v2, please do!