Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] some means to specify properties that should not be seralized - e.g. Symbol properties #52

Open
Bluebie opened this issue Dec 19, 2022 · 2 comments

Comments

@Bluebie
Copy link

Bluebie commented Dec 19, 2022

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.

@matthew-dean
Copy link

@Bluebie

Can you not set the Symbol key to not be enumerable?

@matthew-dean
Copy link

Looks like a duplicate of: #9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants