React-dates: Error in IE11: "Object.getOwnPropertyNames: argument is not an object"

[stilian9205]

When I include the component in my project I am setting it up with the basic props, nothing fancy, everything works fine in Chrome, but in IE11 I get an error "Object.getOwnPropertyNames: argument is not an Object", I saw the other threads about including airbnb-shrims I tried that as well but nothing seems to work, when I click on the calendar input it just flashes and nothing happens the calendar is not opening and it throws that error.

<DateRangePicker
  startDate={props.startDateFilter} // momentPropTypes.momentObj or null,
  startDateId={'startDate'}
  startDatePlaceholderText={'From: '}
  endDate={props.endDateFilter} // momentPropTypes.momentObj or null,
  endDateId={'endDate'}
  endDatePlaceholderText={'To: '}
  displayFormat="DD/MM/YYYY"
  onDatesChange={props.onDatesChange} // PropTypes.func.isRequired,
  focusedInput={props.calendarFocused} // PropTypes.oneOf([START_DATE, END_DATE]) or null,
  onFocusChange={props.onFocusChange} // PropTypes.func.isRequired,
  numberOfMonths={1}
/>

[ljharb]

So you’re including airbnb-browser-shims, before all other code; you’re not using other shims like babel-polyfill/core-js; and you’re getting that error? What’s the stack trace? Can you make a repro case in a codepen or jsfiddle?

[stilian9205]

Actually I am using babel, I am importing the shims in the component it self. Is my approach wrong ?

[ljharb]

Yes. The shims need to be imported in your entry point, before all other code runs, especially react and moment.

[shivam0212]

@ljharb I've added both 'airbnb-js-shims' and 'airbnb-browser-shims' in the index file but the issue is still there. Does it work on any specific version?

[ljharb]

(browser-shims import js-shims already)

You shouldn’t be using babel-polyfill at the same time as airbnb-browser-shims; one or the other would be sufficient.

[slorber]

Hey @ljharb

I'm facing this issue on a Gatsby site where I already use polyfill.io, so I'm actually not using your shims. I guess it makes sense because this lib is used in only a single page so I'd rather handle the polyfills in a generic way for all my pages, using the polyfill service.

I've tried many polyfill.io setups, trying to use the same polyfills as you have in your airbnb polyfills, but the page containing react-dates always crash (all others work fine).

My last attempt was with these polyfill.io settings:
https://cdn.polyfill.io/v3/polyfill.js?features=default,es2015,es2016,es2017,es2018,Symbol,fetch,IntersectionObserver,IntersectionObserverEntry,ResizeObserver,Intl,requestIdleCallback,Symbol.prototype.description

I get the following crash:

Any idea what I could be doing wrong here?

[ljharb]

@slorber In my experience, polyfill.io often has broken shims, so at the risk of being snarky, “using polyfill.io”.

If you could try with core-js or airbnb-browser-shims, and it works with either (presumably both), then this should be closed in favor of an issue filed on polyfill.io.

[slorber]

Thanks for your feedback @ljharb I'll try alternative way to load polyfills then.

Just wondering, why do you prefer to load polyfills with core-js instead of polyfill.io? Don't you think it's interesting to reduce the bundle size? Or do you simply not use it because you think the tool is not enough reliable or something (like on the current case)? I mean, if no shim was broken on polyfill.io, wouldn't you use it? and why not?

[ljharb]

Polyfills must run at runtime in order to determine if they are needed; that means they have to load more or less unconditionally. (Additionally, polyfill.io has a policy of “good enough” that means that many of their shims are not actually spec compliant, they just cover the majority use cases)

The approach attempted by polyfill.io requires a lot of server infrastructure to do properly, and a lot of experimentation to continuously revalidate assumptions about the client. I’m skeptical it can be done in a generic fashion, without deep knowledge of the specific app’s code.

(note, i prefer the es shims over core-js for other reasons, but both are the same category of correct: unconditionally locally loaded shims/polyfills)

[slorber]

thanks, didn't know about the "good enough" tradeoff, maybe that's the reason of my problems here

[ljharb]

The original question has been answered; as have some new related ones.

[slorber]

So actually, my Gatsby site already uses core-js v2, and some polyfills might have conflicted with my polyfill.io setting. I'm now using polyfill.io only for polyfills outside of core-js scope (like IntersectionObserver, Intl etc...) and it seems to work better now ;) Thanks

[JakeChampion]

(Additionally, polyfill.io has a policy of “good enough” that means that many of their shims are not actually spec compliant, they just cover the majority use cases)

That was true about 3 years ago, I've since taken the project over and have rewritten all the polyfills to follow the ECMAScript-262 specification as closely as I could, much like es-shim polyfills does by doing each step in the order defined in the specification. Many of the ECMA-262 abstract functions/methods are implemented and that is what the polyfills use.

With regards to polyfills for feature which are not ECMA-262, such as WHATWG fetch and IntersctionObserver, those are harder to make 100% spec compliant as the underlying browser features those require are not all exposed to userland.

[ljharb]

@JakeChampion thats very good to hear, i was unaware of a shift. is there a reason to reinvent your own instead of using existing correct solutions?

[JakeChampion]

@ljharb the reason for implementing them ourselves is because polyfill.io bundling solution does not support CommonJS or ECMAScript Modules unfortunately, which are the formats that all the other solutions are written in.

I'm hoping to implement CommonJS and ECMAScript Module support some time next year.

[ljharb]

Gotcha, looking forward to fewer sources of truth in the ecosystem for language polyfills :-)