-
Notifications
You must be signed in to change notification settings - Fork 47.1k
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 fixture components #8860
Add fixture components #8860
Conversation
<ol> | ||
{children} | ||
</ol> | ||
</div> |
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.
Right now the fixtures can be tested with (almost) every version of React published. If we use functional components then it will break with versions <14
.
It's probably safest to just use class components everywhere, but we can discuss limiting which versions we really need to support (probably not many)
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.
Ya. I went with createClass for backward compatibility reasons, but that might cause forward compatibility issues I'm the future.
How far back do we want to support?
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.
I didn't think about function components. but the farthest back version in the select is 0.13 which should be fine for plain class components
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.
I think we're fine with only offering fixture tests for 0.13+, so we should probably convert all fixture components to use ES6 classes.
speaking of versions, does it make sense to add something like "fixed in version:" and known exceptions to the test case components. We probably want to document some sort of minimum version the test case should work in, to avoid regressions, or false positives for a regression |
<section className="test-case"> | ||
<h2 className="type-subheading"> | ||
<label> | ||
<input type='checkbox' /> |
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.
Maybe we can give the fixture test case a slight but noticeable green border when its checked off? That way it's very easy to scroll through quickly and see which tests you haven't done.
Yes, it makes a lot of sense. We should also link to the PR that fixed it, so that if it regresses you can easily see how it was fixed the first time, which might give important context.
👍 we don't backport bugfixes so this will be a must. Maybe we could automatically detect what version is being used and then only load those fixtures we expect to work in that version. So, say, if an issue was resolved in |
sounds good, I'll toss something together and add it in here 👍 |
Keeping a manifest JS object of all the test cases, with a semver range might be a nice way to keep track of these. I could imagine it getting really useful as the count gets higher. |
FWIW I wouldn't worry too much about supporting 0.13 in fixtures. |
Is there an official stance on support for older versions of react? |
What do you mean? |
Like how far back bug fixes get migrated, and if, for example, if someone filed an issue for React 0.12, and it was fixed in 0.13 - would we backport the fix, or recommend they upgrade? |
We don't really ever backport bug fixes, so we would likely be fine only having the current major version. |
But as long as it doesn't introduce unneeded complexity I see no problem with allowing users to test with older major versions. So since 0.13 restricts us from using functional components, we might as well remove it from the list. We're not going to be backporting anything to it. |
We don’t backport fixes to previous majors apart from really bad cases at the very start of a new major release when we know people haven’t had time to migrate. Having just the previous and current major is enough. |
I think since it's simple enough right now to support 0.13 in these test cases we might as well. it can be helpful to have a longer tail of past work to see how stuff behaved. even if we aren't going to fix anything for that version |
clean up a bit and added some more options to TestCase. tried not to over engineer it. notable additions:
both are optional to allow usage of the component for cases that aren't tracking regressions or fixed bugs |
@@ -0,0 +1,33 @@ | |||
import React from 'react'; |
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.
For React
and ReactDOM
they should just be globally available. If we import it then we're only getting the current version that create-react-app
installed. The react-loader
script will load the selected version from a CDN.
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.
oops that makes sense. force of habit
Radio inputs should only fire change events when the checked | ||
state changes. | ||
`} | ||
minimumVersion="16.0.0" |
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.
Maybe it would be helpful to also add resolvedIn
and resolvedBy
so we could give more details
<TestCase title="foo" resolvedIn="15.2.0" resolvedBy="#1760" />
Then it could say:
This test case was fixed in version 15.2.0 by #1760. This test is not expected to pass for the selected
version, and that's ok!
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.
That would be really cool. How fancy a fixture tool we are making.
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.
I'd be happy to pick up some of the work here. @jquense if you are busy on other things, I've got time to work on this bit. Would a PR to your branch be fine?
Or if you wanna jam on it, that's fine too. I just wanted to pick up some of the load.
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.
go for it 👍 got caught up with work so feel free
Sent out the PR feedback here: jquense#2 |
- Pull in React from window global - Add field to TestCase for fix PR links - Update some styles
91370e3
to
050bf3c
Compare
@jquense @nhunzaker I rebased the PR with master and added a couple changes. The biggest once is a small utility that will cache the version tags for the duration of a session. Since the Github API is rate limited we want to minimize the number of requests we make. |
Don't bust the cache doing feature detection COME ON
8c20f9d
to
ad39395
Compare
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.
Lookin good!
return ( | ||
<div> | ||
<h1>{title}</h1> | ||
{description && ( |
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.
Double spaces here?
.then(tags => { | ||
let versions = tags.map(tag => tag.name.slice(1)); | ||
versions = ['local', ...versions]; | ||
versions = [`local (${React.version})`, ...versions]; |
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.
Is this always going to be the current version you have loaded? So if you load 0.13.0, will it say local 0.13.0
?
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.
Yupp, I just removed it. It also caused problems when changing versions as it checks query.version === 'local'
fixtures/dom/src/tags.js
Outdated
if (canUseSessionStorage) { | ||
cachedTags = sessionStorage.getItem(TAGS_CACHE_KEY); | ||
} | ||
console.log({ cachedTags }) |
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.
Do we want to hold on to this log?
👍 |
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.
Let's get this merged and start working on the fixture test cases so this doesn't get forgotten about.
related to: #8583
Let me know if this is way off base with what ya’ll are thinking :P Always fun to see how others build stuff
cc @nhunzaker @aweary