Closed mririgoyen closed 6 years ago
@gaearon could i ask for one last thing? Your answer at the top makes it seem like when libs break that's on us, not react, since our code must've been buggy already. Could you please amend this? I'm going to warn users now to upgrade react and i'm going to link to this issue. The new behaviour (which im totally fine with) is definitively changing how react functions, and if any component assumes setState is going through gDSFP it's going to break in 16.3.x, and safeguarding against that will cost some major churn. A warning would be fine, but not when users come back and say "Dan Abramov said its your fault!" π
Updated to:
TLDR: if this change broke your code when you moved from 16.3 to 16.4, your code was already buggy in subtle ways. The change in React 16.4 made these bugs in your product code occur more often so you can fix them. We donβt consider making existing bugs in your code reproduce more reliably to be a breaking change.
If you're coming from an issue in some third-party library that works with 16.4, but doesn't work in 16.3 β you're hitting the React bug. This issue is a complaint about this bug getting fixed in 16.4. However, we think fixing it was the right choice. We recommend everyone to upgrade to React 16.4 or later.
I think this should be clearer?
nice, thanks! π
I'm going to lock this thread since it's super large and everyone gets notified on new comments. If somebody has further concerns please file a new issue and we'd be happy to discuss them.
According to semver, only non-breaking changes are supposed to go into minor and patch version releases. With the release of 16.4, you have made breaking changes to
getDerivedStateFromProps
. Our entire codebase, running perfectly on 16.3.2 is a dumpster fire as soon as we raise that dependency to 16.4.The only thing in your CHANGELOG about this breaking change is:
Please revert this change and save it for 17.0.0, or provide proper documentation to what this change actually entails so that its use can be adjusted by those who have already implemented
getDerivedStateFromProps
.