Skip to content
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

Merged
merged 7 commits into from
Mar 2, 2017
Merged

Add fixture components #8860

merged 7 commits into from
Mar 2, 2017

Conversation

jquense
Copy link
Contributor

@jquense jquense commented Jan 24, 2017

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

@jquense
Copy link
Contributor Author

jquense commented Jan 24, 2017

image

image

@aweary aweary self-assigned this Jan 24, 2017
<ol>
{children}
</ol>
</div>
Copy link
Contributor

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)

Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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.

@jquense
Copy link
Contributor Author

jquense commented Jan 25, 2017

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' />
Copy link
Contributor

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.

@aweary
Copy link
Contributor

aweary commented Jan 25, 2017

speaking of versions, does it make sense to add something like "fixed in version:" and known exceptions to the test case components.

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 probably want to document some sort of minimum version the test case should work in, to avoid regressions or false positives for a regression

👍 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 15.3 then it would specify that and would not be rendered if the loaded version was 15.2 or lower.

@jquense
Copy link
Contributor Author

jquense commented Jan 25, 2017

sounds good, I'll toss something together and add it in here 👍

@nhunzaker
Copy link
Contributor

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.

@gaearon
Copy link
Collaborator

gaearon commented Jan 25, 2017

FWIW I wouldn't worry too much about supporting 0.13 in fixtures.
But your call—whatever makes more sense.

@nhunzaker
Copy link
Contributor

Is there an official stance on support for older versions of react?

@gaearon
Copy link
Collaborator

gaearon commented Jan 25, 2017

What do you mean?

@nhunzaker
Copy link
Contributor

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?

@aweary
Copy link
Contributor

aweary commented Jan 25, 2017

We don't really ever backport bug fixes, so we would likely be fine only having the current major version.

@aweary
Copy link
Contributor

aweary commented Jan 25, 2017

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.

@gaearon
Copy link
Collaborator

gaearon commented Jan 25, 2017

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.

@jquense
Copy link
Contributor Author

jquense commented Jan 25, 2017

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

@jquense
Copy link
Contributor Author

jquense commented Jan 25, 2017

clean up a bit and added some more options to TestCase. tried not to over engineer it. notable additions:

  • Flag test cases with a minimumVersion greatere than the selected one as "not expected to pass"
  • 'affectedBrowsers' prop for optionally noting which browsers are known to be affected.

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';
Copy link
Contributor

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.

Copy link
Contributor Author

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"
Copy link
Contributor

@aweary aweary Jan 25, 2017

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!

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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

@nhunzaker
Copy link
Contributor

Sent out the PR feedback here: jquense#2

jquense and others added 3 commits February 13, 2017 16:28
- Pull in React from window global
- Add field to TestCase for fix PR links
- Update some styles
@aweary
Copy link
Contributor

aweary commented Feb 13, 2017

@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
Copy link
Contributor

@nhunzaker nhunzaker left a 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 && (
Copy link
Contributor

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];
Copy link
Contributor

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?

Copy link
Contributor

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'

if (canUseSessionStorage) {
cachedTags = sessionStorage.getItem(TAGS_CACHE_KEY);
}
console.log({ cachedTags })
Copy link
Contributor

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?

@jquense
Copy link
Contributor Author

jquense commented Feb 13, 2017

👍

Copy link
Contributor

@aweary aweary left a 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.

@aweary aweary merged commit 2757a53 into facebook:master Mar 2, 2017
@jquense jquense deleted the text-fixtures branch March 2, 2017 20:16
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.

6 participants