Skip to content

FED-3528 React 18 dual support #84

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

Open
wants to merge 40 commits into
base: master
Choose a base branch
from

Conversation

sydneyjodon-wk
Copy link
Contributor

@sydneyjodon-wk sydneyjodon-wk commented May 6, 2025

Motivation

We'll need to set up dual support for React 17 and 18 in react_testing_library (RTL).

Changes

  • Addressed the last couple bits of feedback on React 18 #81 and FED-3273 SPIKE - do not merge: React 18 dual versions #82
  • Updated tests to run on both React 17 and 18
  • Revert React 17 JS bundle back to the one from master with a couple updates to the way APIs are exported to get them to work with the dual version support
    • also added regression test for the specific issue that caught this
  • Added a CI check to verify that all JS bundle updates are checked in

Release Notes

Review

See CONTRIBUTING.md for more details on review types (+1 / QA +1 / +10) and code review process.

QA Checklist

Merge Checklist

While we perform many automated checks before auto-merging, some manual checks are needed:

  • A Frontend Frameworks Design member has reviewed these changes
  • There are no unaddressed comments - this check can be automated if reviewers use the "Request Changes" feature
  • For release PRs - Version metadata in Rosie comment is correct

aaronlademann-wf and others added 21 commits October 22, 2024 11:54
Derived from building master (3.0.2) with the following changes:

    diff --git a/js_src/rollup.config.js b/js_src/rollup.config.js
    index 38448f5..e8432dfc 100644
    --- a/js_src/rollup.config.js
    +++ b/js_src/rollup.config.js
    @@ -68 +68 @@ export default (commandFlags) => {
    -        format: 'umd',
    +        format: 'esm',
@sydneyjodon-wk sydneyjodon-wk marked this pull request as ready for review May 8, 2025 22:28
Copy link
Contributor

@greglittlefield-wf greglittlefield-wf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a couple small comments; this looks great!!


export default defineConfig({
define: {
'process.env.NODE_ENV': JSON.stringify('production'),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I never noticed this, but I would think for this package that we'd actually want this to be 'development'... Since we'd want more assertions in a test environment, right?

Wonder what rollup was doing before. Or, if it really makes much of a difference; looks like there's not a lot of checking of these at least in RTL itself: https://github.com/search?q=repo%3Atesting-library%2Freact-testing-library%20NODE_ENV&type=code

So we're probably good to just switch it?

@@ -109,6 +109,7 @@ RenderResult render(
Node? container,
Node? baseElement,
bool hydrate = false,
bool legacyRoot = true,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add legacyRoot to the doc comment?

Could go based off the site's docs: https://testing-library.com/docs/react-testing-library/api/#legacyroot

(Though reminder our default value is different from theirs)

Comment on lines 18 to 19
"@testing-library/dom": "^8.0.0",
"@testing-library/react": "^13.0.0",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#nit could we up these bounds to match what we resolved to, to help ensure we don't go backwards?

Suggested change
"@testing-library/dom": "^8.0.0",
"@testing-library/react": "^13.0.0",
"@testing-library/dom": "^8.20.1",
"@testing-library/react": "^13.4.0",

/// You can configure this behavior by passing a custom `filterNode` function that should return true for every
/// node that you wish to include in the output.
/// {@endtemplate}
external bool Function(Node)? get filterNode;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add a basic test for this option in pretty_dom_test.dart?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants