Question: var ReactServerRendering; var ReactTestUtils; <del> var cx; </del> var reactComponentExpect; var mocks; describe('ReactCompositeComponent', function() { beforeEach(function() { <del> cx = require('cx'); </del> mocks = require('mocks'); reactComponentExpect = require('reactComponentExpect');

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).


Question: var didWarnValueNull = false; var didWarnValueDefaultValue = false; var didWarnCheckedDefaultChecked = false; <ins> var didWarnControlledToUncontrolled = false; var didWarnUncontrolledToControlled = false; </ins> function forceUpdateIfMounted() { if (this._rootNodeID) {

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.


Question:
 const React = window.React; import Fixture from '../../Fixture'; class NumberInputDecimal extends React.Component { state = { value: '.98' }; changeValue = () => { this.setState({ value: '0.98', }); } render() { const {value} = this.state; return ( <Fixture>
{this.props.children}

 <input type="number" value={value} onChange={(e) => { this.setState({value: e.target.value}); }} /> <button onClick={this.changeValue}>change.98 to 0.98</button>
 </Fixture> ); } } export default NumberInputDecimal;

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:


Question: */ import throttle from 'lodash.throttle'; <del> import { useCallback, useEffect, useLayoutEffect, useMemo, useState, } from 'react'; </del> <ins> import {useCallback, useEffect, useLayoutEffect, useState} from 'react'; </ins> import {unstable_batchedUpdates as batchedUpdates} from 'react-dom'; import { localStorageGetItem,

Do you want to request a feature or report a bug? Report a bug What is the current behavior? The hook's value is shown as in React DevTools if the value is a string or a number. Clicking on the bug icon prints the correct values to console. ! 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. CodeSandbox: Direct link to page so you can see the DevTools: What is the expected behavior? The DevTools should show the correct value of the hook. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.9.0. Google Chrome [Version 77.0.3865.90 (Official Build) (64-bit)] running on Linux x64. This issue appeared after version 4.1.0 (9/19/2019) of the DevTools Chrome extension. Might be same bug as but this one appears without any complicated reproduction steps.
Looks like the issue also appears with boolean values.
Having the same problem. The extension worked fine after I downgraded React to version 16.8.6
I think the only significant difference between React v16.8 and v16.9 is that v16.9 injects the function DevTools uses to support editable hooks (in other words, DevTools is using a different code path when you run v16.8 vs v16.9). I think that means this bug is probably related to somehow. Will dig in more.
Should be fixed by
This fix will be released with 4.1.1 (sometime soon)
This fix has just been published to NPM and posted to Chrome/Firefox as v4.1.1


Question: assign( ShallowComponentWrapper.prototype, ReactCompositeComponent.Mixin, { <ins> _constructComponent: ReactCompositeComponent.Mixin._constructComponentWithoutOwner, </ins> _instantiateReactComponent: function(element) { return new NoopInternalComponent(element); },

There appears to have been a change in how is generated between 0.13 and 0.14 which is causing a number of our shallow rendered tests to fail when upgrading because the deepEquals fails on the property. Here is a simple example component which exhibits the issue.
I've been seeing some similar issues with shallow rendering. My current (messy - sorry!) workaround is this: Let me know if that helps! My version currently breaks some of the Jest tests, but I'm happy to work on this some more and submit a PR.
Thank you very much for this, it's been a tremendous help! While this solved the problem for my test case above it still failed on a large number of our more complex tests. I've been iterating on it and once I have all of our tests passing I'll add the updated version.
Here is the updated workaround, it works for our 238 tests of varying complexity but I'd be interested to see if it passes all of your tests as well.
Awesome! If you don't mind trying, what happens if you do and then use the earlier ?
Much cleaner thanks, I guess I was in my head too much :)
I prefer applying a monkey patch, until we have this fixed in react by wrapping TestUtils in my own module:
This should be fixed by .


Question: hookSourceData.originalSourceAST = sourceMetadata.originalSourceAST; hookSourceData.originalSourceCode = sourceMetadata.originalSourceCode; } else { <ins> // TypeScript is the most commonly used typed JS variant so let's default to it // unless we detect explicit Flow usage via the "@flow" pragma. const plugin = originalSourceCode.indexOf('@flow') > 0 ? 'flow' : 'typescript'; </ins> // TODO (named hooks) Parsing should ideally be done off of the main thread. const originalSourceAST = parse(originalSourceCode, { sourceType: 'unambiguous', <del> plugins: ['jsx', 'typescript'], </del> <ins> plugins: ['jsx', plugin], </ins> }); hookSourceData.originalSourceAST = originalSourceAST; if (__DEBUG__) {

DevTools tells Babel to parse the source code using "jsx" and "typescript" plug-ins: This will work for some simple usages of Flow, but syntax may diverge and cause the parsing to fail. Let's scan the source code for a pragma and pass "flow" instead of "typescript" if one is found. We should also add tests for both Flow and TypeScript to the test component pool:
I think something as basic as this should work:


Question: if (__DEV__) { warnIfValueIsNull(props); <ins> var initialValue = inst._wrapperState.initialChecked || inst._wrapperState.initialValue; var defaultValue = props.defaultChecked || props.defaultValue; var controlled = props.checked !== undefined || props.value !== undefined; var owner = inst._currentElement._owner; if ( (initialValue || !inst._wrapperState.controlled) && controlled && !didWarnUncontrolledToControlled ) { warning( false, '%s is changing a uncontrolled input of type %s to be controlled. ' + 'Input elements should not switch from uncontrolled to controlled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components', owner && owner.getName() || 'A component', props.type ); didWarnUncontrolledToControlled = true; } if ( inst._wrapperState.controlled && (defaultValue || !controlled) && !didWarnControlledToUncontrolled ) { warning( false, '%s is changing a controlled input of type %s to be uncontrolled. ' + 'Input elements should not switch from controlled to uncontrolled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components', owner && owner.getName() || 'A component', props.type ); didWarnControlledToUncontrolled = true; } </ins> } // TODO: Shouldn't this be getChecked(props)?


Question: return this.refs.anch; }, render: function() {  var className = cx({'anchorClass': this.props.anchorClassOn});   var className = this.props.anchorClassOn ? 'anchorClass' : '';  return this.props.renderAnchor ?  : ;


Question: } effect = effect.nextEffect; } while (effect !== null); <ins> if (__DEV__) { resetCurrentFiber(); } </ins> isRendering = previousIsRendering;

I've noticed a strange bug with the react redux opt-in. If i use it with a connected class component, everything is ok: If i use it with a connected functional component that use with , i obtain a strange error: in method. I create a codepen to reproduce the issue: PS: Sorry for the cors error, but i don't find the way to add as cdn
I believe the issue here is that expects the second argument to be a function that returns the reference: See: for more information about the API of the hook. Maybe the error thrown could be more clear?
You're right, accept a function as second argument. A warning on wrong argument type could be a good idea.
Ill take this issue on
Sure
i get TypeError: React.useImperativeMethods is not a function in 16.8.0-alpha.1 but when back to 16.7.0-alpha.2 not get this error
The hook was renamed in this PR: Most likely between the 16.7 alpha and 16.8 alpha
Yeah, it was renamed.
yes it work good after rename it where i can get changes between alpha version ?
Commit log. We don't write changelogs for alphas.
I'm taking this in since we want to get Hooks out sooner.
alright np


Question: "node": ">=0.10.0" }, "peerDependencies": { <del> "envify": "~1.0.1" </del> <ins> "envify": "~1.2.0" </ins> }, "browserify": { "transform": ["envify"]

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 .


Question: <ins> name: DevTools Check for bug repro on: issues: types: [opened, edited] issue_comment: types: [created, edited] jobs: check-repro: runs-on: ubuntu-latest steps: - uses: actions/github-script@v3 with: github-token: ${{ secrets.GITHUB_TOKEN }} script: | const URL_REGEXP = /### Website or app[rn]+([^#]+)###/m; const REPRO_STEPS_REGEXP = /### Repro steps[rn]+([^#]+)###/m; const LABEL_NEEDS_MORE_INFORMATION = "Resolution: Needs More Information"; const LABEL_UNCONFIRMED = "Status: Unconfirmed"; function debug(...args) { core.info(args.map(JSON.stringify).join(' ')); } if (context.payload.comment) { debug('Ignoring comment update.'); return; } const user = context.payload.sender.login; const issue = context.payload.issue; const body = issue.body; const urlMatch = body.match(URL_REGEXP); const reproStepsMatch = body.match(REPRO_STEPS_REGEXP); const url = urlMatch !== null ? urlMatch[1].trim() : null; const reproSteps = reproStepsMatch !== null ? reproStepsMatch[1].trim() : null; if (!url || !reproSteps) { debug('This issue is not a DevTools bug report.'); return; } debug(`found URL "${url}"`); debug(`found repro steps "${reproSteps}"`); function formatComment(comment) { return comment .split("n") .map((line) => line.trim()) .join("n") .trim(); } async function getGitHubActionComments() { debug(`Loading existing comments...`); const comments = await github.issues.listComments({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, }); return comments.data.filter(comment => { debug(`comment by user: "${comment.user.login}"`); return comment.user.login === 'github-actions[bot]'; }); } async function getIssueLabels() { const issues = await github.issues.listLabelsOnIssue({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, }); return issues.data; } async function closeWithComment(comment) { if (issue.state !== 'open') { debug(`Issue is not open`); return; } const labels = await getIssueLabels(); const label = labels.find(label => label.name === LABEL_UNCONFIRMED); if (!label) { debug(`Issue was not opened via DevTools bug report template`); return; } const comments = await getGitHubActionComments(); if (comments.length > 0) { debug(`Already commented on issue; won't comment again`); return; } debug(`Missing required information`); await github.issues.addLabels({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, labels: [LABEL_NEEDS_MORE_INFORMATION], }); await github.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body: formatComment(comment), }); await github.issues.update({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, state: 'closed', }); } async function openWithComment(comment) { if (issue.state !== 'closed') { debug(`Issue is already open`); return; } const labels = await getIssueLabels(); const label = labels.find(label => label.name === LABEL_NEEDS_MORE_INFORMATION); if (!label) { debug(`Issue was not tagged as needs information`); return; } const comments = await getGitHubActionComments(); if (comments.length === 0) { debug(`Issue was closed by someone else; won't reopen`); return; } debug(`Re-opening closed issue`); await github.issues.removeLabel({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, name: LABEL_NEEDS_MORE_INFORMATION, }); await github.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body: formatComment(comment), }); await github.issues.update({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, state: 'open', }); } const PROBABLY_NOT_A_URL_REGEX = /(^Chrome$|^Firefox$| Website)/i; const COMMENT_HEADER = ` @${user}: We're sorry you've seen this error. ❤ `.trim(); const COMMENT_FOOTER = ` Please help us by providing a link to a CodeSandbox (https://codesandbox.io/s/new), a repository on GitHub, or a minimal code example that reproduces the problem. (Screenshots or videos can also be helpful if they help provide context on how to repro the bug.) Here are some tips for providing a minimal example: https://stackoverflow.com/help/mcve Issues without repros are automatically closed but we will re-open if you update with repro info. `.trim(); if (url.includes("/localhost")) { closeWithComment(` ${COMMENT_HEADER} Unfortunately the URL you provided ("localhost") is not publicly accessible. (This means that we will not be able to reproduce the problem you're reporting.) ${COMMENT_FOOTER} `); } else if (url.length < 10 || url.match(PROBABLY_NOT_A_URL_REGEX)) { closeWithComment(` ${COMMENT_HEADER} It looks like you forgot to specify a valid URL. (This means that we will not be able to reproduce the problem you're reporting.) ${COMMENT_FOOTER} `); } else if (reproSteps.length < 25) { closeWithComment(` ${COMMENT_HEADER} Unfortunately, it doesn't look like this issue has enough info for one of us to reproduce and fix it though. ${COMMENT_FOOTER} `); } else { openWithComment(` Thank you for providing repro steps! Re-opening issue now for triage. `); } </ins>

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:


Question: form: MUST_USE_ATTRIBUTE, formNoValidate: HAS_BOOLEAN_VALUE, frameBorder: MUST_USE_ATTRIBUTE, <ins> headers: null, </ins> height: MUST_USE_ATTRIBUTE, hidden: MUST_USE_ATTRIBUTE | HAS_BOOLEAN_VALUE, href: null,

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.


Question: override: - ./scripts/circleci/test_entry_point.sh: parallel: true <del> deployment: staging: branch: /.*/ commands: - ./scripts/circleci/upload_build.sh </del>

It looks like this: It happened two times on random commits, and I don't see a pattern. Probably caused by me changing how tasks are distributed between parallel nodes in I don't understand why would try to run before a build exists though (if that's what's happening?)
I think this one would require some experience with CircleCI. I don't have any pointers as to where to start: I don't understand why it's failing myself. So it's not a very beginner-friendly issue (I marked the difficulty as medium for that reason).
Another example:
I want to work on this. After doing some research on circleci document, I didn't find the document said about parallel test and deployment sequence. I'm curious about how circleci deal with parallel test and deployment sequence. I think there are two situations: all parallel test finishes, run deployment sequence. If this is true, I think it won't cause current test error. container runs deployment after the container's test finished. I guess it is more likely in this case. Sometimes it passed, it's because node 2 already built file. Sometimes it failed because node 2 didn't build file yet. So I think maybe that's because each container will run deployment after that node test finished. If the situation is as above, I come up with two solutions. we want to keep current test flow, we can try to keep each node builds time balance. this test at first, then run other test parallel. reference link:
Only node 2 does a full build. So I don't understand how deployment on other nodes could work at all.
Or do nodes share the file system?
I think nodes share the file system. Otherwise, it should fail every time. It will be easier to debug if we can add more log, like current build time and .
Would it make sense to change the upload script to only run on the second node?
Yep, I think so, because in the document I can't ensure whether deployment stage is triggered after all parallel test finished.
Can we just put the deployment command right into the test command? Is there any benefit to separating them?
I think it's also workable, but may lead misunderstanding. Cause we put build process to test stage. Or we can try to use stage. Run at compile stage, so we can promise and stages have needed file.


Question: override: - ./scripts/circleci/test_entry_point.sh: parallel: true <del> deployment: staging: branch: /.*/ commands: - ./scripts/circleci/upload_build.sh </del>

The interesting part is our regular tests don't need compilation. If "compile" stage has to run before any other stages then we'll wait unnecessarily. I'd prefer to have a single script that does everything than to buy into CircleCI specific terminology unless it buys us something real good (e.g. parallelism was very useful). Maybe can try this:
OK, I understand your consideration. I think this fix will work. Just tell me if anything can help.


Question: workInProgress: Fiber, priorityLevel: PriorityLevel, ): void { <ins> if (__DEV__) { checkClassInstance(workInProgress); } </ins> const instance = workInProgress.stateNode; const state = instance.state || null;

Follow up from Here's one I found. These two invariants: are in a function that's behind a DEV block: I don't think this is intentional, but need to verify. There may be more. I'll use this issue to track while preserves existing behavior.
Here’s another difference: in development, putting a string ref on a functional component throws with: Stateless function components cannot have refs. but in production gives you: Element ref was specified as a string but no owner was set.


Question: <ins> --- layout: none --- <?xml version="1.0" encoding="UTF-8"?> <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>{{ site.name }}</title> <description>{{ site.description }}</description> <link>{{ site.url }}{{ site.baseurl }}</link> <atom:link href="{{ site.url }}{{ site.baseurl }}/feed.xml" rel="self" type="application/rss+xml" /> {% for post in site.posts limit:10 %} <item> <title>{{ post.title | xml_escape }}</title> <description>{{ post.content | xml_escape }}</description> <pubDate>{{ post.date | date_to_xmlschema }}</pubDate> <link>{{ site.url }}{{ site.baseurl }}{{ post.url }}</link> <guid isPermaLink="true">{{ site.url }}{{ site.baseurl }}{{ post.url }}</guid> </item> {% endfor %} </channel> </rss> </ins>

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.


Question: <ins> --- layout: none --- <?xml version="1.0" encoding="UTF-8"?> <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> <channel> <title>{{ site.name }}</title> <description>{{ site.description }}</description> <link>{{ site.url }}{{ site.baseurl }}</link> <atom:link href="{{ site.url }}{{ site.baseurl }}/feed.xml" rel="self" type="application/rss+xml" /> {% for post in site.posts limit:10 %} <item> <title>{{ post.title | xml_escape }}</title> <description>{{ post.content | xml_escape }}</description> <pubDate>{{ post.date | date_to_xmlschema }}</pubDate> <link>{{ site.url }}{{ site.baseurl }}{{ post.url }}</link> <guid isPermaLink="true">{{ site.url }}{{ site.baseurl }}{{ post.url }}</guid> </item> {% endfor %} </channel> </rss> </ins>

Once the docs are written, we can add a link to the end of the warning.
Got a PR for this! Would really appreciate some feedback.


Question: export function createCache(invalidator: () => mixed): Cache { const resourceMap: ResourceMap = new Map(); <del> function accessRecord<K, V>(resourceType: any, key: K): Record<V> { </del> <ins> function accessRecord<K, V>(resourceType: any, key: K): Record<K, V> { </ins> if (__DEV__) { warning( typeof resourceType !== 'string' && typeof resourceType !== 'number',

In we landed a change to the Flow types in , making the types for the various types recursive with their and properties. On that PR we may have been running an older version of Flow - I'm not having luck finding the record of when Flow ran for that PR, so not sure. In any case, that PR was merged even though it had the recursive Flow type definitions, plus one or more Flow errors which were unrelated and not detected. The problem with the recursive type definitions is that recent versions of Flow will go into an infinite loop if they try to infer types which are recursive. The solution may be to add more detail to those types, but to unblock things we temporarily made them looser type definitions.


Question: * @param [string ...]  Variable list of classNames in the string case. * @return string       Renderable space-separated CSS className. */ <ins> 'use strict'; var warning = require('warning'); var warned = false; </ins> function cx(classNames) { <ins> if (__DEV__) { warning( warned, 'React.addons.classSet will be deprecated in a future version. See ' + 'http://fb.me/react-addons-classset' ); warned = true; } </ins> if (typeof classNames == 'object') { return Object.keys(classNames).filter(function(className) { return classNames[className];


Question: ); }); <ins> it('should not enumerate enumerable numbers (#4776)', function() { /*eslint-disable no-extend-native */ Number.prototype['@@iterator'] = function() { throw new Error('number iterator called'); }; /*eslint-enable no-extend-native */ try { var instance = ( <div> {5} {12} {13} </div> ); var traverseFn = jasmine.createSpy(); traverseAllChildren(instance.props.children, traverseFn, null); expect(traverseFn.calls.length).toBe(3); expect(traverseFn).toHaveBeenCalledWith( null, 5, '.0' ); expect(traverseFn).toHaveBeenCalledWith( null, 12, '.1' ); expect(traverseFn).toHaveBeenCalledWith( null, 13, '.2' ); } finally { delete Number.prototype['@@iterator']; } }); </ins> });

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"


Question:
 /** * Copyright 2013-2015, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @emails react-core */ 'use strict'; var React; var ReactDOM; var ReactTestUtils; describe('ReactEventIndependence', function() { beforeEach(function() { require('mock-modules').dumpCache(); React = require('React'); ReactDOM = require('ReactDOM'); ReactTestUtils = require('ReactTestUtils'); }); it('does not crash with other react inside', function() { var clicks = 0; var div = ReactTestUtils.renderIntoDocument(
 clicks++} dangerouslySetInnerHTML={{ __html: '<button data-reactid=".z">click me
', }} /> ); ReactTestUtils.SimulateNative.click(div.firstChild); expect(clicks).toBe(1); }); it('does not crash with other react outside', function() { var clicks = 0; var outer = document.createElement('div'); outer.setAttribute('data-reactid', '.z'); var inner = ReactDOM.render( <button onClick={() => clicks++}>click me</button>, outer ); ReactTestUtils.SimulateNative.click(inner); expect(clicks).toBe(1); }); it('does not when event fired on unmounted tree', function() { var clicks = 0; var container = document.createElement('div'); var button = ReactDOM.render( <button onClick={() => clicks++}>click me</button>, container ); // Now we unmount the component, as if caused by a non-React event handler // for the same click we're about to simulate, like closing a layer: ReactDOM.unmountComponentAtNode(container); ReactTestUtils.SimulateNative.click(button); // Since the tree is unmounted, we don't dispatch the click event. expect(clicks).toBe(0); }); });

Since upgrading from beta3 to rc1 I've seen this error a few times in production. Haven't been able to trace the source yet though. cc
I was unmounting a root during a keyboard event which caused this to happen. I think this has always been a problem? Perhaps we've only been lucky... leaving open just to be sure. EDIT: Could it make sense to have something along the lines of ? Allowing you to schedule things to occur as soon as the current transaction ends.
This invariant was new in this release. We also hit one case at FB that I haven't yet investigated. Probably need to change something for the final release.
I have seen this on RC1 can't find a sequence of actions to repeat it.
I'm running into this issue as well when conditionally rendering based on state. Not sure how to boil it down to a simple reproducible bug report yet.
My issue only happens when I am leveraging FastClick. Didn't happen before 0.14.
I've found it is because the events are handled in a different order with fastclick, so the batching gets weird...
e.g. click gets fired before touchEnd, so click handler setState to remove subtree, and then react tries to do something with it in touch end perhaps?


Question:
 /** * Copyright 2013-2015, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @emails react-core */ 'use strict'; var React; var ReactDOM; var ReactTestUtils; describe('ReactEventIndependence', function() { beforeEach(function() { require('mock-modules').dumpCache(); React = require('React'); ReactDOM = require('ReactDOM'); ReactTestUtils = require('ReactTestUtils'); }); it('does not crash with other react inside', function() { var clicks = 0; var div = ReactTestUtils.renderIntoDocument(
 clicks++} dangerouslySetInnerHTML={{ __html: '<button data-reactid=".z">click me
', }} /> ); ReactTestUtils.SimulateNative.click(div.firstChild); expect(clicks).toBe(1); }); it('does not crash with other react outside', function() { var clicks = 0; var outer = document.createElement('div'); outer.setAttribute('data-reactid', '.z'); var inner = ReactDOM.render( <button onClick={() => clicks++}>click me</button>, outer ); ReactTestUtils.SimulateNative.click(inner); expect(clicks).toBe(1); }); it('does not when event fired on unmounted tree', function() { var clicks = 0; var container = document.createElement('div'); var button = ReactDOM.render( <button onClick={() => clicks++}>click me</button>, container ); // Now we unmount the component, as if caused by a non-React event handler // for the same click we're about to simulate, like closing a layer: ReactDOM.unmountComponentAtNode(container); ReactTestUtils.SimulateNative.click(button); // Since the tree is unmounted, we don't dispatch the click event. expect(clicks).toBe(0); }); });

In this repro, I created 2 buttons and only one is rendered at a time. One button's click handler is hooked up to React's synthetic "click" event while the other is hooked up to the native "click" event. Even though only one button is rendered at a time, a single click is triggering both click events. This bug can be hit by apps that mix React components with non-React controls (e.g. jQuery UI). I reproed this in Chrome with React 0.13.2. to the button labeled "One" Expected: There's a button rendered labeled "Two" Actual: The rendered button still has the label "One" If you open the console, you'll see "goToTwo" and "goToOne" which indicates that the "One" button's click handler ran and then the "Two" button's click handler ran (even though we never saw button "Two"").
I experimented more and came up with another repro: In this one, you click on a button with a native "click" handler which causes the button to go away and an input field to be rendered. It results in this exception: From these 2 repros, it seems something strange is going on when calling from within a native "click" handler.
It works if you add to the event handler.
Thanks for the workaround. Is the behavior without the by design? It looks like the bad behavior is being caused by the rerender happening synchronously within the native "click" handler.
This looks bad. We don't do a great job interacting with native events. Sebastian wrote a post about this once-upon-a-time, how native and synthetic event systems are, by and large, not interoperable. Even so, I can't see a reason we should fatal like this. Do you understand what's going wrong here? What a fix might look like?
This happens when we handle a click event from a node that's been removed in between when the event is triggered and when React receives it. How should we deal with the case that events fire on detached elements? Should we ignore events for nodes that aren't in the document? I don't think the bug is easily fixable otherwise because we don't have the old event handler after the reconcile that removes that node.
Here are some additional details about the impact of the bug.


Question:
 /** * Copyright 2013-2015, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @emails react-core */ 'use strict'; var React; var ReactDOM; var ReactTestUtils; describe('ReactEventIndependence', function() { beforeEach(function() { require('mock-modules').dumpCache(); React = require('React'); ReactDOM = require('ReactDOM'); ReactTestUtils = require('ReactTestUtils'); }); it('does not crash with other react inside', function() { var clicks = 0; var div = ReactTestUtils.renderIntoDocument(
 clicks++} dangerouslySetInnerHTML={{ __html: '<button data-reactid=".z">click me
', }} /> ); ReactTestUtils.SimulateNative.click(div.firstChild); expect(clicks).toBe(1); }); it('does not crash with other react outside', function() { var clicks = 0; var outer = document.createElement('div'); outer.setAttribute('data-reactid', '.z'); var inner = ReactDOM.render( <button onClick={() => clicks++}>click me</button>, outer ); ReactTestUtils.SimulateNative.click(inner); expect(clicks).toBe(1); }); it('does not when event fired on unmounted tree', function() { var clicks = 0; var container = document.createElement('div'); var button = ReactDOM.render( <button onClick={() => clicks++}>click me</button>, container ); // Now we unmount the component, as if caused by a non-React event handler // for the same click we're about to simulate, like closing a layer: ReactDOM.unmountComponentAtNode(container); ReactTestUtils.SimulateNative.click(button); // Since the tree is unmounted, we don't dispatch the click event. expect(clicks).toBe(0); }); });

It sounds like this bug is likely to trigger when you use a non-React component (e.g. jQuery UI) in a React single page application and the non-React component triggers a navigation within the app.
Thanks for an excellent bug report and good repro case! I think this happens because we use the "root id" to determine which element was clicked. In the repro case there is no "key" as part of the root ID for two reasons: 1) It is not a child of a container (multichild) so it doesn't get a key to the root ID. 2) It doesn't have a unique key and doesn't need one because it the button is of a different type. If I make sure that a key is used as part of the root ID the problem is solved: So the problem in the repro isn't that we're firing on a removed node, it is that we're firing the event on the new node. This would be solved if we used a unique ID per instance to identify event handlers instead of a generate root that is non-unique. Which I think we wanted to do anyway. Is there another repro that shows a different issue?


Question: describe('ReactDOMComponent', function() { var React; var ReactDOM; <del> var ReactDOMFeatureFlags; </del> var ReactDOMServer; beforeEach(function() { jest.resetModuleRegistry(); React = require('React'); <del> ReactDOMFeatureFlags = require('ReactDOMFeatureFlags') </del> ReactDOM = require('ReactDOM'); ReactDOMServer = require('ReactDOMServer'); });

Appears to be working in Firefox but at least Chrome & Safari are broken. Should be a really recent regression so very few possible changes to blame... Easiest repo: the todo list on our homepage.
Just a heads up but this still seems to be an issue even on 15.4.1. I've been struggling to reproduce this because it seems to be some sort of ninja bug. Nevertheless, I was wondering if anyone is still dealing with this problem?
I haven't seen anything.
I'm still seeing this issue.
Please open a new issue with a simplified repro case if you're still seeing this!


Question: - Gemfile.lock - README.md - Rakefile <ins> url: http://facebook.github.io </ins> baseurl: /react permalink: /blog/:year/:month/:day/:title.html


Question: - Gemfile.lock - README.md - Rakefile <ins> url: http://facebook.github.io </ins> baseurl: /react permalink: /blog/:year/:month/:day/:title.html


Question: expect(console.error.argsForCall.length).toBe(1); }); <ins> it('should warn if controlled input switches to uncontrolled', function() { var stub = <input type="text" value="controlled" onChange={emptyFunction} />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="text" />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a controlled input of type text to be uncontrolled. ' + 'Input elements should not switch from controlled to uncontrolled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if controlled input switches to uncontrolled with defaultValue', function() { var stub = <input type="text" value="controlled" onChange={emptyFunction} />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="text" defaultValue="uncontrolled" />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a controlled input of type text to be uncontrolled. ' + 'Input elements should not switch from controlled to uncontrolled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if uncontrolled input switches to controlled', function() { var stub = <input type="text" />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="text" value="controlled" />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a uncontrolled input of type text to be controlled. ' + 'Input elements should not switch from uncontrolled to controlled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if controlled checkbox switches to uncontrolled', function() { var stub = <input type="checkbox" checked={true} onChange={emptyFunction} />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="checkbox" />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a controlled input of type checkbox to be uncontrolled. ' + 'Input elements should not switch from controlled to uncontrolled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if controlled checkbox switches to uncontrolled with defaultChecked', function() { var stub = <input type="checkbox" checked={true} onChange={emptyFunction} />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="checkbox" defaultChecked={true} />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a controlled input of type checkbox to be uncontrolled. ' + 'Input elements should not switch from controlled to uncontrolled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if uncontrolled checkbox switches to controlled', function() { var stub = <input type="checkbox" />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="checkbox" checked={true} />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a uncontrolled input of type checkbox to be controlled. ' + 'Input elements should not switch from uncontrolled to controlled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if controlled radio switches to uncontrolled', function() { var stub = <input type="radio" checked={true} onChange={emptyFunction} />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="radio" />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a controlled input of type radio to be uncontrolled. ' + 'Input elements should not switch from controlled to uncontrolled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if controlled radio switches to uncontrolled with defaultChecked', function() { var stub = <input type="radio" checked={true} onChange={emptyFunction} />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="radio" defaultChecked={true} />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a controlled input of type radio to be uncontrolled. ' + 'Input elements should not switch from controlled to uncontrolled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); it('should warn if uncontrolled radio switches to controlled', function() { var stub = <input type="radio" />; var container = document.createElement('div'); ReactDOM.render(stub, container); ReactDOM.render(<input type="radio" checked={true} />, container); expect(console.error.argsForCall.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'A component is changing a uncontrolled input of type radio to be controlled. ' + 'Input elements should not switch from uncontrolled to controlled (or viceversa). ' + 'Decide between using a controlled or uncontrolled input ' + 'element for the lifetime of the component. More info: https://fb.me/react-controlled-components' ); }); </ins> it('sets type before value always', function() { var log = []; var originalCreateElement = document.createElement;

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.


Question: const [parsedValue, setParsedValue] = useState(initialValue); const [isValid, setIsValid] = useState(initialIsValid); <del> const reset = useCallback(() => { setEditableValue(smartStringify(initialValue)); setParsedValue(initialValue); setIsValid(initialIsValid); }, []); </del> <ins> const reset = useCallback( () => { setEditableValue(smartStringify(initialValue)); setParsedValue(initialValue); setIsValid(initialIsValid); }, [initialValue, initialIsValid], ); </ins> const update = useCallback(newValue => { let isNewValueValid = false;

Do you want to request a feature or report a bug? Report a bug What is the current behavior? The hook's value is shown as in React DevTools if the value is a string or a number. Clicking on the bug icon prints the correct values to console. ! 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. CodeSandbox: Direct link to page so you can see the DevTools: What is the expected behavior? The DevTools should show the correct value of the hook. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.9.0. Google Chrome [Version 77.0.3865.90 (Official Build) (64-bit)] running on Linux x64. This issue appeared after version 4.1.0 (9/19/2019) of the DevTools Chrome extension. Might be same bug as but this one appears without any complicated reproduction steps.
Looks like the issue also appears with boolean values.
Having the same problem. The extension worked fine after I downgraded React to version 16.8.6
I think the only significant difference between React v16.8 and v16.9 is that v16.9 injects the function DevTools uses to support editable hooks (in other words, DevTools is using a different code path when you run v16.8 vs v16.9). I think that means this bug is probably related to somehow. Will dig in more.
Should be fixed by
This fix will be released with 4.1.1 (sometime soon)
This fix has just been published to NPM and posted to Chrome/Firefox as v4.1.1


Question: disableInputAttributeSyncing, enableTrustedTypesIntegration, deferPassiveEffectCleanupDuringUnmount, <ins> warnAboutShorthandPropertyCollision, </ins> } = require('ReactFeatureFlags'); // In www, we have experimental support for gathering data

I a "bug" today that made me spent 1h figuring out what was going on: I'm using an external component that accepts a prop in order to set the of the root element, but this same component also accepts a prop which I wasn't passing, and by default, it was set to . The result: React didn't throw an error nor a warning, however, the resulting element in the DOM didn't contain either or , and since the element had a default coming from a CSS class, it took me a while to figure out why the color that I was passing wasn't being applied, and instead it was using the one from the CSS class. See: What I reported above was the case. I other cases as a bonus, as when I was playing with this they also seemed weird to me. On I define the same properties, but because I change the order, it works. On the toggleable ones, initially I can see the background, but after changing it never appears anymore. I'm not sure if I created those extra "test cases" correctly. My main concern is really around static1 not outputting anything on the console as a warning. Related issues: I wonder if ( should have covered this?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
it seems that the bot automatically closed the issue, but this still needs action. I took a time to investigate it, and I realized that the work Sophie has done covers this case, but there's just one problem: it's disabled under a . I built it locally and flipped the flag, and it works: I can see the helpful warning. It was flagged in , and as per the PR, the original intention was to unflag it on the next minor. Since then we had at least 4 new minor versions, but it is still flagged. Is there a special reason for that or was it just forgotten? tagging you since you this flag, so I'm hoping you can give context here.
Can we unflag this?
This was released.


Question: // TODO: we should warn here. }); }); <ins> describe('checked inputs without a value property', function() { // In absence of a value, radio and checkboxes report a value of "on". // Between 16 and 16.2, we assigned a node's value to it's current // value in order to "dettach" it from defaultValue. This had the unfortunate // side-effect of assigning value="on" to radio and checkboxes it('does not add "on" in absence of value on a checkbox', function() { const container = document.createElement('div'); ReactDOM.render( <input type="checkbox" defaultChecked={true} />, container, ); const node = container.firstChild; expect(node.value).toBe('on'); expect(node.hasAttribute('value')).toBe(false); }); it('does not add "on" in absence of value on a radio', function() { const container = document.createElement('div'); ReactDOM.render(<input type="radio" defaultChecked={true} />, container); const node = container.firstChild; expect(node.value).toBe('on'); expect(node.hasAttribute('value')).toBe(false); }); }); </ins> });

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.


Question: "benchmark": "~1.0.0", "browserify": "~3.20.0", "coverify": "~1.0.4", <del> "envify": "~1.0.1", </del> <ins> "envify": "~1.2.0", </ins> "es3ify": "~0.1.2", "es5-shim": "~2.3.0", "grunt": "~0.4.2",

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 .


Question: charSet: null, challenge: null, checked: MUST_USE_PROPERTY | HAS_BOOLEAN_VALUE, <ins> cite: null, </ins> classID: null, className: null, cols: HAS_POSITIVE_NUMERIC_VALUE,

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.


Question:
A Component Using External Plugins

 React is flexible and provides hooks that allow you to interface with  other libraries and frameworks. This example uses Showdown, an external   other libraries and frameworks. This example uses **marked**, an external  Markdown library, to convert the textarea's value in real-time.

Since copy+pasting our code makes it too easy for people to XSS themselves, lets just add a comment in there about it.
PR at - let me know if that's what you had in mind!
My intuition is that it makes more sense to fix the example (call a sanitization library) or to change the example completely (demonstrate something else that is safer). It looks really bad to have a security warning on the homepage of the react site. Makes it seem like our framework encourages unsafe operations, rather than a safe-by-default way of doing things.
Should switch the demo to use a different library like markdown-js that escapes everything and doesn't support HTML:
markdown-js looks good. First attempt: ,output Code licensed if someone wants to turn this into a coherent example; I've signed the CLA.
That's a good suggestion too :) - what are your thoughts? I'm happy to change the example to use like people have suggested above. nice usage example :+1:
Uh yea, that sounds fine to me. This behavior is definitely non-standard markdown but it's an example so not a big deal. We should probably do the same for the tutorial while we're here. And it's on cdnjs so that's all pretty easy:
Just going to use marked instead, which I'm already familiar with and has an option to sanitize input.


Question: export const disableJavaScriptURLs = false; export const disableInputAttributeSyncing = false; export const exposeConcurrentModeAPIs = __EXPERIMENTAL__; <del> export const warnAboutShorthandPropertyCollision = false; </del> <ins> export const warnAboutShorthandPropertyCollision = true; </ins> export const enableSchedulerDebugging = false; export const enableDeprecatedFlareAPI = false; export const enableFundamentalAPI = false;


Question: expect(console.error.argsForCall.length).toBe(0); }); <ins> it('should not enumerate enumerable numbers (#4776)', function() { /*eslint-disable no-extend-native */ Number.prototype['@@iterator'] = function() { throw new Error('number iterator called'); }; /*eslint-enable no-extend-native */ try { void ( <div> {5} {12} {13} </div> ); } finally { delete Number.prototype['@@iterator']; } }); </ins> });


Question: ]); }); <ins> it('warns for bad useImperativeHandle first arg', () => { const {useImperativeHandle} = React; function App() { useImperativeHandle({ focus() {}, }); return null; } expect(() => { expect(() => { ReactTestRenderer.create(<App />); }).toThrow('create is not a function'); }).toWarnDev([ 'Expected useImperativeHandle() first argument to either be a ' + 'ref callback or React.createRef() object. ' + 'Instead received: an object with keys {focus}.', 'Expected useImperativeHandle() second argument to be a function ' + 'that creates a handle. Instead received: undefined.', ]); }); it('warns for bad useImperativeHandle second arg', () => { const {useImperativeHandle} = React; const App = React.forwardRef((props, ref) => { useImperativeHandle(ref, { focus() {}, }); return null; }); expect(() => { ReactTestRenderer.create(<App />); }).toWarnDev([ 'Expected useImperativeHandle() second argument to be a function ' + 'that creates a handle. Instead received: object.', ]); }); </ins> // https://github.com/facebook/react/issues/14022 it('works with ReactDOMServer calls inside a component', () => { const {useState} = React;

I've noticed a strange bug with the react redux opt-in. If i use it with a connected class component, everything is ok: If i use it with a connected functional component that use with , i obtain a strange error: in method. I create a codepen to reproduce the issue: PS: Sorry for the cors error, but i don't find the way to add as cdn
I believe the issue here is that expects the second argument to be a function that returns the reference: See: for more information about the API of the hook. Maybe the error thrown could be more clear?
You're right, accept a function as second argument. A warning on wrong argument type could be a good idea.
Ill take this issue on
Sure
i get TypeError: React.useImperativeMethods is not a function in 16.8.0-alpha.1 but when back to 16.7.0-alpha.2 not get this error
The hook was renamed in this PR: Most likely between the 16.7 alpha and 16.8 alpha
Yeah, it was renamed.
yes it work good after rename it where i can get changes between alpha version ?
Commit log. We don't write changelogs for alphas.
I'm taking this in since we want to get Hooks out sooner.
alright np


Question: <meta property="og:description" content="A JavaScript library for building user interfaces" /> <link rel="shortcut icon" href="/react/favicon.ico"> <ins> <link rel="alternate" type="application/rss+xml" title="{{ site.name }}" href="{{ site.url }}{{ site.baseurl }}/feed.xml"> </ins> <link rel="stylesheet" href="/react/css/react.css"> <link rel="stylesheet" href="/react/css/syntax.css">


Question: <meta property="og:description" content="A JavaScript library for building user interfaces" /> <link rel="shortcut icon" href="/react/favicon.ico"> <ins> <link rel="alternate" type="application/rss+xml" title="{{ site.name }}" href="{{ site.url }}{{ site.baseurl }}/feed.xml"> </ins> <link rel="stylesheet" href="/react/css/react.css"> <link rel="stylesheet" href="/react/css/syntax.css">


Question: inst._wrapperState = {selected: selected}; }, <ins> postMountWrapper: function(inst) { // value="" should make a value attribute (#6219) var props = inst._currentElement.props; if (props.value != null) { var node = ReactDOMComponentTree.getNodeFromInstance(inst); node.setAttribute('value', props.value); } }, </ins> getNativeProps: function(inst, props) { var nativeProps = Object.assign({selected: undefined, children: undefined}, props);


Question: module Jekyll module SidebarItemFilter def sidebar_item_link(item) pageID = @context.registers[:page]["id"] itemID = item["id"] href = item["href"] || "/react/docs/#{itemID}.html" className = pageID == itemID ? ' class="active"' : '' return "#{item["title"]}" end end end Liquid::Template.register_filter(Jekyll::SidebarItemFilter)

We're basically keeping 2 copies of documentation in sync and failing. We should just point at and We should maybe make the permalinks on our site redirect or just link offsite. We should also look for links in our docs pointing to those pages and update.
cc
also cc
Definitively agreed, we should link all the traffic to the dedicated website. See the Complementary section on Flux website


Question: miss: A => Promise<V>, missArg: A, ): void { <del> const record: Record<V> = accessRecord(resourceType, key); </del> <ins> const record: Record<K, V> = accessRecord(resourceType, key); </ins> switch (record.status) { case Empty: // Warm the cache.


Question: // Control this behavior with a flag to support 16.6 minor releases in the meanwhile. export const exposeConcurrentModeAPIs = __EXPERIMENTAL__; <del> export const warnAboutShorthandPropertyCollision = false; </del> <ins> export const warnAboutShorthandPropertyCollision = true; </ins> // Experimental React Flare event system and event components support. export const enableDeprecatedFlareAPI = false;


Question: <script src="https://fb.me/react-{{site.react_version}}.js"></script> <script src="https://fb.me/JSXTransformer-{{site.react_version}}.js"></script> <script src="https://code.jquery.com/jquery-1.10.0.min.js"></script> <del> <script src="https://cdnjs.cloudflare.com/ajax/libs/showdown/0.3.1/showdown.min.js"></script> </del> <ins> <script src="https://cdnjs.cloudflare.com/ajax/libs/marked/0.3.2/marked.min.js"></script> </ins> </head> ``` Next, let's convert the comment text to Markdown and output it: <del> ```javascript{2,10} </del> <ins> ```javascript{9} </ins> // tutorial6.js <del> var converter = new Showdown.converter(); </del> var Comment = React.createClass({ render: function() { return (


Question: export const replayFailedUnitOfWorkWithInvokeGuardedCallback = false; export const warnAboutDeprecatedLifecycles = true; <del> export const warnAboutShorthandPropertyCollision = false; </del> export const disableLegacyContext = false; export const warnAboutStringRefs = false; export const warnAboutDefaultPropsOnFunctionComponents = false;


Question: expect(store).toMatchSnapshot('2: add host nodes'); }); <ins> // This test is not the same cause as what's reported on GitHub, // but the resulting behavior (owner mounting after descendant) is the same. // Thec ase below is admittedly contrived and relies on side effects. // I'mnot yet sure of how to reduce the GitHub reported production case to a test though. // See https://github.com/facebook/react/issues/21445 it('should handle when a component mounts before its owner', () => { const promise = new Promise(resolve => {}); let Dynamic = null; const Owner = () => { Dynamic = <Child />; throw promise; }; const Parent = () => { return Dynamic; }; const Child = () => null; const container = document.createElement('div'); act(() => ReactDOM.render( <> <React.Suspense fallback="Loading..."> <Owner /> </React.Suspense> <Parent /> </>, container, ), ); expect(store).toMatchInlineSnapshot(` [root] <Suspense> ▾ <Parent> <Child> `); }); </ins> describe('collapseNodesByDefault:false', () => { beforeEach(() => { store.collapseNodesByDefault = false;

<!-- Please answer both questions below before submitting this issue. --Please provide a link to the URL of the website (if it is public), a CodeSandbox () example that reproduces the bug, or a project on GitHub that we can checkout and run locally. If possible, please describe how to reproduce this bug on the website or app mentioned above: <!-- FILL THIS IN --<!-- FILL THIS IN --<!-- FILL THIS IN --<!---------------------------------------------------<!-- Please do not remove the text below this line --<!---------------------------------------------------DevTools version: 4.13.1- Call stack: at chrome- at (chrome-) at chrome- at listener (chrome-) Component stack: (none) GitHub URL search query:
Hi I'm sorry you ran into this problem Unfortunately, it doesn't look like this issue has enough info for one of us to reproduce it though. This means that it's going to be very hard for us to fix. Please help us by providing a link to a CodeSandbox (), a repository on GitHub, or a minimal code example that reproduces the problem. (Screenshots or videos can also be helpful if they help provide context on how to repro the bug.) Here are some tips for providing a minimal example:
I am also having this bug
See the comment above please :) Repro is needed.
This happened to me, the node wasn't appearing in the Components tree and I was getting this error. The problem was that my attribute was way too long
! suddenly having this issue right now. I thought it was because of my commits, but changing to another old branch just give the same errors. it was working just fine yesterday, don't know why. maybe due to the devtools update or something? btw I'm on react 16.8.6, react devtools 4.13.3 (5/19/2021)
Try updating to the latest release (4.13.4) just to rule anything out. But if you're still seeing the issue, then we still need a repro case.
at first the bug still persists. with same error log. then I retried close the devtools and opened it again (I think I actually have done this as well before) then somehow it works now. the error log still shows up but at least now all components are showing on the devtools, and that's all I need.


Question: expect(store).toMatchSnapshot('2: add host nodes'); }); <ins> // This test is not the same cause as what's reported on GitHub, // but the resulting behavior (owner mounting after descendant) is the same. // Thec ase below is admittedly contrived and relies on side effects. // I'mnot yet sure of how to reduce the GitHub reported production case to a test though. // See https://github.com/facebook/react/issues/21445 it('should handle when a component mounts before its owner', () => { const promise = new Promise(resolve => {}); let Dynamic = null; const Owner = () => { Dynamic = <Child />; throw promise; }; const Parent = () => { return Dynamic; }; const Child = () => null; const container = document.createElement('div'); act(() => ReactDOM.render( <> <React.Suspense fallback="Loading..."> <Owner /> </React.Suspense> <Parent /> </>, container, ), ); expect(store).toMatchInlineSnapshot(` [root] <Suspense> ▾ <Parent> <Child> `); }); </ins> describe('collapseNodesByDefault:false', () => { beforeEach(() => { store.collapseNodesByDefault = false;

in addition, I found this ! and I was trying to hide that component (which has no recent changes on it) to see whether it has any impact. or any component that last showing on the devtools. but for now, that'll be all. thank you for responding
I appreciate the extra information, but this isn't a description that I can use to reproduce (and fix) the bug. I need an actual website (or code) that I can run along with instructions (like "do this, then this") so I can see the bug.
There are some simple code could help reproduce. You could try following code sandbox link. The reproduce steps are: "Do not" open develop panel. to develop panel and go to react dev tab. Errors was shown. I guess it's kind of race condition. When I change the component order such as It will work perfect. Ps: brief explain what component do. The PageLoadProgressHandler will dispatch float element to PopupPool.
Excellent! Thank you, Super interesting that this bug only occurs if you wait to open DevTools until after the page has loaded.
I think it is because only have two components, I have two sites, one it will always happen, another will random happen. or maybe code-sandbox do some strange things.
This is interesting. The reason DevTools throws is that the Fiber's owner (the attribute) points to a Fiber that hasn't been mounted yet. That seems unexpected. This repro is just a wrapper around two NPM packages. Where's the source code for these packages? :D Edit I found it, although there's a lot of indirection here_. Tracing one package which imports another which imports another. Would be helpful if it were flattened but I guess I can always step through the bundled source.
PopupPool: PageLoadProgressHandler: Good luck... XD.
Interestingly, if I copy the , , and source files into the sandbox (and only change the import statement in ) the bug goes away. That's surprising.
I wonder if I'm running slightly different code? The debug log shows a slightly different tree structure.


Question: expect(store).toMatchSnapshot('2: add host nodes'); }); <ins> // This test is not the same cause as what's reported on GitHub, // but the resulting behavior (owner mounting after descendant) is the same. // Thec ase below is admittedly contrived and relies on side effects. // I'mnot yet sure of how to reduce the GitHub reported production case to a test though. // See https://github.com/facebook/react/issues/21445 it('should handle when a component mounts before its owner', () => { const promise = new Promise(resolve => {}); let Dynamic = null; const Owner = () => { Dynamic = <Child />; throw promise; }; const Parent = () => { return Dynamic; }; const Child = () => null; const container = document.createElement('div'); act(() => ReactDOM.render( <> <React.Suspense fallback="Loading..."> <Owner /> </React.Suspense> <Parent /> </>, container, ), ); expect(store).toMatchInlineSnapshot(` [root] <Suspense> ▾ <Parent> <Child> `); }); </ins> describe('collapseNodesByDefault:false', () => { beforeEach(() => { store.collapseNodesByDefault = false;

Is the version of the source you linked me to the same as the one the Sandbox points to in NPM, Edit Looks like the repro is using 0.18.8 (released a couple of months ago) but the latest NPM release is 0.11.1. That being said, it doesn't look like the files that are being imported have changed (at least not in source) so I'm still not sure what's up.
I change two main components to hook style then get better performance, it reduce the error happen, but I still could get error. Some error is happen after component render done and open the panel same behavior with pervious. I'll log my changes in following issue ticket.
Would be nice to get a smaller reproduction of this issue (all of the code in one project, rather than spread across many NPM packages). That's what I was trying to do with moving the source but then the bug goes away b'c the code seems to be different. I noticed one potential difference being the indirection but I'm not sure how likely that is to be related.
Looking at the error while debugging, it looks like the , then either renders it or dispatches a popup event to show it. I'm not sure why (too sleepy to think it through maybe) but sometimes seems to be mounting before_ has, which goes against an assumption in DevTools. Will dig back in tomorrow.
I really appreciate the repro case, but there are so many layers of indirection between the various NPM packages being used to dynamically create the components. It's difficult to trace through. I'm going to hand this issue to you and ask for a smaller repro case. (Without 10+ NPM projects that each require each other.) Is this something you can help with? Edit I fixed this () but the test case I is not great since it relies on unsupported side effects to trigger the problem case. I'd still love to get a smaller repro so I can (1) be sure I fully fixed the problem and (2) add a regression case so it doesn't get re-introduced.
Bugfix released as
thank you fixed on version 4.13.5
Thanks your effort. Your fixed also be success from my side.


Question: var MARKDOWN_COMPONENT = ` <del> var converter = new Showdown.converter(); </del> var MarkdownEditor = React.createClass({ getInitialState: function() { return {value: 'Type some *markdown* here!'};


Question:
--- id: flux-overview title: Flux Application Architecture  next: flux-todo-list.html  ---  Flux is the application architecture that Facebook uses for building client-side web applications.  It complements React's composable view components by utilizing a unidirectional data flow.  It's more of a pattern rather than a formal framework, and you can start using Flux immediately without a lot of new code.

 Flux applications have three major parts: the dispatcher, the stores, and the views (React components).  These should not be confused with Model-View-Controller.  Controllers do exist in a Flux application, but they are controller-views — views often found at the top of the hierarchy that retrieve data from the stores and pass this data down to their children.  Additionally, actions — dispatcher helper methods — are often used to support a semantic dispatcher API.  It can be useful to think of them as a fourth part of the Flux update cycle. Flux eschews MVC in favor of a unidirectional data flow. When a user interacts with a React view, the view propagates an action through a central dispatcher, to the various stores that hold the application's data and business logic, which updates all of the views that are affected. This works especially well with React's declarative programming style, which allows the store to send updates without specifying how to transition views between states. We originally set out to deal correctly with derived data: for example, we wanted to show an unread count for message threads while another view showed a list of threads, with the unread ones highlighted. This was difficult to handle with MVC — marking a single thread as read would update the thread model, and then also need to update the unread count model.  These dependencies and cascading updates often occur in a large MVC application, leading to a tangled weave of data flow and unpredictable results. Control is inverted with stores: the stores accept updates and reconcile them as appropriate, rather than depending on something external to update its data in a consistent way. Nothing outside the store has any insight into how it manages the data for its domain, helping to keep a clear separation of concerns. This also makes stores more testable than models, especially since stores have no direct setter methods like `setAsRead()`, but instead have only an input point for the payload, which is delivered through the dispatcher and originates with actions. ## Structure and Data Flow Data in a Flux application flows in a single direction, in a cycle:
 Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores -------+ Ʌ                                                                                | |                                                                                V +-- (Controller-Views "change" event handlers) ---- (Stores emit "change" events) --+
 A unidirectional data flow is central to the Flux pattern, and in fact Flux takes its name from the Latin word for flow. In the above diagram, the dispatcher, stores and views are independent nodes with distinct inputs and outputs. The actions are simply discrete, semantic helper functions that facilitate passing data to the dispatcher. All data flows through the dispatcher as a central hub.  Actions most often originate from user interactions with the views, and are nothing more than a call into the dispatcher.  The dispatcher then invokes the callbacks that the stores have registered with it, effectively dispatching the data payload contained in the actions to all stores.  Within their registered callbacks, stores determine which actions they are interested in, and respond accordingly.  The stores then emit a "change" event to alert the controller-views that a change to the data layer has occurred.  Controller-views listen for these events and retrieve data from the stores in an event handler.  The controller-views call their own `render()` method via `setState()` or `forceUpdate()`, updating themselves and all of their children. This structure allows us to reason easily about our application in a way that is reminiscent of functional reactive programming, or more specifically data-flow programming or flow-based programming, where data flows through the application in a single direction — there are no two-way bindings. Application state is maintained only in the stores, allowing the different parts of the application to remain highly decoupled. Where dependencies do occur between stores, they are kept in a strict hierarchy, with synchronous updates managed by the dispatcher. We found that two-way data bindings led to cascading updates, where changing one object led to another object changing, which could also trigger more updates. As applications grew, these cascading updates made it very difficult to predict what would change as the result of one user interaction. When updates can only change data within a single round, the system as a whole becomes more predictable. Let's look at the various parts of the Flux update cycle up close. A good place to start is the dispatcher. ### A Single Dispatcher The dispatcher is the central hub that manages all data flow in a Flux application. It is essentially a registry of callbacks into the stores. Each store registers itself and provides a callback. When the dispatcher responds to an action, all stores in the application are sent the data payload provided by the action via the callbacks in the registry. As an application grows, the dispatcher becomes more vital, as it can manage dependencies between stores by invoking the registered callbacks in a specific order.  Stores can declaratively wait for other stores to finish updating, and then update themselves accordingly. ### Stores Stores contain the application state and logic. Their role is somewhat similar to a model in a traditional MVC, but they manage the state of many objects — they are not instances of one object. Nor are they the same as Backbone's collections. More than simply managing a collection of ORM-style objects, stores manage the application state for a particular __domain__ within the application. For example, Facebook's [Lookback Video Editor](https://facebook.com/lookback/edit) utilized a TimeStore that kept track of the playback time position and the playback state. On the other hand, the same application's ImageStore kept track of a collection of images.  The TodoStore in our [TodoMVC example](https://github.com/facebook/flux/tree/master/examples/flux-todomvc) is similar in that it manages a collection of to-do items.  A store exhibits characteristics of both a collection of models and a singleton model of a logical domain. As mentioned above, a store registers itself with the dispatcher and provides it with a callback. This callback receives the action's data payload as a parameter. The payload contains a type attribute, identifying the action's type. Within the store's registered callback, a switch statement based on the action's type is used to interpret the payload and to provide the proper hooks into the store's internal methods. This allows an action to result in an update to the state of the store, via the dispatcher. After the stores are updated, they broadcast an event declaring that their state has changed, so the views may query the new state and update themselves. ### Views and Controller-Views React provides the kind of composable views we need for the view layer. Close to the top of the nested view hierarchy, a special kind of view listens for events that are broadcast by the stores that it depends on. One could call this a controller-view, as it provides the glue code to get the data from the stores and to pass this data down the chain of its descendants. We might have one of these controller-views governing any significant section of the page. When it receives the event from the store, it first requests the new data it needs via the stores' public getter methods. It then calls its own `setState()` or `forceUpdate()` methods, causing its `render()` method and the `render()` method of all its descendants to run. We often pass the entire state of the store down the chain of views in a single object, allowing different descendants to use what they need. In addition to keeping the controller-like behavior at the top of the hierarchy, and thus keeping our descendant views as functionally pure as possible, passing down the entire state of the store in a single object also has the effect of reducing the number of props we need to manage. Occasionally we may need to add additional controller-views deeper in the hierarchy to keep components simple.  This might help us to better encapsulate a section of the hierarchy related to a specific  data domain.  Be aware, however, that controller-views deeper in the hierarchy can violate the singular flow of data by introducing a new, potentially conflicting entry point for the data flow.  In making the decision of whether to add a deep controller-view, balance the gain of simpler components against the complexity of multiple data updates flowing into the hierarchy at different points.  These multiple data updates can lead to odd effects, with React's render method getting invoked repeatedly by updates from different controller-views, potentially increasing the difficulty of debugging. ### Actions The dispatcher exposes a method that allows a view to trigger a dispatch to the stores, and to include a payload of data, or an action. The action construction may be wrapped into a semantic helper method which sends the payload to the dispatcher. For example, we may want to change the text of a to-do item in a to-do list application. We would create an action with a function signature like `updateText(todoId, newText)` in our `TodoActions` module. This method may be invoked from within our views' event handlers, so we can call it in response to a user action. This action method also adds the action type to the payload, so that when the payload is interpreted in the store, it can respond appropriately to a payload with a particular action type. In our example, this type might be named something like `TODO_UPDATE_TEXT`. Actions may also come from other places, such as the server. This happens, for example, during data initialization. It may also happen when the server returns an error code or when the server has updates to provide to the application. We'll talk more about server actions in a future article. In this post we're only concerned with the basics of the data flow. ### What About that Dispatcher? As mentioned earlier, the dispatcher is also able to manage dependencies between stores. This functionality is available through the `waitFor()` method within the Dispatcher class.  We did not need to use this method within the extremely simple [TodoMVC application](https://github.com/facebook/flux/tree/master/examples/flux-todomvc), but we have included it [in the example dispatcher](https://github.com/facebook/flux/blob/master/examples/flux-todomvc/js/dispatcher/Dispatcher.js#L110) as an example of what a dispatcher should be able to do in a larger, more complex application. Within the TodoStore's registered callback we could explicitly wait for any dependencies to first update before moving forward: ```javascript case 'TODO_CREATE': Dispatcher.waitFor([ PrependedTextStore.dispatcherIndex, YetAnotherStore.dispatcherIndex ], function() { TodoStore.create(PrependedTextStore.getText() + ' ' + action.text); TodoStore.emit('change'); }); break; ``` The arguments for `waitFor()` are an array of dispatcher registry indexes, and a final callback to invoke after the callbacks at the given indexes have completed.  Thus the store that is invoking `waitFor()` can depend on the state of another store to inform how it should update its own state. A problem arises if we create circular dependencies. If Store A waits for Store B, and B waits for A, then we'll have a very bad situation on our hands. We'll need a more robust dispatcher that flags these circular dependencies with console errors, and this is not easily accomplished with promises. Unfortunately, that's a bit beyond the scope of this documentation. In the future we hope to cover how to build a more robust dispatcher and how to initialize, update, and save the state of the application with persistent data, like a web service API.   This page has been moved to the Flux website. [View it there](http://facebook.github.io/flux/docs/overview.html).


Question: }); }); <ins> it('does change the string ".98" to "0.98" with no change handler', () => { class Stub extends React.Component { state = { value: '.98', }; render() { return <input type="number" value={this.state.value} />; } } var stub = ReactTestUtils.renderIntoDocument(<Stub />); var node = ReactDOM.findDOMNode(stub); stub.setState({value: '0.98'}); expect(node.value).toEqual('0.98'); }); </ins> it('should display `defaultValue` of number 0', () => { var stub = <input type="text" defaultValue={0} />; stub = ReactTestUtils.renderIntoDocument(stub);

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:


Question: </span> {typeof overrideValueFn === 'function' ? ( <EditableValue <del> dataType={type} </del> <ins> initialValue={value} </ins> overrideValueFn={overrideValueFn} path={[]} <del> value={value} </del> /> ) : ( // $FlowFixMe Cannot create span element because in property children


Question: type EditableValueProps = {| className?: string, <del> dataType: string, </del> initialValue: any, overrideValueFn: OverrideValueFn, path: Array<string | number>,


Question: 'use strict'; var ReactChildren = require('ReactChildren'); <ins> var ReactDOMComponentTree = require('ReactDOMComponentTree'); </ins> var ReactDOMSelect = require('ReactDOMSelect'); var warning = require('warning');


Question: utils.catchup(openingElement.range[0], state, trimLeft); <del> if (nameObject.namespace) { throw new Error( 'Namespace tags are not supported. ReactJSX is not XML.'); </del> <ins> var isFallbackTag = false; if (nameObject.type === Syntax.XJSIdentifier) { if (nameObject.namespace) { throw new Error( 'Namespace tags are not supported. ReactJSX is not XML.'); } isFallbackTag = FALLBACK_TAGS.hasOwnProperty(nameObject.name); </ins> } <del> var isFallbackTag = FALLBACK_TAGS.hasOwnProperty(nameObject.name); utils.append( (isFallbackTag ? jsxObjIdent + '.' : '') + (nameObject.name) + '(', state ); </del> <ins> utils.append(isFallbackTag ? jsxObjIdent + '.' : '', state); utils.move(nameObject.range[0], state); utils.catchup(nameObject.range[1], state); </ins> <del> utils.move(nameObject.range[1], state); </del> <ins> utils.append('(', state); </ins> var hasAttributes = attributesObject.length;

:+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.


Question: return () => refCallback(null); } else if (ref !== null && ref !== undefined) { const refObject = ref; <ins> if (__DEV__) { warning( refObject.hasOwnProperty('current'), 'Expected useImperativeHandle() first argument to either be a ' + 'ref callback or React.createRef() object. Instead received: %s.', 'an object with keys {' + Object.keys(refObject).join(', ') + '}', ); } </ins> const inst = create(); refObject.current = inst; return () => {


Question: nextEffect = nextEffect.nextEffect; } <ins> if (__DEV__) { resetCurrentFiber(); } </ins> } function commitPassiveEffects(root: FiberRoot, firstEffect: Fiber): void {