Allow replacing JSON.stringify
- Dominant language
- JavaScript
- Stars
- 14.8k
- Forks
- 1.4k
- Avg merge
- 22d 3h
- Merged PRs (30d)
- 1
Description
#### Support plan
* *is this issue currently blocking your project?* (yes/no): No
* *is this issue affecting a production system?* (yes/no): Yes
#### Context
* *node version*: 18.16.0
* *module version*: 21.3.2
* *environment* (e.g. node, browser, native): Node
* *used with* (e.g. hapi application, another framework, standalone, ...): Hapi application
* *any other relevant information*:
#### What problem are you trying to solve?
In performance tests, we've found that calling JSON.stringify on large responses is a significant bottleneck. We're experimenting with alternatives such as [fast-json-stringify](https://www.npmjs.com/package/fast-json-stringify).
#### Do you have a new or modified API suggestion to solve the problem?
I saw in https://github.com/hapijs/hapi/pull/3014 that there was a brief discussion about using an alternative to JSON.stringify. I completely understand the desire expressed there to not add dependencies to the Hapi core, but it like there could be some value in adding an option to use a function other than JSON.stringify, so that users can use alternatives themselves if they want.
Suggested API: Add `route.options.stringify` or `route.options.jsonStringify`, as a function that takes an arbitrary object and returns a string. If this option is present, and if a response is a normal (i.e., success, not Boom) response of `'plain'` type (such that it would normally go through JSON.stringify), then it's invoked instead of JSON.stringify, and [`route.options.json`](https://hapi.dev/api/?v=21.3.2#-routeoptionsjson) is ignored.
(Ignoring this new option for Boom error responses simplifies usage with alternatives like fast-json-stringify, which expect to know the schema of the object(s) they're used with.)
Contributor guide
Assessment
This issue has not been assessed yet.