Use devalue for island props serialization

[bluwy]

Changes

fixes #12088
partially revives #8004

compared to #8004, this uses devalue instead of seroval as I don't really understand the main difference with seroval, and we're already using devalue in our codebase. It also doesn't completely serialize other island information, only the props, to minimize the change surface area.

Testing

added test for #12088 and removed some irrelevant ones

Using the repro in #7978, this reduces the serialized prop value size ("Astro bytes"):

Before (4.15.9)	After (this PR, v5)

It could get even lower by serializing string values with single quotes to prevent needing escaping, but I think for now it's fine as a stop gap.

Docs

It doesn't look like we document specific serialization edge cases other than https://docs.astro.build/en/guides/framework-components/#passing-props-to-framework-components, which is still true today (regarding function serialization)

[changeset-bot]

🦋 Changeset detected

Latest commit: 1759606

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

[github-actions]

This PR is blocked because it contains a minor changeset. A reviewer will merge this at the next release if approved.

[natemoo-re]

This looks great, thanks for reviving my efforts! 🎉

For context, seroval is used by Solid and has more comprehensive support for common cross-environment primitives. The other benefit is that we wouldn't need to generate the (0, eval)() step, because seroval outputs self-contained JS strings.

Of course, devalue is also a great choice—I'll leave the final call up to you.

[bluwy]

For context, seroval is used by Solid and has more comprehensive support for common cross-environment primitives.

I did some checks and I think they're largely the same. devalue can handle typed arrays, holey arrays, and other edge cases well. Except Error objects but I think that's fine and not something users usually do.

The other benefit is that we wouldn't need to generate the (0, eval)() step, because seroval outputs self-contained JS strings.

I think both devalue and seroval outputs similar JS that still requires us to eval. We're putting the values in attribute values, so we have to manually eval it again.

devalue also seem to be much smaller, which reduces the ssr bundle size. Comparison: devalue (5.21 kB -> 2.16 kB (gzip)) and seroval (28.2 kB -> 7.75 kB (gzip))

[ascorbic]

This is great. Makes a lot of sense that this matches the supported types for content layer too.

[matthewp]

I don't think we should introduce eval. Currently users are required to use unsafe-inline if they are using a CSP policy, this change would require that they also use unsafe-eval. Given the number of people who are not satisfied with an unsafe- at all, we should be moving in the direction of not requiring it, and I don't see how we can make CSP work with eval in the code.

[ascorbic]

This could use devalue.parse and devalue.stringify instead of eval.

[matthewp]

@ascorbic how much client JS are we adding by bringing devalue in? The reason we went with a custom thing is because the file sizes of these tools seemed like too much. Also remember that it gets inlined into the page, you really don't want a several kilobytes dependency to be inlined like that, it's a waste.

Also consider here that the only thing we gain by bringing in a dependency is not needing to maintain our custom serializer/deserializer. But we haven't had much maintenance on the one we have. This Infinity thing is the last time we've gotten a request for a new type in probably a couple of years. Adding more kB to everyone's pages to avoid occasionally updating a small amount of custom code doesn't seem like a very good tradeoff to me.

@natemoo-re did a spike a while back (last year IIRC) on going back to inlining the hydration script rather than using astro-island. If we did that we could use these sorts of tools again because there would be no client-side penalty for deserialization. I think that's probably what we should do instead of this. And for now, just add Infinity as a new type in our custom serializer.

[natemoo-re]

@matthewp supporting Infinity in the custom logic seems like a reasonable conclusion to me! NWTWWHB.

As Astro pushes into more ecomm/interactive usecases, the potential payoff on serialization optimizations will continue to grow. Could pair nicely with any cross-island communication explorations, if that's ever on the table.

[bluwy]

going back to inlining the hydration script rather than using astro-island. If we did that we could use these sorts of tools again because there would be no client-side penalty for deserialization. I think that's probably what we should do instead of this.

We can't do that because that will require unsafe-inline again.

how much client JS are we adding by bringing devalue in?

devalue stringify is 971B gzip. Our custom implementation is 283B gzip.

---

Looks like there's no other way to implement this without size tradeoffs. I do still think the edgecases being handled by devalue is valuable but maybe in the future.