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
Coming from PureScript, I don't expect encoding a value as JSON to fail.
Suggested Solution
It seems to me rather than trying to encode any JS value as JSON, most use cases (and I could be wrong here) will be trying to encode a value that extends Json.Json. If that's the case, stringify could pretty safely be implemented as:
Of course I could be overlooking an obvious reason that the current implementation makes more sense. But if the current implementation is necessary for some cases, while the implementation suggested here would work for most, then I think it's worth providing both.
Who does this impact? Who is this for?
Maybe just me but I assume this would benefit all users as they could avoid having to deal with failure when encoding JSON.
Your environment
Software
Version(s)
fp-ts
2.16.1
TypeScript
5.1.6
The text was updated successfully, but these errors were encountered:
JSON.stringify throws a TypeError when the value contains a circular reference or a BigInt.
BigInt doesn't extend Json though. And while I'm still learning TS, I can't figure out how to construct a self-referencing Json type without using any then casting it to Json with stringify(notJson as Json), which if you're doing, then you should expect type-errors anyway.
So without deliberately circumventing the compiler, you shouldn't be able to call the stringify function I suggested with either.
🚀 Feature request
Current Behavior
Json.stringify
is currently defined as:fp-ts/src/Json.ts
Line 60 in 01b8661
Desired Behavior
Coming from PureScript, I don't expect encoding a value as JSON to fail.
Suggested Solution
It seems to me rather than trying to encode any JS value as JSON, most use cases (and I could be wrong here) will be trying to encode a value that extends
Json.Json
. If that's the case,stringify
could pretty safely be implemented as:Of course I could be overlooking an obvious reason that the current implementation makes more sense. But if the current implementation is necessary for some cases, while the implementation suggested here would work for most, then I think it's worth providing both.
Who does this impact? Who is this for?
Maybe just me but I assume this would benefit all users as they could avoid having to deal with failure when encoding JSON.
Your environment
The text was updated successfully, but these errors were encountered: