Bump react-dom from 16.4.1 to 16.4.2 in /reactjs

[dependabot[bot]]

Bumps react-dom from 16.4.1 to 16.4.2.

Release notes

Sourced from react-dom's releases.

v16.4.2

16.4.2 (August 1, 2018)

React DOM Server

• Fix a potential XSS vulnerability when the attacker controls an attribute name (CVE-2018-6341). This fix is available in the latest [email protected], as well as in previous affected minor versions: [email protected], [email protected], [email protected], and [email protected]. (@​gaearon in #13302)

• Fix a crash in the server renderer when an attribute is called hasOwnProperty. This fix is only available in [email protected]. (@​gaearon in #13303)

Changelog

Sourced from react-dom's changelog.

16.4.2 (August 1, 2018)

React DOM Server

• Fix a potential XSS vulnerability when the attacker controls an attribute name (CVE-2018-6341). This fix is available in the latest [email protected], as well as in previous affected minor versions: [email protected], [email protected], [email protected], and [email protected]. (@​gaearon in #13302)

• Fix a crash in the server renderer when an attribute is called hasOwnProperty. This fix is only available in [email protected]. (@​gaearon in #13303)

Commits

• 54adb26 16.4.2
• d922ed2 Fix SSR crash on a hasOwnProperty attribute
• 5b19684 Sanitize unknown attribute names for SSR
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot ignore this [patch|minor|major] version will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

[canonic-epicure]

I think this point

It's a little unclear how multiple mixins ought to work

Is exactly the opposite with inheritance-based mixins (I'm strong proponent of those)

It is very clear, how multiple inheritance-based mixins combines together. And it is very unclear how they combine for copying-based mixins. Here's why:

Inheritance-based mixins, as follows from their name, just performs inheritance. This is a simple, intuitive concept, everybody understands very well. If you combine several mixins - thats just long inheritance chain, thats all. Again, the intuition, developed from the years of work with single-class inheritance answers all questions.

For copying-based mixins there's no such intuition to re-use. You need to write some specification that will define all edge cases:

• What will happen if 2 or more mixins defines the method/property with the same name? Which one will "win"? Only 1 method wins or all of them?
• In what order the constructors of mixins are called?
• If some method is defined in the mixins and in the class itself - what is the order of calls for super chain?
• What will happen if in one mixin some property is private, but in another public? etc, etc