jiebi/CodeConvo huggingface dataset:
Here's an example: (no jsfiddle because that's broken in IE8)
I tried to fix this bug yesterday but had a bad time trying to find a fix for a similar cases. I looked at current well maintained libraries and didn't find a way to make scroll bubble or capture it on IE8. Seems like trying to fix it would be a waste of time and would make code much complex, for a browser that is slowly dying. My suggestion is to point that out on the documentation.
Seems like this isn't so easy. Let's do what says and document it.
do you think that we should do a everytime someone uses onScroll on any browser or would that be annoying? I would say it would be annoying but it would also be very frustrating to figure that it's a React limitation after some hours of debugging on IE8 (ugh!)
+1 on the warning -- would be super helpful.
reopening so we can add a warning
Warning was in
Now that events are listened on demand, maybe the warning should be moved to method, where support is already checked?
It also prints the warning if you render on the server, its annoying :/
That's odd, I wouldn't expect that code to run at all when using server rendering.
I see this warning when I'm doing with . Any chance to disable it?
I also see this error when using ssr
This is happening to me with JSDOM as well and in my case our team project standards aren't going to accommodate leaving these errors in the console when tests are run. How can I suppress or stub this out. It's not just obnoxious it is preventing me from getting my work merged in our project.
/ - I am now seeing this error after upgrading my version of Enzyme to . Did you find a way to suppress these warnings for JSDOM?
If you're having problems please file a new issue. Nobody actively reads old issues, and requests for help here will get lost.
A component should either be using uncontrolled inputs or controlled inputs, but not both (they should pick a single paradigm, for the lifetime of the component). As a result, an instance of an input should never switch from controlled to uncontrolled (or vice versa). We should warn when an input that was previously controlled becomes uncontrolled, or vice versa.
Could you provide some code as to how a controlled input becomes uncontrolled and vice versa?
I just got this warning, can anyone point me to an explanation with a bit more detail? ty
put your code in a stackoverflow question, and link it here.
newswim Read about controlled components and uncontrolled components. Choose one (preferably controlled components), and don't ever use uncontrolled components. If you are using controlled components, make sure you never pass a or to React. And yes, is correct, this is better addressed on StackOverflow.
I don't consider an input's value being null or undefined as a qualifying factor in determining if an input is controlled or uncontrolled. Controlled forms are a paradigm that may share some qualities with uncontrolled forms. It's about listening to changes and updating the state of the value, but React shouldn't stipulate that the value can't be undefined. It's an additional burden to those following good practice in using controlled forms. This warning should occur if both defaultValue and value props are used throughout the input's lifecycle.
I agree, but in the sense that they shouldn't be a single component at all, they should be two separate. Regardless I would say that actually providing the correct string value to an interactive component that expects a string value seems like a rather good practice. Otherwise you will have two distinct value states and , but both being intended to mean the exact same thing. No, because being or makes it uncontrolled by definition and you shouldn't switch between controlled and uncontrolled.
This has no dependencies so I think we should either publish it as a standalone module or direct people to something else from the community. I'm inclined to do the latter since it means we can wash our hands of it. Our internal usage of is tied to our transforms so we've said no to features that would be useful to others outside FB. I'm concerned we'd do that again. Any suggestions for existing projects that we can point to?
Can't we just link to a bunch of "useful scripts" in the docs and leave it at that? People are free to use/modify them, it's implied they're not being maintained and are there just for getting people started. I feel like a lot of people don't understand the current state of , but expect them to be full-blown frameworks and updated with every feature conceivable. Publishing on NPM kind of continues that trend and I suspect no-one on Team React really cares about the addons enough. So I would say, make them available in the docs (as code/files) and let the community sort out publishing/improving/direction.
...Can I "steal" the code and post it somewhere else under my name? I do need it for another CSS repo of mine, and it's really not React-specific.
After talking with Jed at the conference, I think I'll just point people at
Pete hunt already has react-classset module on npm I believe as well
According to the react-classset has been deprecated in favor of the above mentioned library.
It is. They're pretty much the same except for some negligible differences so I deprecated the former (the latter has an active maintainer).
for example, when the original value is '.98', we need format it to '0.98'. but it is not take effect
This is working for me -
your example is not same with mine. the key is .98 can't be formated to 0.98. Because as number they are equal.
Just housekeeping. Do we close out issues before a release with the fix has shipped or wait?
typically I close the issue once the has been merged into master
Awesome, thanks! This should land in the next minor release of React:
React 0.8 React 0.9 I think this is because of switched to in 1.0.0. I submitted a to envify which uses instead of recast. This brings us back to 1.5s and delivers the same advantages as recast version (preserves code formatting): I think this is blocker for 0.9.0.
What command are you running, and in what directory? I'm having trouble reproducing the slow-down with just .
Many of the issues created with the with the  template are missing repro information (e.g. a "localhost" or otherwise invalid URL, missing or no repro description). I usually have to review, label, comment, and close this by hand. It would be nice if we had an automated action that checked: Was the issue made with the  template? Does the URL section have an invalid URL (e.g. "localhost" or "company website") Does the repro steps section have invalid steps (e.g. "don't know") For issues that pass all of the above text, the bot should: Assign the "Resolution: Needs More Information" label Close the issue Leave a comment explaining that repro information was missing and that we'll re-open it if information is provided
Related action:
Going to play with this idea here:
I am working on a project that has strict accessibility requirements. The table I am putting some data in has to implement headers and ids attributes to meet accessibility. See W3 techniques here Unfortunately the "headers" attribute is being stripped out because it's not supported by React (it's not on the supported attributes list). Can you please add support for the missing standard attribute called "headers"?
+1
As a workaround I believe on a you can grab the DOMNode with a ref and add what you need.
As it is known (but ), React's SyntheticEvent is pooled. This is confusing for many users as they don't understand why the event starts to behave strangely when used in an async callback, like inside a , a or a callback. There has already been an attempt to solve this problem here: The code of SyntheticEvent's default methods is: It may make sense to be more defensive because calling on a pooled event will raise . It would be more useful to add a check like:
To illustrate the problem in not being defensive, I would give you this commit that has made it into production as a workaround in React-tappable: Basically the user is trying to assign an empty function to a SyntheticEvent that as been put back in the pool (the call to persist was from another PR at the same time). And we were basically 3 concurrent PR to try different solutions to the exact same problem.
As the person who made the PR in a panic, I did find the code that broke in react itself. the preventDefault method tries to call the method on . A simple if check for in the method, and a no-op if null would be a great fix to this problem. Similar to how setState is handled on an unmounted component.
I think React should not swallow this error and be fail fast, because this does not make any sense to preventDefault in an async callback (because the default already has been applied), React should rather throw an error. But this is only my opinion, because the browser behavior with dom events is not fail fast and swallow that bad usage of preventDefault. I mean the browser does not throw an error when we do: It simply has no effect (like what you suggest) I don't like this and would rather change the behavior of both React and the browser, but I don't think I can do much on my own... Maybe at least React could issue a warning in DEV env?
Yeah, I think warning is appropriate here.
A warning would be great!
Just wonder what kind of message should be put into this warning. If event pooling is not going to be documented (will it?), it may be strange to explain the pooling system inside a warning no?
Yes, event pooling should/will be documented. Feel free to submit a PR. We should add a warning to let the user know that the event has been returned to the pool and so invoking methods on it makes no sense.
Issue with the reproducible example . Full build contains non-standard iterator. Theoretical, it can be to ES in the future, it can be (or already ) to another libraries. should take into account possibility iterable numbers.
Well, the good news is that if this is already on enough pages, then introducing iterable numbers may not be web compatible anyway. I think that this is only in DEV only code. Unfortunately a lot of pages incorrectly uses the DEV build of React.
"good news"
Do you want to request a feature or report a bug? Report a bug What is the current behavior? React sets (via attributes / defaultValue) on all inputs with and no value. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: (actual, React) (expected, vanilla DOM) What is the expected behavior? value attribute should be empty unless passed via props. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 15+, any browser.
cc
I think this happens because the default value reported by checkboxes and radios is "on", in absence of a value property/attribute. Unfortunately, for ~16 our controlled text input code "detatches" value by assigning it over: We have some updates on master that prevent this, but I'll prep a test case for it and send it out. I'm also working on a PR that isolates the controlled checked and controlled value code to help prevent accidents like this in the future.
Sent with Lucky number .
We now have a test to confirm that this works as intended on master. This should land in the next release of React.
is currently only supported as element, not as attribute in . Since it is unknown to react it's thrown away on render.
I'd like to take this!
It's yours Let me know if you have any questions.
Cool! :+1:
Can we get this into a PR pretty please? :o)
Umm this was merged 3 years ago already...
my apologies. I came across this from a Google search after using cite in blockquote in React 16.8.6 was throwing an error for me at build time. I'll have to dig deeper into the cause.
:+1:
+1
+1
I'mma jump on the :+1: bandwagon too. Great idea.
I don't want to keep duplicated issues opened so just to sumup: said it makes sense to implement "namespacing" using colons as opt-in, config-defined option, where one of the possibilities would be a member expression. I don't have enough time to implement it this way, so I closed my issue. More on why&how in jeffmo's final comment and in in general
+1
+1
A non JavaScript-first implementation that wouldn't require changes to :
PR landing for JSX member expressions , can close this.
From : cc
Fixed.
Reopening because new docs don't have that info, and it is confusing. We should re-add it.
I am looking to make my first contribution and would like to fix this issue.
I also opened a PR for this on last week, restoring the original note. I notes for discussion on a more thorough example on the PR, like the current example has, but have not done much beyond that. Do we think that such an example would be beneficial? I almost think not, since the difference is just treating as an array with , but I'm curious to hear everyone else's thoughts on that.
There hasn't been any further discussion in PR or on this issue in the last two months, so is that PR all we need to do for this? cc
Sorry. We’ve been busy with a rewrite for React 16, and haven’t been actively reviewing the PRs.
Fixed in
No sweat, I figured as much. React 16 was absolutely worth it, great work!
Steps to reproduce: 1) Disable all add-ons in Firefox 2) Open an URL that points to a XML file 3) AS EXPECTED: A pretty-printed XML is shown 4) Enable the React DevTools Add-on 5) Open the XML file again 6) FAIL: Only the content inside the XML tags are shown Using Firefox Developer Edition 72.0b6 on macOS 10.15.2
I am able to reproduce the behavior described using Firefox Developer Edition (72.0b1) but regular Firefox (71.0) does not exhibit the buggy behavior. I don't believe this is something that the React DevTools add-on should be able to cause, since syntax highlighting is a built-in browser feature. There is no error in the console (or the add-on if I inspect it). Just enabling the extension is enough to immediately "break" pretty-print for XML files, e.g. I believe that this may be a Firefox Developer Edition bug. It's probably not something that an extension should be able to cause. I'll open a bug on their end: cc
Thanks! I see the same with and the LastPass add-on
It's unclear what Firefox is going to do on their end about this, but it seems like we can make this better by checking in the content script if is "text/xml" before injecting any tags.
This will be fixed in the next release.
FYI this issue should be fixed in v4.4 (released today)