-
Notifications
You must be signed in to change notification settings - Fork 46.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
[RFC] Testing Browser Compatibility #8583
Comments
cc @jquense, you've done a lot of work in this area too. What do you think? |
A few thoughts/questions on the high-level structure of the page(s):
|
I would put everything on a single page and have a switch at the top that points to CDN versions or local build, and refreshes the part of the page below when you change them. |
I have a small set of in-browser tests for react-virtualized that read query param and toggle between different versions of react (by version number) and react-virtualized (either a version number pulled from CDN or "local" which runs against the local build). Very useful when checking for regressions or perf changes. +1 to Dan's in-page switch suggestion. The most common case is probably to compare between local and latest release on NPM. |
this sounds really helpful in general. So much of that knowledge now is either lost, or trapped in tons of jsfiddles in many different issues. I'd love if the many many browser decisions made to attend to browser quirks was better documented, ITs always tough to try and understand even the starting point for addressing DOM issues without that knowledge. I'd also add that documenting the minimal reqs for certain changes would be really helpful. Such as input components needing to work with imperative sets to Would this also be a tool for new issues? I wonder what adding to such a page would look like? Changes accompany associated fixes? Is it possible to leverage an existing code iteration tool (codepen/jsbin/jsfiddle) for this? That might make it more helpful for the beginning bits of identifying new issues. |
As I see it, the process would look something like:
|
This is a long term stretch goal, but automatic deployment of the test page when a PR is opened that affects DOM code would be amazing. |
One other item, though I'd be okay with excluding it as a core part of this issue, is base line browser compatibility.
|
#8589 has been merged! The DOM fixtures application is in place and functioning, now we need to focus on writing up all the fixture test cases and designing the UI for them |
Some outstanding DOM issues, i'm personally familiar with are ('ill try and collect others as well)
|
We still need to write the fixture components yeah? I could take a stab at that if its not in process somewhere |
@jquense yupp, go for it! ping me when you've got a PR open and I'll review |
Started to catalog a check list of test cases in the issue description. |
I'm a bit stuck on this one:
Does React expose the ability to touch feature flags with the UMD build? |
@nhunzaker sounds good, I claimed the unclaimed ones 😃 |
Can we close this now? 😃 |
Yes. I think we certainly can. |
Testing browser quirks is challenging. What if we set up a page or site local to the React repository that made it easier to isolate browser differences and document known issues:
For example:
http://natehunzaker.com/react-issue-reproducer/cases/input-kitchen-sink/index.html
We could start with some of the outstanding input issues (like #7359), and work our way backward to historical decision points for adding additional rules to support specific browsers.
Speaking with @gaearon and @aweary about this. We see a couple of outstanding tasks:
Eventually, this could also be a great resource for how React handles DOM manipulation, obscure DOM API concepts, and reference notes for implementors of other DOM rendering libraries.
Test cases
The text was updated successfully, but these errors were encountered: