fix(@clayui/tooltip): add polyfill for element.matches

[bryceosterhaus]

fixes #2998

This approach seemed the most straight forward. I had looked into via MDN and stackoverflow and this was the primary way recommended.

If you have any concerns, let me know!

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit a16ff00:

Sandbox	Source
youthful-browser-u9h0e	Configuration
sleepy-breeze-5xts9	Configuration

[coveralls]

Pull Request Test Coverage Report for Build 4511

• 1 of 2 (50.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.06%) to 78.8%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
packages/clay-tooltip/src/TooltipProvider.tsx	1	2	50.0%

Totals
Change from base Build 4507:	-0.06%
Covered Lines:	2213
Relevant Lines:	2614

---

💛 - Coveralls

[bryceosterhaus]

Tested on IE11, Chrome, and Firefox. Also passes SSR for gatsby build. Going to merge for todays release and if we make adjustments if needed.

[wincent]

😢 I don't think Clay should be polyfilling anything — we shouldn't mutate global state, because we don't know if the environment we're going to be running in may provide or want to provide a polyfill of its own, and which order things will load in. In general, I think libraries are more broadly useful if they ask users to follow a BYOP (Bring Your Own Polyfill) pattern.

Instead of a polyfill:

if (typeof window !== 'undefined' && !Element.prototype.matches) {
	Element.prototype.matches =
		// @ts-ignore
		Element.prototype.msMatchesSelector ||
		Element.prototype.webkitMatchesSelector;
}

A "ponyfill" would be better:

function matches(element, selectorString) {
  if (element.matches) {
    return element.matches(selectorString);
  } else if (element.msMatchesSelector) {
    return element.msMatchesSelector(selectorString);
  } else if (element.webkitMatchesSelector) {
    return element.webkitMatchesSelector(selectorString);
  } else {
    return false;
  }
}

There is exactly one place where we use matches, so you could just define it there — for me, needing it in only one place is even more reason to avoid mutating global state.

[bryceosterhaus]

@wincent yeah you're totally right. I was thinking about it more last night after releasing and felt uneasy about it. I was concerned about mutating global state as well, but I figured that if we are already checking if it exists first, we should be relatively safe. But the caveat is that we can't dictate when this part of code is run, maybe someone mutates that state later.

I like your solution though, I can add that and release again today to help mitigate any problems from my initial change.