IE 11: Object doesn't support property or method 'isView'

[JamieMason]

Hi,
I noticed in a bug report from Sentry that /index.js#L67 throws Object doesn't support property or method 'isView' in IE 11.

Broadly speaking, I think the fix would be to check for ArrayBuffer.isView before invoking it:

- if (hasArrayBuffer && ArrayBuffer.isView(a) && ArrayBuffer.isView(b)) {
+ if (hasArrayBuffer && ArrayBuffer.isView && ArrayBuffer.isView(a) && ArrayBuffer.isView(b)) {

I'm happy to submit a PR if you agree to this change.

Thanks.

[chrisbolin]

ugh IE again lol.

i'd welcome a PR! let's actually change the line var hasArrayBuffer = typeof ArrayBuffer === 'function'; and add a check for isView. It'd be nice to comment to note the IE fix. One of the goals of this package is to be very small, so try and think thru the minimal way to safely create hasArrayBuffer

[kitten]

Hm that’s odd... MDN flags ArrayBuffer.isView as supported on IE11 🙃 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer/isView

[JamieMason]

what would be the most appropriate file to put a test in for this? test/browser/browser.spec.js, one of test/node/*.spec.js, or create a new file for testing host environment conditions?

[chrisbolin]

@JamieMason this is still an issue with IE11 right? i'll keep it open if it is

[JamieMason]

Hi @chrisbolin, this is still present yes – have reopened.

[JamieMason]

On ArrayBuffer.isView being supported in IE11 – another theory might be a bad Polyfill somewhere in the Stack, or one released in the period between ArrayBuffer and ArrayBuffer.isView being adopted – I don't know. The environment is outside of our control but we can take small measures to defend ourselves against it.

EDIT:

1. I have a proposed fix here you can see, I can raise a PR and let me know about IE 11: Object doesn't support property or method 'isView' #66 (comment) if you want tests: https://github.com/FormidableLabs/react-fast-compare/compare/master...JamieMason:issue/66?expand=1

2. Totally off-topic, but I played around with some optimisations in this branch https://github.com/JamieMason/react-fast-compare/pull/new/optimisations and measured consistent improvements, it spoils the boundary you've been trying to maintain via comments between this and your upstream library though, but it's there incase you're interested in the ideas.

   Benchmarks

   MASTER BRANCH
   
   --- speed tests: generic usage ---
   
   react-fast-compare x 167,026 ops/sec ±3.17% (86 runs sampled)
   react-fast-compare x 170,456 ops/sec ±1.92% (89 runs sampled)
   react-fast-compare x 165,394 ops/sec ±2.68% (90 runs sampled)
   
   --- speed tests: generic and react ---
   
   react-fast-compare x 79,449 ops/sec ±3.06% (86 runs sampled)
   react-fast-compare x 80,047 ops/sec ±4.81% (89 runs sampled)
   react-fast-compare x 86,828 ops/sec ±0.91% (93 runs sampled)
   
   OPTIMISATIONS BRANCH (commit 65ca248)
   
   --- speed tests: generic usage ---
   
   react-fast-compare x 182,872 ops/sec ±0.95% (94 runs sampled)
   react-fast-compare x 178,770 ops/sec ±0.95% (90 runs sampled)
   react-fast-compare x 172,519 ops/sec ±2.54% (89 runs sampled)
   
   --- speed tests: generic and react ---
   
   react-fast-compare x 85,501 ops/sec ±3.29% (87 runs sampled)
   react-fast-compare x 87,158 ops/sec ±2.29% (89 runs sampled)
   react-fast-compare x 91,644 ops/sec ±0.60% (92 runs sampled)
   
   OPTIMISATIONS BRANCH (commit 1f878f3)
   
   --- speed tests: generic usage ---
   
   react-fast-compare x 179,164 ops/sec ±1.41% (87 runs sampled)
   react-fast-compare x 175,094 ops/sec ±2.73% (86 runs sampled)
   react-fast-compare x 171,544 ops/sec ±2.81% (83 runs sampled)
   
   --- speed tests: generic and react ---
   
   react-fast-compare x 91,610 ops/sec ±0.69% (92 runs sampled)
   react-fast-compare x 90,979 ops/sec ±0.50% (94 runs sampled)
   react-fast-compare x 85,835 ops/sec ±3.34% (89 runs sampled)
   
   

[ryan-roemer]

@JamieMason -- Is there perhaps a simple reproduction (no minification, etc.) you can host online / in a public repository that we can then open in an ie11 VM and confirm?

[JamieMason]

A reduced test case can be helpful to isolate a problem when there's a lot of noise and can be a really good idea, but could you help me understand why one would be needed in this case @ryan-roemer? Let me explain my thinking – the only variable I can think of is whether IE11 supports ArrayBuffer.isView or not, and our VM could assert that via its Developer Console.

We can also see how this library would behave under the condition that ArrayBuffer is present but ArrayBuffer.isView is not by reading the source.

So I think the only question left is whether we feel that, on balance, it's worth doing. It makes an uncaught exception impossible, but in old and dying browsers, and adds code that now has to be maintained.

[ryan-roemer]

So, when I do just that test in IE11 vm via https://www.browserling.com/ it's all there:

[ryan-roemer]

So I think if we think the behavior you're seeing is a bug in react-fast-compare, I'd love to see a failing test case that uses react-fast-compare and throws on ie11...

[JamieMason]

I'm totally happy to close it Ryan

[chrisbolin]

it makes sense that it's tough to repro, as the original error came from Sentry—so not even a machine you controlled

[JamieMason]

So whether it happens in specifically IE11 is a Red Herring, whether it does or doesn't we still know that Browsers exist with this level of intermediate support and, just like IE 11, they're way out on the fringes.

the only question left is whether we feel that, on balance, it's worth doing. It makes an uncaught exception impossible, but in old and dying browsers, and adds code that now has to be maintained.

It's such low priority you could live with it and be fine and I honestly don't mind either way whether you implement a fix or not, I'm not invested and have no reason to sell you it – I saw the error in Sentry and thought it helpful to bring it to your attention.

I think you have all the information you need so I'll end my involvement here. Thanks for your time and for this great Project 👏