Adding support for TypedArrays - #640
Conversation
|
|
||
| functionCode += ` | ||
| if (!Array.isArray(obj)) { | ||
| if (!Array.isArray(obj) && !(obj != null && (${supportedTypedArrays.map(type => ' obj.constructor.name === \'' + type + '\' ').join('||')}) )) { |
There was a problem hiding this comment.
ugh. It would be better to put the array in a "global" scope and make an indexOf by the obj.constructor.name than this imho.
I think this will slow down array significantly.
There was a problem hiding this comment.
I am not familiar with perf implications here.
Would Array.includes also be worth testing?
ivan-tymoshenko
left a comment
There was a problem hiding this comment.
This would not work in places where we use Ajv. To test it put an array under anyOf, oneOf or if.
|
PR: MASTER: |
It seems like there is no way to solve this? |
|
Closing this PR as it has been inactive for some time and may no longer be aligned with the current state of the codebase. If the changes are still relevant, feel free to open a new PR with the necessary updates. |
I have added support for
Uint8Arraywith a test showing that it works as expected. No additional types have been created, this works by simply treating aUint8Arraylike a normalarray. Afaik, you cannot create a nested array this way so the changes are quite limited.Support for more types of
TypedArrayis easy to add but as I worked on this issue further I realised that there may be wider implications for this:TypedArrayshould be supported?Related to - #626 - I haven't verified the performance difference either, I am assuming this can only come from removing type checks?
Checklist
npm run testandnpm run benchmarkand the Code of conduct