Better representation of typed arrays in the browser console
janpaul123 opened this issue · comments
@disambiguator "Would be cool if we could clean up our monkey patching such that normal TypedArrays don't get represented as ZapTypedArrays, not sure how though. i.e."
Maybe this still works? https://stackoverflow.com/a/38652208
Or maybe we can create it not as an ES6 class but in the old prototype style so we can give it a custom name?
@disambiguator: "I dont want to try right this moment but also curious what would happen if we did.."
diff --git a/zaplib/web/zap_buffer.ts b/zaplib/web/zap_buffer.ts
index 9f5ce3f..b0a54b0 100644
--- a/zaplib/web/zap_buffer.ts
+++ b/zaplib/web/zap_buffer.ts
@@ -81,7 +81,7 @@ function zapBufferExtends(cls: any) {
super(...args);
this.__zaplibBuffer = buffer;
} else {
- super(...args);
+ cls(...args);
}
}
I did some investigation on this on Friday. A few problems:
If I do the above replacement such that our else
path just returns the original TypedArray implementation, we get errors in getZapParamType
Lines 378 to 389 in 74c0058
because the array is no longer an instanceof our overridden array type, because of this line:
zaplib/zaplib/web/zap_buffer.ts
Line 49 in de98157
doesn't seem to correctly
cls
. For example:![image](https://user-images.githubusercontent.com/2306794/156031595-6c4dc6f2-d8f5-4939-ab80-5f77311e02d1.png)
Right but that makes sense right? In that else clause it's not backed by a ZapBuffer
so it isn't a zap array any more? So maybe calls to getZapParamType
should be preceded with isZapBuffer
(aren't they already?) since that should return false in that case.
Not necessarily. getZapParamType is also used by createBuffer
/ createReadOnlyBuffer
to determine what kind of param should be created from a normal TypedArray.
Oh I see I understand now. Hm, that is strange. I wonder what happens if we use a traditional constructor, not an ES6 class. I suspect that that will work with return cls(...args)
.