You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the SvelteKit use case, it's annoying that sometimes my server side data models contain data that should not be sent to the client (like private keys or passwords as strings) but are conceptually related to the object (e.g. user profile). I was surprised when SvelteKit errored out instead of silently ignoring Symbol keys in objects during serializing of a server load event.
I'd like to see devalue support some means of having a property omitted from devalue serialization. Quietly skipping over Symbol keys in objects seems reasonable, because it would match the behaviour of JSON.serialize, and there is inherantly nothing useful you can do to serialize a Symbol in the future, short of having some kind of laboriously maintained symbol registry on both sides, so there's little value in trying to reserve the space for future functionality.
WeakMaps are a feasible work around, but it's messy and requires a lot of care in data models to handle it well. Symbol keys seem idiomatic and popular in other projects as a way of kind of hiding properties in objects, almost akin to private fields in OOP. I think in the context of an object property the intent to conceal is fairly clear.
The text was updated successfully, but these errors were encountered:
In the SvelteKit use case, it's annoying that sometimes my server side data models contain data that should not be sent to the client (like private keys or passwords as strings) but are conceptually related to the object (e.g. user profile). I was surprised when SvelteKit errored out instead of silently ignoring Symbol keys in objects during serializing of a server load event.
I'd like to see devalue support some means of having a property omitted from devalue serialization. Quietly skipping over Symbol keys in objects seems reasonable, because it would match the behaviour of
JSON.serialize
, and there is inherantly nothing useful you can do to serialize a Symbol in the future, short of having some kind of laboriously maintained symbol registry on both sides, so there's little value in trying to reserve the space for future functionality.WeakMaps are a feasible work around, but it's messy and requires a lot of care in data models to handle it well. Symbol keys seem idiomatic and popular in other projects as a way of kind of hiding properties in objects, almost akin to private fields in OOP. I think in the context of an object property the intent to conceal is fairly clear.
The text was updated successfully, but these errors were encountered: