-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add enzyme-adapter-react-17 #2564
base: master
Are you sure you want to change the base?
Conversation
UNSAFE_componentWillReceiveProps() on setContext()
lifecycle methods disabled according to test.
React.forwardRef under 17.
didn't come up with a workaround.
original PR, plus add an act() wrapper on shallow's simulate(), just to show it doesn't help.
a7a7d75
to
165d692
Compare
Codecov ReportBase: 96.31% // Head: 95.99% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #2564 +/- ##
==========================================
- Coverage 96.31% 95.99% -0.33%
==========================================
Files 49 53 +4
Lines 4207 4716 +509
Branches 1130 1279 +149
==========================================
+ Hits 4052 4527 +475
- Misses 155 189 +34
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
165d692
to
cc64090
Compare
Re your discussion point, as long as component stacks are correct within a React major/minor, there's no reason they need to stay the same as those change. |
What do you need to juggle and how would a branch help? The existing 2 are replaced by this one. If the forked component stack tests are fine, then this PR is ready to land |
Every pull request has a permanent, eternal, undeleteable ref created on Github (that's not fetched by git by default, but can be opted into), so all three PRs must point to the same commit before landing any of them, or else any outliers will remain as orphaned refs for eternity. |
Why are the other two PRs relevant here? They've been abandoned. The PR description clearly states that thus PR replaces them. How would I get CI to work without a PR? Is there any change substance to discuss or do we want to spend more time on unrelated details? If I understood you correctly you have very limited time. But even if someone gives you a green PR that's not ok because? |
@eps1lon the PR refs are part of the github repo, and no PRs are truly abandoned when a maintainer can update them directly. Either way, repo management concerns are never irrelevant/unrelated. On all my projects, I strenuously avoid having any abandoned PRs, and I repurpose every PR to ensure that all PR refs point to something useful. This PR isn't quite green - coverage is failing - but it's great that tests are passing. When I have time to review it, I will certainly do so, and I appreciate the contribution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are createClass components no longer supported in React 17?
.gitignore
Outdated
# vim | ||
**/*.swp | ||
*.swp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gitignore stuff for a specific editor belongs in your global gitignore, instead of in every repo you touch; please revert this.
CONTRIBUTING.md
Outdated
|
||
In another terminal tab execute a specific test file for faster TDD test execution: | ||
```bash | ||
node_modules/.bin/mocha packages/enzyme-test-suite/build/ReactWrapper-spec.js |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
node_modules/.bin/mocha packages/enzyme-test-suite/build/ReactWrapper-spec.js | |
npx mocha packages/enzyme-test-suite/build/ReactWrapper-spec.js |
hardcoding node_modules should always be avoided.
&& instance | ||
&& context | ||
) { | ||
if (lifecycles.componentWillReceivePropsOnShallowRerender) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you elaborate on this lifecycle option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code corrects shallow()'s calling of componentWillReceiveProps() and UNSAFE_componentWillReceiveProps() under react 17.
-- https://github.com/enzymejs/enzyme/pull/2534/files#r687066582
// React stores references to the Provider on a Consumer differently across versions. | ||
if (Consumer) { | ||
let Provider; | ||
if (Consumer._context) { | ||
({ Provider } = Consumer._context); | ||
} | ||
if (Provider) { | ||
return Provider; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In React 17+, when is Consumer._context
not set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Never. But there's a test specifically for passing something other than createContext
so these guards are required. I'll remove the outdated comment.
I'm not aware of any changes to |
I think I diffed the 16 to 17 adapter files, and saw some code related to createClass removed. In theory yes, the tests should be automatic, so if they're passing then maybe it's fine. |
} | ||
|
||
function isStateful(Component) { | ||
return Component.prototype && Component.prototype.isReactComponent; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ljharb You're probably referring to this change compared to 16 regarding create-react-class
changes?
Older versions of create-react-class
might not pass this duck-typing check but then they would also not pass the same check in React 17 itself:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for confirming :-)
@eps1lon Thanks for integrating this adapter. We are eagerly waiting for this to release, as it's a blocker for us in our project. |
@ljharb Is this something you want me to address? As far as I can tell this adapter has not less coverage than the 16 adapter. But since 16 adapter has less coverage than the average it's somewhat expected that coverage decreases. It looks to me that coverage target isn't really a target and more a check for changes (96.31% looks completely arbitrary to me). |
@eps1lon nah definitely not a requirement - just something that'd be nice to improve, if possible, until i have the time to get to the PR. Coverage targets are just minimums; the ideal is always 100% :-) |
@ljharb We're in dire need to have support for react 17 and 18 in enzyme. Is there anything we could help with to speed things up? |
43eb75e
to
39e6b1f
Compare
Stacked on #2534 (Diff against #2534)
Compared to #2534:
TODO:
Open to discussing the remaining items @ljharb
Would need to discuss if we want to normalize them across React versions. For the initial release I would lean towards being ok with different stacks between 16 and 17 since that's also what developers experience.
Closes #2429
Closes #2534
Closes #2430