Closed aleclarson closed 5 months ago
Now that I better understand the internals, I'd say that #781 is enough to close this issue out, since all I wanted was the full JSON path to be attached to nested Encode/Decode errors.
@aleclarson Hey, Let me give this some thought on how best to proceed here.
I do like this idea (especially for debugging), but it's going to take some refactoring to propagate the navigable path through the current Encode/Decode transform logic. Currently the best example of how TB achieves this is via the Errors
logic, so will likely want to replicate a similar pattern for Transforms. This will also need some tests written.
I think between this and the other PR's submitted for Transforms, an additional general review of the way TypeBox currently handles Transform error handling might be good (I'm very much open to ways to improve things there). I think mostly, getting some concrete use cases (code examples) might be a good way to communicate where things could improve. In the mean time, I've left some fairly detailed notes on the PR's you've submitted (these will need a follow up review from you), Will spend some time reviewing follow ups a bit later on this week.
Also hey, thanks for submitting these PR's. It's great to get some visibility on the current TB Transform logic (as these have been quite difficult to get right). All community inputs to help improve this aspect of TB are very much appreciated :)
Will pick things up later this week. Cheers! S
When using
Transform(…).Decode(…).Encode(…)
, it would be great if JSON paths were forwarded through to theDecode/Encode
callbacks. Then I would be able to thread the JSON path through to any nestedValue.Encode/Decode
calls.Here's an example of what I'm doing:
These types are being used for JS<->SQLite marshalling.
The Problem
When a nested encode/decode fails, the error doesn't have the full JSON path in it, making it hard to debug.