Question: }, "preferGlobal": true, "commonerConfig": { <del> "version": 6 </del> <ins> "version": 7 </ins> }, "scripts": { "test": "jest",

Idea (that I'm pretty sure I saw elsewhere, react-native maybe?)… We should transform our calls to a conditional wrapping the call. We have to check the condition anyway and this would reduce the no-op function calls. In otherwords becomes Hell, we could replace the with and get rid of the function call entirely, though it really doesn't matter much since we're going to throw (plus we'd duplicate the default string). This might end up be a meaningless optimization…
I believe this is done intentionally (by hand) in some hotspots, so it would seem not. I guess one could argue if it might not make more sense to simply always use the inline style and drop the argument rather than adding another transform?
That's a tough sentence to parse. Are you saying we should always write the "optimized" form? If so I would say "no", the first is way easier to read as a human being.
do you consider something like since jsx has to be transformed anyways? invariant feels more like a contract to me and codes could be more readable if we separate the warning and real implementation, any thoughts?
We have complex invariants that aren't strictly about arguments so while that might be an option for some cases, it doesn't cover us.


Question: crossOrigin: null, data: null, // For `<object />` acts as `src`. dateTime: MUST_USE_ATTRIBUTE, <ins> default: HAS_BOOLEAN_VALUE, </ins> defer: HAS_BOOLEAN_VALUE, dir: null, disabled: MUST_USE_ATTRIBUTE | HAS_BOOLEAN_VALUE,

I'm trying to use Video element but some attributes doesn't work. from i'm trying to do: but it only renders to:
kind and srcLang were recently in They'll be a part of a future release (likely 0.14.1). I didn't see default then though so I guess we still need to add that.
Related to


Question: var dest = 'build/npm-react/'; var modSrc = 'build/modules/'; var lib = dest + 'lib/'; <ins> var dist = dest + 'dist/'; var distFiles = [ 'react.js', 'react.min.js', 'JSXTransformer.js', 'react-with-addons.js', 'react-with-addons.min.js' ]; </ins> function buildRelease() { // delete build/react-core for fresh start

It's nice to have prebuilt binaries available through the current package managers. Right now there's a prebuilt package for , but it'd be nice to also have them on npm / component / What do you think is the best way to create and maintain these packages? cc/
See also .
cc -- Not a blocker for 0.11, but it would be nice if could be merged.
By "binaries" do you actually mean prebuilt versions of React that you can just include on a web page? React doesn't really have binary components.
Yep, that's what I mean.
I'm using in a project and I would love to be able to include react that way. The last conversation about this ended in
We don't have plans to do this right now.


Question: <del> 'use strict'; var _extends = Object.assign || function(target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i]; for (var key in source) { if (Object.prototype.hasOwnProperty.call(source, key)) { target[key] = source[key]; } } } return target; }; /** * Copyright (c) 2013-present, Facebook, Inc. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @providesModule Circle.art * @typechecks * * Example usage: * <Circle *   radius={10} *   stroke="green" *   strokeWidth={3} *   fill="blue" * /> * */ var PropTypes = require('prop-types'); var React = require('react'); var ReactART = require('..'); var createReactClass = require('create-react-class'); var Path = ReactART.Path; var Shape = ReactART.Shape; /** * Circle is a React component for drawing circles. Like other ReactART * components, it must be used in a <Surface>. */ var Circle = createReactClass({ displayName: 'Circle', propTypes: { radius: PropTypes.number.isRequired, }, render: function render() { var radius = this.props.radius; var path = Path() .moveTo(0, -radius) .arc(0, radius * 2, radius) .arc(0, radius * -2, radius) .close(); return React.createElement(Shape, _extends({}, this.props, {d: path})); }, }); module.exports = Circle; </del>

It seems like those were intended to be public APIs () but they’re not published on npm because folder is not in the whitelist.


Question: props, resumableState, renderState, <del> !!(formatContext.tagScope & PICTURE_SCOPE), </del> <ins> !!(formatContext.tagScope & (PICTURE_SCOPE | NOSCRIPT_SCOPE)), </ins> ); } // Omitted close tags

<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React version: 18.3.0-canary-- SSR app that has images in its tree using renderToString or renderToPipeableStream <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: --! To not insert preloads randomly. Note that there is difference between renderToString and renderToPipeableStream, renderToString the preloads appear inside root and renderToPipeableStream they appear in head. Sorry this is a bit of a question rather than bug report maybe, I have searched around and cannot see any mention of auto-preloading images but I assume there must be something going on that I have missed. I was able to fix by using .
This. Tested with . It would be "kinda" tolerable for the LCP image above fold (featured image or similar), but we have lots of lazy loaded images below fold which contain <noscriptalternatives like: For every tag used in noscript, the image is preloaded in which completely defies the purpose of lazy loading.
I think this is actually now expected behaviour, after digging the source a bit I found Though I could not find any docs/release notes that mention this which is a little odd as now you need to explicitly think about the loading strategy of every img tag you use. For me I was able to "fix" this by making sure all our img tags have either loading=lazy or fetchPriority=low when they are not to be preloaded, this gave me more or less only the LCP images preloaded. For your case you could either add loading=lazy or fetchPriority=low to the fallback images, though depending on your target browsers you could get rid of the noscript parts these days as loading=lazy has pretty wide browser support now.

Would be good to have this documented somewhere and also maybe add this to the react linter.
Thanks for the info regarding loading=lazy, that could solve it. If this is really a "feature", I have to say, I don't think it should be React's business to put stuff into my automagically…
Which framework are you using?
For me, its Remix.
You're probably using their image component that uses . Or they're doing calls some other way. Can you open an issue on their issue tracker first to clarify?
I'm not using their image component but , but I will take a look at Remix & React Router code, whether they call this somewhere and open an issue. Interestingly, this behavior is only applied by Remix (or happens for some reason), when upgrading to React canary.
React is adding support for Suspensey "resource". For instance if you render a stylesheet and opt into React's handling of this using "precedence" then commits which contain this stylesheet will wait to commit until the sheet has loaded. Another area that we're making Suspensey is images. Lazy images indicate that they do not require suspense coordination but by default images will (in the future) block a boundary reveal until the image has loaded and been decoded. While these features are for client updates there are analogs for SSR. for stylesheets browsers already block paint until stylesheets load in the head. They don't however do this for images. React canaries now preload the first few images rendered if they are not lazy because we want to mimic the coordinated reveal of Suspensey images along with the first paint. It's not a perfect heuristic because it's not actually enforced to be coordinated but it does better align the behavior across suspensy vs lazy images. Another way you can signal to React that an image is not expected to be part of the first paint is to set the fetchPriority to "low"
For every <imgtag used in noscript, the image is preloaded in <headwhich completely defies the purpose of lazy loading. This is a genuine bug. will land a fix
Good to know, thanks for the explanation.
fwiw no framework used just renderToPipeableStream, in my case I was able to add low priority to a few icon images to get the preload to load reasonable candidates.

Would be good to be able to opt-out of this somehow for a boundary, thinking of the case where you are waiting on component/data to load and don't really care about the image but lazy loading would be inappropriate for an above the fold larger image. Maybe even a way to modify the heuristic via some sort of callback would be useful.


Question: path.pushContainer( 'body', t.expressionStatement( <del> t.callExpression(t.identifier('$RefreshReg$'), [ </del> <ins> t.callExpression(refreshReg, [ </ins> handle, t.stringLiteral(persistentID), ]),

Do you want to request a feature or report a bug? Feature Right now babel plugin emits globals: It would be nice to have them configurable. That would allow to use in environments like SystemJS and have simpler implementation: If you don't mind I could create PR with changes to react-refresh/babel next week. environment:
Happy to take a PR.


Question: expect(React.renderComponent.bind(React, instance, node)).toThrow(); }); <ins> it('should support checkedLink', function() { var container = document.createElement('div'); var link = new ReactLink(true, mocks.getMockFunction()); var instance = <input type="checkbox" checkedLink={link} />; React.renderComponent(instance, container); expect(instance.getDOMNode().checked).toBe(true); expect(link.value).toBe(true); expect(link.requestChange.mock.calls.length).toBe(0); instance.getDOMNode().checked = false; ReactTestUtils.Simulate.click(instance.getDOMNode()); expect(link.requestChange.mock.calls.length).toBe(1); expect(link.requestChange.mock.calls[0][0]).toEqual(false); }); it('should warn with checked and no onChange handler', function() { var oldWarn = console.warn; try { console.warn = mocks.getMockFunction(); var node = document.createElement('div'); var link = new ReactLink(true, mocks.getMockFunction()); React.renderComponent(<input type="checkbox" checkedLink={link} />, node); expect(console.warn.mock.calls.length).toBe(0); React.renderComponent( <input type="checkbox" checked="false" onChange={mocks.getMockFunction()} />, node ); expect(console.warn.mock.calls.length).toBe(0); React.renderComponent( <input type="checkbox" checked="false" readOnly={true} />, node ); expect(console.warn.mock.calls.length).toBe(0); React.renderComponent(<input type="checkbox" checked="false" />, node); expect(console.warn.mock.calls.length).toBe(1); React.renderComponent( <input type="checkbox" checked="false" readOnly={false} />, node ); expect(console.warn.mock.calls.length).toBe(2); } finally { console.warn = oldWarn; } }); it('should throw if both checked and checkedLink are provided', function() { // Silences console.error messages // ReactErrorUtils.guard is applied to all methods of a React component // and calls console.error in __DEV__ (true for test environment) spyOn(console, 'error'); var node = document.createElement('div'); var link = new ReactLink(true, mocks.getMockFunction()); var instance = <input type="checkbox" checkedLink={link} />; expect(React.renderComponent.bind(React, instance, node)).not.toThrow(); instance = <input type="checkbox" checkedLink={link} checked="false" />; expect(React.renderComponent.bind(React, instance, node)).toThrow(); instance = <input type="checkbox" checkedLink={link} onChange={emptyFunction} />; expect(React.renderComponent.bind(React, instance, node)).toThrow(); }); it('should throw if both checkedLink and valueLink are provided', function() { // Silences console.error messages // ReactErrorUtils.guard is applied to all methods of a React component // and calls console.error in __DEV__ (true for test environment) spyOn(console, 'error'); var node = document.createElement('div'); var link = new ReactLink(true, mocks.getMockFunction()); var instance = <input type="checkbox" checkedLink={link} />; expect(React.renderComponent.bind(React, instance, node)).not.toThrow(); instance = <input type="checkbox" valueLink={link} />; expect(React.renderComponent.bind(React, instance, node)).not.toThrow(); instance = <input type="checkbox" checkedLink={link} valueLink={emptyFunction} />; expect(React.renderComponent.bind(React, instance, node)).toThrow(); }); </ins> });

When using ReactLink with checkboxes or dropdowns, the state should not be bound to 'value', but to 'checked' and 'selected' instead.
I guess it's not obvious what the API should be here. I suppose the most obvious way is to do but keep as-is (and should still not work). Any opinions?
Either or change to do the same thing as ?


Question:
 --- layout: default sectionid: blog ---
 {% include nav_blog.html %}
 {% for page in site.posts %} {% include blog_post.html %} {% endfor %}

I am having an issue with text based inputs in React 0.14.3 and React DOM 0.14.3. When the event is fired for an input, the input will be deselected. Here is what this looks like in the UI: ! Here is an example of my components. There is a top-level component, which describes the fields on the form. This component also holds the state of the form and is the only component that extends . For each field in the form, there is a child component—which each has a and child. The form also has one component, which, when clicked, will fire an function with the state of the form. With the exception of , these components are all stateless functional components. The components are controlled. They get their value from the top level form component. The state is properly updated in this top level after the event is fired—as you would expect things to typically work with a controlled form. This state is then passed down via props to the input. I've been trying to figure out what could possibly be the cause of this weird deselection issue, but haven't made any progress... any ideas? Thanks.
This causes it: On every render the is a different random value. When the key is different, then React will not reuse the old component. So you lose focus because the input got replaced.
Ah, right, that would make sense. Bad mistake! Thanks.
as a key is definitely a bad idea
Haha, yes. I have long sense moved away from this solution.


Question: case topLevelTypes.topEnded: case topLevelTypes.topError: case topLevelTypes.topInput: <ins> case topLevelTypes.topInvalid: </ins> case topLevelTypes.topLoad: case topLevelTypes.topLoadedData: case topLevelTypes.topLoadedMetadata:

Ref:
I'm taking a look at this as a first bug - from the docs and some testing, the event seems to be fired at the form element level rather than the form itself. That is to say: will not log on submit, but: will log on submit. Does this match the expected behaviour, and if so do we want the handler to be on the individual React.DOM form elements (i.e. so it is called when that element is invalid), or do we want it to bubble up to the parent (i.e. so it is called whenever at least one element in that form is invalid)?
We should match the DOM and fire it on the element (not the form). We already have support for these events which don't bubble. Most of our events are at the document level and then delegated but the ones which don't bubble need to be to specific elements on creation. Here's how we're doing it for forms and the submit & reset events: Thanks for taking this on! Feel free to get a PR up before it's completely ready if you have questions / need help.
Thanks Paul, good to know I was looking in the right place! Will update when I have had time to create a PR or if I need any help :) Cheers Tom
Hey, I've put together a PR at - it would be great to get your feedback on it. A couple of specific questions I had: should I handle automated testing of this? There's a lot of test code to look at and I'm unfamiliar with the React codebase, so I'm unsure if/how this should be tested. the splitting out of the logic make sense? Or do you think it would be better to have a separate statement for this bit, preceeding the other in , matching all the elements which need this setup, and then keep the other as is (minus the first ) Any feedback appreciated, this does seem to work but I'm totally new to the React code so not sure if the way I've gone about it is suitable or not! Cheers, Tom
Awesome!


Question: 'use strict'; <del> var React = require('./build/React'); </del> <ins> var React = require('./build/react'); </ins> var visitors = require('./vendor/fbtransform/visitors').transformVisitors; var transform = require('./vendor/fbtransform/lib/transform').transform;

I'm trying to programatically invoke the JSX transformer (using the version of in the npm registry) by running something like Which then throws this error: If I comment out the lines in that require/use the module loads fine and the transformer runs correctly.
Bah, I changed build filenames last minute and didn't properly test the module after :( Thanks for finding this! I guess we should write some tests for the node module too, not just our phantomjs tests. (Very) Short term, you should be able to change to and that will fix the problem. - I guess it's time to figure out what we want to do with npm versions vs library versions. Should we just bump them both for the time being?
Nope, that alone won't do it, we're not even packaging. I totally screwed up the node module :( Fix soon!
Yeah, doesn't look like there's even a directory there. :)


Question: instance = ReactTestUtils.renderIntoDocument(instance); }).toThrow( 'Invariant Violation: mergeObjectsWithNoDuplicateKeys(): ' + <del> 'Tried to merge two objects with the same key: x' </del> <ins> 'Tried to merge two objects with the same key: `x`. This conflict ' + 'may be due to a mixin; in particular, this may be caused by two ' + 'getInitialState() or getDefaultProps() methods returning objects ' + 'with clashing keys.' </ins> ); });

Understandably general given that this is used to merge a couple things, but the actual use case is when or (or but shh) is used in a mixin and the component and both return an object with the same key. We should make this error mention something about those methods so people have an idea of where to look instead of them coming to IRC and being (rightfully) confused.


Question: // `textContent` (unnecessary since we update value). // The initial value can be a boolean or object so that's why it's // forced to be a string. <del> initialValue: '' + (value != null ? value : defaultValue), value: defaultValue </del> <ins> initialValue: '' + (value != null ? value : defaultValue) </ins> }; },

creates invalid html markup and appears to be unnecessary for proper functionality of the . Admittedly my test here was very minimal, but removing from the object using rendered valid html and the component still worked properly in the browser and passed all it's tests. Other than perhaps supporting server-side rendering, is there a purpose to rendering into the real dom?
Good catch :+1: The reason is set is because is , i.e, it's treated as a property rather than an attribute at run-time (which is correct). But like you say, it should not generate markup for the attribute (because it's wrong). I'm not 100% sure what the preferred fix is here, add another "directive" ex: ?
I don't think it's invalid markup. just isn't used (unless you use , which we don't do for ). I was surprised that just deleting value would work, but I guess we're applying updates to value of the actual node manually, not relying on render. This seems like a good enough approach to me. We already render the initial value as a text child so we don't use this for server rendering. another directive could make sense if we get scoped properties in there since this is only true for <textareabut not for other inputs. But until then... Want to submit a PR (cc
By invalid I meant the generated markup will not validate via the W3C html validator, throwing the error "Attribute value not allowed on element textarea at this point." Yes, I will submit a PR.


Question: if (type && type.defaultProps) { var defaultProps = type.defaultProps; for (propName in defaultProps) { <del> if (typeof props[propName] === 'undefined') { </del> <ins> if (props[propName] === undefined) { </ins> props[propName] = defaultProps[propName]; } }

Introduction I found a bug on resolving default props when component props have property with HTMLAllCollection. React ignores value and uses default value (it should take that collection). isIE9OrLower (look at the end of topic) is simple function to test Internet Explorer in version 9 or lower. Simple use case: Chrome/Firefox/modern IE (yeah, i know....) returns HTMLAllColection (as ), but old IE returns true. HTMLAllCollection is weird collection: Source of bug and fix release: 0.14.7 file: line: 9149 code (bug): if (typeof props[propName] === 'undefined') { code (fix): if (props[propName] === undefined) { Btw, === undefined is faster than typeof === 'undefined' on Chrome and IE. Reproduction Open in Firefox / Chrome / IE10 or higher. Fiddle: Raw: Workaround Change to
Haha, browsers suck. Want to submit a PR? It looks like we do that thing unnecessarily in a few places in the React codebase. Note that we do need to use typeof if the binding might not exist, so we need to look at each case individually to make sure the change is valid there.
I went through the react repo configuration (build, tests execution). Fix didn't break anything, but so far I didn't find solution to make good test (phantomjs doesn't have property). (HTMLAllCollection) is probably the only exception to the typeof and is not a html standard. Any suggestions to the unit test for this fix/improvement?
As long as you tested it manually and it worked in IE, I think we can accept this change without a unit test.
Fixed in
lol what even
I can't reproduce being in IE 8 or IE 9 on Windows 7, either in standards or quirks mode. What am I missing?
IE < 10 is fine. Problem occurs when using modern browser like Chrome, Firefox, IE = 10 or Edge. They returns . component prop as in Chrome. will compare your prop with default prop (which is ). on Chrome is so React treats it as missing value. Default prop () will be selected. the end, prop will be always set to on modern browser in this case.
Oh! Sorry I totally misread. Yes I can repro this.


Question: pkgData.name = pkgName; grunt.file.mkdir(destDir); <ins> var link = info.docs ? info.docs : 'addons'; link = `https://facebook.github.io/react/docs/${link}.html`; </ins> fs.writeFileSync(path.join(destDir, 'index.js'), generateSource(info)); fs.writeFileSync(path.join(destDir, 'package.json'), JSON.stringify(pkgData, null, 2)); fs.writeFileSync(path.join(destDir, 'LICENSE'), license); fs.writeFileSync(path.join(destDir, 'PATENTS'), patents); fs.writeFileSync( path.join(destDir, 'README.md'), <del> '# ' + pkgName + 'nn' + 'This package provides the React ' + k + ' add-on. See ' + 'http://facebook.github.io/react/docs/addons.html for more information.n' </del> <ins> ` # ${pkgName} This package provides the React ${k} add-on. See <${link}> for more information.`.slice(1) </ins> ); });

Follow-up for : The react-addons-* packages should have a entry in their files.


Question: Like all DOM events, the `onChange` prop is supported on all native components and can be used to listen to bubbled change events. <ins> > Note: > > For `<input>` and `<textarea>`, `onChange` supersedes — and should generally be used instead of — the DOM's built-in [`oninput`](https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/oninput) event handler. </ins> ## Controlled Components

It would be nice for the to be more explicit about the fact that React's supersedes, and should generally be used in place of, the DOM's built-in event. People might be used to using instead for text inputs and textareas, since, with the raw DOM, the change event for these controls doesn't fire until the control loses focus.
Opened a PR to address this:
Merged, hurray, we can close this now! :tada:
wait but why?
I don't understand why React chose to make behave like does. As fas as I can tell, we have no way of getting the old behaviour back. Docs claim it's a "misnomer" but it isn't really, it does fire when there's a change, just not until the input also loses focus. For validation, sometimes we don't want to show validation errors until they're done typing. Or maybe we just don't want a re-render on every keystroke. Now the only way to do that is with onBlur but now we also need to check that the value has changed manually. It's not that big of a deal, but it seems to me like React threw away a useful event and deviated from standard behaviour when there was already an event that does this.
Agree with mnpenner. With fireing on every keystroke, my redux store changes simultaneously. To avoid that, I have to use . Finally, we have two events - and - which work same manner.
Besides there is no easy workaround to replicate such behaviour for the element. Native events behave such way that moving the slider around triggers an event and releasing it triggers .
Another note: Autofill events (at least on Chrome/OSX) trigger , but not ! So if I want to capture a change event to an input that might be filled using Chrome's autofill feature, I need to bind to both (to detect keystrokes and autofill) and (to placate React [1]). [1]
for validation messages or things that you want to wait until they stop typing for use debounce in your event handler instead of waiting until onBlur.
Still no way of using onChange? I've been writing lots of logic to get around not having a real change event. I think to be a better abstraction, React needs to stick to onChange and let us use onInput without a silly warning. Validation has never been this hard.

For better or worse, this has been the behavior for quite a while, and many React users rely on it. IMHO, it's probably too late in the game to totally change what "onChange" means in React. But if you feel strongly, maybe do a quick PR to propose a solution with a sensible upgrade path? (Before spending a lot of time on it, get the thoughts of the core team.)
Right I've suggested instead to create a new event and minimise breaking changes.
Definitely a huge design issue with React. Hope it doesn't stay this way forever
This is a mistake or a feature :/
Features are supposed to be useful... this is the opposite of useful.
For anyone who needs a workaround to get true onChange behavior, you can implement your own component to use HTML's built-in event. Here's how I've done it, inspired by . Kaspar's allows you to use both onchange and oninput, mine is just for onchange.
Looks like there is an official answer now:
I don't think that's new. See
It is really aggravating, this "official answer". How presumptuous of them to call the HTML Spec official and consolidated event name a "misnomer".
2024 and issue still exists, this one wasted a serious chunk of time, atleast I now have an answer but if I didnt trust facebook before I sure dont trust them now. Always follow the spec, there should be no alternative breaking change or not.
Guys for people looking to do it with functions, expanding on Ettar solution, this seems to be working (here I am using MUI component, but input component works as well):


Question: * * @param {string} name CSS property name such as `topMargin`. * @param {*} value CSS property value such as `10px`. <ins> * @param {ReactDOMComponent} component </ins> * @return {string} Normalized style value with dimensions applied. */ <del> function dangerousStyleValue(name, value) { </del> <ins> function dangerousStyleValue(name, value, component) { </ins> // Note that we've removed escapeTextForBrowser() calls here since the // whole string will be escaped when the attribute is injected into // the markup. If you provide unsafe user data here they can inject

It's weird that gets turned into . I think we should only add if the value is an actual number.
I'll just chime in with what I mentioned in the chat last time, I think it's a great solution. Just as means you're providing a raw CSS-string, would mean you're providing a raw CSS-string. So it makes sense logically. However, and suddenly has two very different outcomes if the component passes the value as-is to the style-object. I see no intuitive way out of this, sure enforcing numbers as is technically the right solution, but it's not obvious to new users (document it thoroughly) and it's potentially error prone for a user base accustomed to HTML (especially designers I would assume). I don't mind making the only right way, but to me it seems like there's no way to enforce it at run-time without which is a developer burden, and as I've understood it, an entirely optional feature in your eyes. So it seems kind of fragile.
Note: this isn't actually fixed, just have a warning in place.
Yep, was autoclosed by the PR.
should we add a version in the warning message to this behavior be removed?
So just to clarify, is passing a number value as string type the only thing that will no longer have appended to it? Will passing a plain number a la still be supported, or is there also an intent to remove that as well?
As I understood, only string type. The example you gave, will still be supported.
we still have this warning in place, should we consider acting on for 16 or wait until 17?
Too late for breaking changes for 16, let's look at doing it in 17. Can probably land soon after the release behind a flag.
Hmm. I neither see a warning, nor do I see it apply the style. I think this was fixed in 16.


Question: render: function() { return ( <div> <del> <ReactCSSTransitionGroup transitionName="carousel"> </del> <ins> <ReactCSSTransitionGroup transitionName="carousel" transitionEnterTimeout={300} transitionLeaveTimeout={300}> </ins> <img src={this.props.imageSrc} key={this.props.imageSrc} /> </ReactCSSTransitionGroup> </div>

When a is used without timeout props, it : for each missing timeout prop. However, that URL simply points to . The code listed there does use timeout props, but nothing on the page explains what those props do or why they're necessary. In fact, the word "timeout" only appears in the names of those props in code examples. Could we get some explanation in the docs, please?
Hmm, I think it does: <img width="516" alt="screen shot 2016-07-20 at 15 23 18" src=""Some line breaks would help there. There is an entry explaining why they were in 0.14 release notes: <img width="717" alt="screen shot 2016-07-20 at 15 24 12" src=""(I’m not saying it’s easy to find—it’s out fault for not updating the docs to reflect that.) Would you like to massage the doc page and send a PR?
Ah, got it. Yeah, knowing how it works now, I can do that. Thanks!
Can transitionAppearTimeout replace transitionLeaveTimeout?? If i am using animation for initial mount because i am still getting error with .... In facebook docs they replaced LeaveTimetout with AppearTimeout... but it looks like there still must be LeaveTimeout..


Question: } // Resolve default props <del> if (type.defaultProps) { </del> <ins> if (type && type.defaultProps) { </ins> var defaultProps = type.defaultProps; for (propName in defaultProps) { if (typeof props[propName] === 'undefined') {

I spent the last hour trying to fix an issue that was caused by me trying to render a when the actual variable was undefined. The root cause was me misinterpreting that would return the whole instead of just (which is my bad), but the error itself and the stack trace were extremely cryptic and it took me a while to even get a clue that the reason why it wasn't working was that I was just trying to render an undefined type. This is the actual exception: And here's the stack trace: ! You can see that, ultimately, execution comes crashing down when React tries to look at on my undefined type, which of course raises an exception. The reason why this was confusing to me is that the exception happened quite far away from the source cause and, as a secondary factor, this code worked completely fine before I started porting it to Browserify and made my mistake with . This lead me to a wild set of hypotheses as to why it wasn't working, such as assuming it might be due to a regression in React 0.12 (since it's been migrating from to and I thought might have been lagging behind), to thinking it could be a problem with itself. The reason why I raise this issue is that, since passing an type won't work anyway, it would make sense if React could check for and warn about it or maybe even raise an exception (since it would crash soon after anyway). My instance was a bit more extreme and if something like this happens to someone else they'll probably know where they screwed up in the first place, but some help from React would always be welcome!
Actually returns the whole react lib + the addons. The addons are just to the object you'd get if you did . I've been using browserify the whole time and this error just came up, after updating to 0.12.1. It was working fine before, so it seems kind of weird that it's throwing an error right now. If a dev could comment on this, that'd be great.
Yea, seems like it wouldn't be a bad idea to have a check in createElement. What was working fine before? createElement didn't really exist (it was in 0.11.x but would likely not have been used). And react/addons has always been the full React object with addons inserted.
Talked it through with on IRC, same cause just not via addons.

An undefined component was being used.
Yeah, I became aware of that when I figured out what the issue is, I was just thinking it would have been way more helpful if React had told me straight away that I was passing an undefined component to .
+1, I also had this issue (albeit for a different reason)
Thanks! :+1:
If you are giving the whole JSX code under the script tag of the HTML page, then the order of declaration of the components could cause this issue. When the inbuilt compiler sees a component which you've later declared in the code, it'll throw an error. However in plain terms, this just means that the component is missing.
Getting this Uncaught TypeError: Cannot read property 'createElement' of undefined Any solutions
Please ask on StackOverflow; this is hard to answer without seeing your complete code.
here is my code ...
is incorrect, should be There is no named export named . It is confusing because React is a CommonJS module, and since you’re using ES6 imports, Babel tries to map the semantics but they don’t match exactly. actually grabs from itself so you might just and use instead if it’s less confusing.
Woah, thank you for a nice clarification.


Question: scryRenderedDOMComponentsWithTag: function(root, tagName) { return ReactTestUtils.findAllInRenderedTree(root, function(inst) { return ReactTestUtils.isDOMComponent(inst) && <del> inst.tagName === tagName.toUpperCase(); </del> <ins> inst.tagName.toUpperCase() === tagName.toUpperCase(); </ins> }); },

After migrating from 0.13 to 0.14-beta1, some of our unit tests are reporting false positive failures. It seems as though is no longer able to find elements inside components.
Isn't findRenderedDOMComponentWithTag's first argument supposed to be the name of the react component tree that you've defined (MyElement)?
Oops. That was a typo in my code sample. I've corrected it.
The problem was that was passed as a lowerCase string to . Converting it to upperCase before hand doesn't hurt anyway. What do you guys think?


Question: <ins> /** * Copyright 2013-present, 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. * * @providesModule DisabledInputUtils */ 'use strict'; var disableableMouseListenerNames = { onClick: true, onDoubleClick: true, onMouseDown: true, onMouseMove: true, onMouseUp: true, onClickCapture: true, onDoubleClickCapture: true, onMouseDownCapture: true, onMouseMoveCapture: true, onMouseUpCapture: true, }; /** * Implements a native component that does not receive mouse events * when `disabled` is set. */ var DisabledInputUtils = { getNativeProps: function(inst, props) { if (!props.disabled) { return props; } // Copy the props, except the mouse listeners var nativeProps = {}; for (var key in props) { if (!disableableMouseListenerNames[key] && props.hasOwnProperty(key)) { nativeProps[key] = props[key]; } } return nativeProps; }, }; module.exports = DisabledInputUtils; </ins>

The same in Chrome 35.0.1916.153. It's OK in Chrome Canary 38.0.2082.0 canary (64-bit).
This is actually an - we've the workarounds to make sure disabled s actually behave correctly here. This holds for all disabled inputs it seems.


Question: isIdleScheduled = false; var callback = scheduledRICCallback; scheduledRICCallback = null; <del> if (callback) { </del> <ins> if (callback !== null) { </ins> callback(frameDeadlineObject); } };

We don't use rAF for scheduling anything anymore, yet we still enable it in ReactDOMFrameScheduling. It can probably be simplified a bit by not exposing it.


Question: var invariant = require('invariant'); var isEventSupported = require('isEventSupported'); var keyOf = require('keyOf'); <ins> var shallowEqual = require('shallowEqual'); </ins> var validateDOMNesting = require('validateDOMNesting'); var warning = require('warning');

Right now, we copy it in one of the hottest paths of React to allow users to mutate the style object afterward. I've come to realize that this pattern doesn't come up that often, since the style's often created inline inside and not retained after that. Additionally, is coming soon, so people could always clone the style themselves if there's the need.
You could start with a dev-only warning() if you're concerned about breaking stuff.
Would be extremely nice, especially since we're going to make a push to get more people to use inline styles in the future
Really? From my tests, it would seem that it would be a performance nightmare.
it's certainly nice if it was possible. I think there are some tricks to make this performant enough.


Question: <!-- TODO: Document mixins here directly. --> <ins> ### displayName ```javascript string displayName ``` The `displayName` string is used in debugging messages. JSX sets this value automatically, see [JSX in Depth](react/docs/jsx-in-depth.html#react-composite-components). </ins> ## Lifecycle Methods Various methods are executed at specific points in a component's lifecycle.

I couldn't find a reference to the fact that jsx transform attaches to the component spec, this would be nice to document somewhere (more importantly, that not using jsx means debugging messages will be littered with ). I found this while using .
That would be very nice indeed. If you want to take a stab at it, the docs are in the repo in the markdown format. Would love to have you on the contributor list :)


Question: ); if (__DEV__) { const inst = workInProgress.stateNode; <del> if (inst.props !== nextProps) { </del> <ins> if (shouldUpdate && inst.props !== nextProps) { </ins> if (!didWarnAboutReassigningProps) { console.error( 'It looks like %s is reassigning its own `this.props` while rendering. ' +

<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . 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: What is the expected behavior? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
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!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is


Question: <ins> function Component({ value }) { const object = { get value() { return value; }, }; return <div>{object.value}</div>; } export const FIXTURE_ENTRYPOINT = { fn: foo, params: [{ value: 0 }], sequentialRenders: [{ value: 1 }, { value: 2 }], }; </ins>

[ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization) [X] babel-plugin-react-compiler (build issue installing or using the Babel plugin) [ ] eslint-plugin-react-compiler (build issue installing or using the eslint plugin) [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script) In the above code, doubleValue uses get syntax, and after compilation, it loses the keyword and becomes an ordinary function. In this case the compiler should skip compilation until this syntax is supported. I know that some syntaxes are currently unsupported by the react compiler, can we know what syntaxes are currently unsupported and in process? Every time 0-rc--
Thanks for posting, this is a bug. We have not support for get/set syntax but looks like we missed a todo for this.
Let’s close when the associated PR lands
Oops my bad, I didn't read


Question: 'use strict'; <del> import ExecutionEnvironment from 'fbjs/lib/ExecutionEnvironment'; import warning from 'fbjs/lib/warning'; </del> // We capture a local reference to any global, in case it gets polyfilled after // this module is initially evaluated. // We want to be using a consistent implementation. <del> const localRequestAnimationFrame = requestAnimationFrame; </del> <ins> const localRequestAnimationFrame = typeof requestAnimationFrame === 'function' ? requestAnimationFrame : undefined; </ins> <del> if (__DEV__) { if ( ExecutionEnvironment.canUseDOM && typeof localRequestAnimationFrame !== 'function' ) { warning( false, 'React depends on requestAnimationFrame. Make sure that you load a ' + 'polyfill in older browsers. https://fb.me/react-polyfills', ); } } </del> <ins> // The callsites should check if the requestAnimationFrame imported from this module is a function, // fire a developer warning if it doesn't exist, and substitute it by a shim in that case // (e.g. that throws on call). </ins> export default localRequestAnimationFrame;

<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? bug What is the current behavior? <!-- 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: --The change seems to have broken the server-side rendering on : I'm attempting to the to test and getting the following error from the server-side when I load the page: It points to this line: What is the expected behavior? No ReferenceError in server-side environment. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? (not published at the time of writing) Node environment: during server-side rendering in response to a browser request.
fixed in


Question: var getDebugConfig = function() { return { "debug": true, <ins> "commonerConfig": grunt.config.data.pkg.commonerConfig, </ins> "constants": { "__VERSION__": grunt.config.data.pkg.version, "__DEV__": true

I'd rather do it , if you don't mind.
I think we should do both. I think a forced clean should force clean all of the build artifacts (of which .module-cache is a part of).
can we distinguish between and ?
In what situation would you want to clean but not remove ?
I'm actually not aware of any other use cases for so maybe this is fine. But it still means we need to tell people to do if they encounter problems that might be fixed by doing so, whereas gives us a way to get the same effect with no verbal communication.
I'm going to do it. I think we should probably also do .
Closed by .


Question: // Never dehydrate the "hooks" object at the top levels. return true; } <ins> if ( path[path.length - 2] === 'hookSource' && path[path.length - 1] === 'fileName' ) { // It's important to preserve the full file name (URL) for hook sources // in case the user has enabled the named hooks feature. // Otherwise the frontend may end up with a partial URL which it can't load. return true; } </ins> if ( path[path.length - 1] === 'subHooks' || path[path.length - 2] === 'subHooks'

This can cause long file names (URLs) to be truncated which in turn will break named hooks code (since it needs to load those file names).


Question: installHook(window); export type StatusListener = (message: string) => void; <ins> export type OnDisconnectedCallback = () => void; </ins> let node: HTMLElement = ((null: any): HTMLElement); let nodeWaitingToConnectHTML: string = ''; let projectRoots: Array<string> = []; let statusListener: StatusListener = (message: string) => {}; <ins> let disconnectedCallback: OnDisconnectedCallback = () => {}; </ins> // TODO (Webpack 5) Hopefully we can remove this prop after the Webpack 5 migration. function hookNamesModuleLoaderFunction() {

Any client that connects to the standalone DevTools While using the standalone DevTools app: a client to the DevTools that client and you should be redirected to the introduction page The event listeners are not re-attached to the splash page elements after the client disconnects. The <scripttags that can be copied on click and the "Profiler tab" link stop working. Every time No response No response No response No response No response No response
I was thinking about two ways to fix this issue: set a MutationObserver to re-attach the listeners when the contents of the root node are changed, or add a callback to the DevToolsUI in the core of the standalone version and re-attach the listeners on that callback.
Nice find! If you'd be interested in submitting a proposal (PR) I'd be happy to review and discuss.
Sure thing, will do!


Question: return map; } <del> function isValidUrl(possibleURL: string): boolean { try { // eslint-disable-next-line no-new new URL(possibleURL); } catch (_) { return false; } return true; } </del> function loadSourceFiles( locationKeyToHookSourceData: Map<string, HookSourceData>, ): Promise<*> {

This can cause long file names (URLs) to be truncated which in turn will break named hooks code (since it needs to load those file names).


Question: Component.displayName || Component.name || 'Component' ); } <ins> var propsMutated = inst.props !== publicProps; var componentName = Component.displayName || Component.name || 'Component'; warning( typeof inst.props === 'undefined' || !propsMutated, '%s(...): When calling super() in `%s`, make sure to pass ' + 'up the same props that your component's constructor was passed.', componentName, componentName ); </ins> } // These should be set up in the constructor, but as a convenience for

Having the constructor passing super a props object that differs (in object equality and/or shallow compare) from the original is... illegal, because: We should have a warning for that, because it's reasonable for someone to assume they could extend a component and modify the props, without considering the ramifications, and the bug won't show up in their initial render test but will show up when the component updates.
Can a shallow comparison of and suffice, or is a deep equality check between the two objects needed?
I think shallow is fine. Deep equality is too difficult/expensive because of cycles. Note that we should only do the check in dev mode, so surround your logic with a block


Question: expect(stubStyle.color).toEqual(''); }); <ins> // trouble </ins> it("should update styles when 'style' changes from null to object", function() { var container = document.createElement('div'); var styles = {color: 'red'};

Right now, we copy it in one of the hottest paths of React to allow users to mutate the style object afterward. I've come to realize that this pattern doesn't come up that often, since the style's often created inline inside and not retained after that. Additionally, is coming soon, so people could always clone the style themselves if there's the need.
You could start with a dev-only warning() if you're concerned about breaking stuff.
Would be extremely nice, especially since we're going to make a push to get more people to use inline styles in the future
Really? From my tests, it would seem that it would be a performance nightmare.
it's certainly nice if it was possible. I think there are some tricks to make this performant enough.


Question: "manifest_version": 3, "name": "React Developer Tools", "description": "Adds React debugging tools to the Microsoft Edge Developer Tools.", <del> "version": "4.27.7", "version_name": "4.27.7", </del> <ins> "version": "4.27.8", "version_name": "4.27.8", </ins> "minimum_chrome_version": "102", "icons": { "16": "icons/16-production.png",

local repo Loading a React component with the React profiler recording enabled Every time react-devtools-extensions 27.6- Cannot add node "1751" because a node with that id is already in the Store. No response
! Same issue here. Devtools version: 4.27.6 (4/20/2023)
Same issue here. Using NextJS 13.4.1 !
Same issue here. Happens, when adding Canvas element. version 8.13.0 <img width="682" alt="Снимок экрана 2023-05-10 в 22 31 40" src=""
Same issue: !
same... do you all have code for a chrome extension?
same with devtools version: 4.27.7 (5/7/2023) !
I've installed a React profiler via Chrome web store () which created a second copy of an extension under "From other sources" title in extensions panel, after that I've deleted a copy of an react dev tools that was 'native' to edge, and voila, profiler works.
Hey folks, the only reproducible example I've found is mentioned in I've merged a fix for it, but need more input from you: you are constantly facing this issue, can you post here a repro please? you please follow and try to reproduce this error again?
I am no longer seeing this error after installing the release you linked in .
Great, thank you! This fix will be included in v4.27.8 release, which I will publish this week.


Question: // Proceed under the assumption that this is a function component workInProgress.tag = FunctionComponent; value = finishHooks(Component, props, value, context); <ins> reconcileChildren(null, workInProgress, value, renderExpirationTime); </ins> if (__DEV__) { <del> if (Component) { warningWithoutStack( !Component.childContextTypes, '%s(...): childContextTypes cannot be defined on a function component.', Component.displayName || Component.name || 'Component', ); } if (workInProgress.ref !== null) { let info = ''; const ownerName = ReactCurrentFiber.getCurrentFiberOwnerNameInDevOrNull(); if (ownerName) { info += 'nnCheck the render method of `' + ownerName + '`.'; } </del> <ins> validateFunctionComponentInDev(workInProgress, Component); } return workInProgress.child; } } </ins> <del> let warningKey = ownerName || workInProgress._debugID || ''; const debugSource = workInProgress._debugSource; if (debugSource) { warningKey = debugSource.fileName + ':' + debugSource.lineNumber; } if (!didWarnAboutFunctionRefs[warningKey]) { didWarnAboutFunctionRefs[warningKey] = true; warning( false, 'Function components cannot be given refs. ' + 'Attempts to access this ref will fail.%s', info, ); } } </del> <ins> function validateFunctionComponentInDev(workInProgress: Fiber, Component: any) { if (Component) { warningWithoutStack( !Component.childContextTypes, '%s(...): childContextTypes cannot be defined on a function component.', Component.displayName || Component.name || 'Component', ); } if (workInProgress.ref !== null) { let info = ''; const ownerName = ReactCurrentFiber.getCurrentFiberOwnerNameInDevOrNull(); if (ownerName) { info += 'nnCheck the render method of `' + ownerName + '`.'; } let warningKey = ownerName || workInProgress._debugID || ''; const debugSource = workInProgress._debugSource; if (debugSource) { warningKey = debugSource.fileName + ':' + debugSource.lineNumber; } if (!didWarnAboutFunctionRefs[warningKey]) { didWarnAboutFunctionRefs[warningKey] = true; warning( false, 'Function components cannot be given refs. ' + 'Attempts to access this ref will fail.%s', info, ); } } </ins> <del> if (typeof Component.getDerivedStateFromProps === 'function') { const componentName = getComponentName(Component) || 'Unknown'; </del> <ins> if (typeof Component.getDerivedStateFromProps === 'function') { const componentName = getComponentName(Component) || 'Unknown'; </ins> <del> if (!didWarnAboutGetDerivedStateOnFunctionComponent[componentName]) { warningWithoutStack( false, '%s: Function components do not support getDerivedStateFromProps.', componentName, ); didWarnAboutGetDerivedStateOnFunctionComponent[componentName] = true; } } </del> <ins> if (!didWarnAboutGetDerivedStateOnFunctionComponent[componentName]) { warningWithoutStack( false, '%s: Function components do not support getDerivedStateFromProps.', componentName, ); didWarnAboutGetDerivedStateOnFunctionComponent[componentName] = true; } } </ins> <del> if ( typeof Component.contextType === 'object' && Component.contextType !== null ) { const componentName = getComponentName(Component) || 'Unknown'; </del> <ins> if ( typeof Component.contextType === 'object' && Component.contextType !== null ) { const componentName = getComponentName(Component) || 'Unknown'; </ins> <del> if (!didWarnAboutContextTypeOnFunctionComponent[componentName]) { warningWithoutStack( false, '%s: Function components do not support contextType.', componentName, ); didWarnAboutContextTypeOnFunctionComponent[componentName] = true; } } </del> <ins> if (!didWarnAboutContextTypeOnFunctionComponent[componentName]) { warningWithoutStack( false, '%s: Function components do not support contextType.', componentName, ); didWarnAboutContextTypeOnFunctionComponent[componentName] = true; </ins> } <del> reconcileChildren(null, workInProgress, value, renderExpirationTime); return workInProgress.child; </del> } }

<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Attempting to assign a ref to a component wrapped in does not produce a friendly error message. Attempting the same thing with a functional component not wrapped in memo gives a descriptive error ("Warning: Function components cannot be given refs. Attempts to access this ref will fail."). 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: I trust this is not needed for this case What is the expected behavior? The same error message as with a non-memo functional component should be displayed. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? 0


Question: integrity sha512-zIURGIS1E1Q4pcrMjp+nnEh+16G56eG/MUllJH8yEvw7asDo7Ac9uhC9KIH5jzpITueEZolfYglnCGIuSBz39g== axios@^1.6.1: <del> version "1.7.1" resolved "https://registry.yarnpkg.com/axios/-/axios-1.7.1.tgz#522145622a09dfaf49359837db9649ff245a35b9" integrity sha512-+LV37nQcd1EpFalkXksWNBiA17NZ5m5/WspmHGmZmdx1qBOg/VNq/c4eRJiA9VQQHBOs+N0ZhhdU10h2TyNK7Q== </del> <ins> version "1.7.4" resolved "https://registry.yarnpkg.com/axios/-/axios-1.7.4.tgz#4c8ded1b43683c8dd362973c393f3ede24052aa2" integrity sha512-DukmaFRnY6AzAALSH4J2M3k6PkaC+MfaAGdEERRWcC9q3/TWQwLpHR8ZRLKTdQ3aBDL64EdluRDjJqKw+BPZEw== </ins> dependencies: follow-redirects "^1.15.6" form-data "^4.0.0"

Now that react-python is being completely deprecated and will probably cease to function soon with new versions of react ( ) the docs should probably no longer link to it from the Use React and JSX in Python Applications page.
For those following along, I assume is referring to It's an old blog post (with a date), not part of the living docs. We generally don't go back in time and update old posts because things are constantly changing over time and it's hard enough to just keep the main documentation up-to-date. If someone wants to add a red note box that says "Update: PyReact is now deprecated", I think I would be ok with that and we would likely accept such a PR. cc because he feels the strongest about updating historical posts. Anyway, I'm going to close this out to take it off our radar, because we don't generally track/update historical posts.
Meh, If somebody did want to add a note like that, that would be fine. But I don't think we need to change the content of the post. And linking to the actual project is probably good because it has a nice big deprecated notice in the readme.
Ah, I actually hadn't noticed that it's a blog post. It's the thing that comes up when you google "react python" (or anything similar) and is formatted the same as the rest of React's documentation. But yeah, it seems like a shame to have to keep every old blog post up to date. (I suppose after JSXTransformer becomes completely nonfunctional it might be worth making PyReact's deprecation notice a bit stronger, but at this point it's really just nitpicking)


Question: five: true }); }); <ins> it('should support mergeKeySets with undefined input', function () { var prev = { one: true, two: true }; var next = undefined; expect(ReactTransitionKeySet.mergeKeySets(prev, next)).toEqual({ one: true, two: true }); prev = undefined; next = { three: true, four: true }; expect(ReactTransitionKeySet.mergeKeySets(prev, next)).toEqual({ three: true, four: true }); }); </ins> });

Consider this example: If is false or undefined, will be and will throw
Want to take a go at fixing this? I think it would be a good opportunity to learn a bit more about a constrained subset of internals.
yea - i'll give it a shot :)


Question: } } <ins> function stripComplexValues(key, value) { if (typeof value !== 'object' || Array.isArray(value) || value == null) { return value; } var prototype = Object.getPrototypeOf(value); if (!prototype || prototype === Object.prototype) { return value; } return '<not serializable>'; } </ins> // This implementation of ReactPerf is going away some time mid 15.x. // While we plan to keep most of the API, the actual format of measurements // will change dramatically. To signal this, we wrap them into an opaque-ish

Identical app. I call after the app is loaded. React 0.14.7: <img width="622" alt="screen shot 2016-03-17 at 20 31 56" src=""React 15.0 RC1, RC2 and master: <img width="635" alt="screen shot 2016-03-17 at 20 34 02" src=""We should fix this before releasing 15.0.
There seem to be two distinct things causing this issue: is now a possible argument for and points to DOM nodes which now have a hidden field which points to the component instances which point to .. DOM nodes, I guess. now accepts a argument for a better warning which pulls component instances into the which in turn pull nodes which in turn pull components.


Question: var runScripts; var loadScripts; var headEl; <ins> var dummyAnchor; </ins> var buffer = require('buffer'); var transform = require('jstransform').transform;

It was reported to me on IRC today and confirmed on master / FF nightly myself. Also
I should add that when there are no errors in the jsx file the page still renders correctly, but the behavior persists (cannot load source file). Errors are reported from lines that do not exist in html file which makes bugs hard to track down. Confirmed on Windows 7 and Firefox 29. I can add more details once I get back to work on Monday - just let me know what information you need. Thanks, -Eric
What exactly is the issue? If it's just source lines being "off/out of bounds" then it's possible that it's the old JSX issue where source lines reported by esprima are mysteriously offset. AFAIK it was never explicitly solved, but no one was able to reproduce it anymore, perhaps it struck again? Other than that, JSX is just sugar on-top of esprima (and source-map I assume), and I think even the above issue is/was, so I don't think JSX is necessarily the root cause here.
Hi thanks for responding. At the most general level, the problem I am trying to solve is this: I want to be able to use the JSXTransformer script and be able to see a useful version of my compiled JS script which (pre-compilation) had JSX in it. I want to do this so that when I make an error in my JSX-containing JS script I can get a useful error message and hopefully see where the problem is in my original script (or get some clue as to where the problem might be). As it stands now, when I have an error in my script, the console just complains about lines which do not exist in my HTML file (which is only a few lines). So it'll say there's an error in line 65 of even though is only 15 lines. Compounding the problem is that, even when there were no errors and the JSX compiled perfectly to JS and the JS file ran just fine, I still cannot see any sources other than the JSX compiler, the reactjs source and my jquery source. I can't see either a uncompiled or compiled version of my JSX-containing JS file. Instead, what I see is this: Hopefully that explains everything, but let me know if you're still confused. I can provide more info when/if you need it.

Thanks
When I tested last week I couldn't get the source map to do anything at all in Firefox.
Figured it out. I can't decide if it's a Firefox issue or something we're doing wrong, but is the problem. It seems when we pass URLs (eg "") here, Firefox chokes. If we pass a filename (eg "") the sourcemap is usable. So short term, I'm just going to pull off the actual filename and use that. Inline scripts don't appear to have been a problem (supporting my URL theory). cc from the Firefox devtools team, might be worth looking into on your end as well (can't remember if I filed that bug).
Can we keep the full path but drop the domain-part perhaps?
Good idea, I changed to doing that :)
would love a minimal test case. Can you repro with just mozilla/source-map, or only while using devtools?


Question: function markRef(current: Fiber | null, workInProgress: Fiber) { const ref = workInProgress.ref; <del> if (ref !== null && (!current || current.ref !== ref)) { </del> <ins> if ( (current === null && ref !== null) || (current !== null && current.ref !== ref) ) { </ins> // Schedule a Ref effect workInProgress.effectTag |= Ref; }

Do you want to request a feature or report a bug? Bug What is the current behavior? If you remove the ref from a mounted HostComponent on an update, it calls the original ref with null. If you remove the ref from a mounted ClassComponent on an update, it does not call the original ref with null. Note that it doesn't call ref1 (passed to FooInner as ref) with null Note that it does call ref1 (passed to div as ref) with null If you modify the ref from either a HostComponent or a ClassComponent (change from to ), the original ref (ref1) is called with null and the new ref (ref2) is called with the instance. (take the sandboxes above and change the second to What is the expected behavior? Honestly not sure but it should be consistent. The reason this is different is because for HostComponents, as long as . For ClassComponents, as long as -- which means if is null, the behavior is different (hence this issue). We should probably pick one and make it consistent. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Unsure - it for sure is an issue in latest/Fiber, but I haven't dug deep enough to see what happened in <16.


Question: **Note:** `setState()` does not immediately mutate `this.state` but creates a pending state transition. Accessing `this.state` after calling this method can potentially return the existing value. <del> ### replaceState(object nextState) </del> <ins> #### replaceState ```javascript replaceState(object nextState) ``` </ins> Like `setState()` but deletes any pre-existing state keys that are not in nextState. <del> ### forceUpdate() </del> <ins> #### forceUpdate() ```javascript forceUpdate() ``` </ins> If your `render()` method reads from something other than `this.props` or `this.state` you'll need to tell React when it needs to re-run `render()`. Use `forceUpdate()` to cause React to automatically re-render. This will cause `render()` to be called on the component and all of its children but React will only update the DOM if the markup changes. Normally you should try to avoid all uses of `forceUpdate()` and only read from `this.props` and `this.state` in `render()`. This makes your application much simpler and more efficient. <del> ### object getInitialState() ### componentWillMount() ### componentDidMount(DOMElement domNode) ### componentWillReceiveProps(object nextProps) ### boolean shouldComponentUpdate(object nextProps, object nextState) ### componentWillUpdate(object nextProps, object nextState) ### ReactComponent render() ### componentDidUpdate(object prevProps, object prevState, DOMElement domNode) ### componentWillUnmount() These are overridable lifecycle methods; see the [lifecycle methods](lifecycle.html) documentation for more information. </del> <ins> ```javascript object getInitialState() componentWillMount() componentDidMount(DOMElement domNode) componentWillReceiveProps(object nextProps) boolean shouldComponentUpdate(object nextProps, object nextState) componentWillUpdate(object nextProps, object nextState) ReactComponent render() componentDidUpdate(object prevProps, object prevState, DOMElement domNode) componentWillUnmount() ``` See the [advanced components](advanced-components.html) documentation for more details on these lifecycle methods. </ins>

I have a fresh installation of Ubuntu 14.04 and installed compiled version of 10.38. failed on step with error 'make: g++: Command not found'. solves the problem. It make sense put g++ dependency into Prerequisites section.
That's kind of annoying but yea, we might need to do something like that. Compilers are a dependency for any binary npm module (which one of our dependencies depends on). Even contextify itself doesn't call out the need for g**. When you install node / npm via does it not install as well? It seems like it should since that's a requirement for many modules.
I used the recommended approach for . is not a part of installation. But I see your point, contextify setup on Windows even more .
The installation of build-essential is not 'optional'. It is a prerequisite for otherwise node-gyp will fail. The instructions for the Debian-based installation should reflect that build-essential is a prerequisite.
for installing g++ in fedora and other linux os use sudo yum install /usr/bin/g++ or sudo dnf install gcc-c++
fixed it for me (Ubuntu)
works for CentOS7, too. :)
What about Mac?


Question: // fire. The workaround for this bug involves attaching an empty click // listener on the target node. if (registrationName === ON_CLICK_KEY) { <del> var id = inst._rootNodeID; </del> <ins> var key = getDictionaryKey(inst); </ins> var node = ReactDOMComponentTree.getNodeFromInstance(inst); <del> if (!onClickListeners[id]) { onClickListeners[id] = EventListener.listen( </del> <ins> if (!onClickListeners[key]) { onClickListeners[key] = EventListener.listen( </ins> node, 'click', emptyFunction

In my javascript frameworks benchmark I ran into a performance regression for react. To reproduce open and open the console. Repeat three times the following: Click "Create 10,000" then click "Clear" You'll get a result like that: runLots took 1905. clear took 1997. runLots took 1813. clear took 4208.895 runLots took 1806. clear took 401. Now repeat the same for and you'll get something like that: unLots took 2938. clear took 399. runLots took 2726.365 clear took 383. runLots took 2872.625 clear took 381. (Measurement on Chrome 51 on MacOS 10.11.5 on a MBP 15) Notice that clear is a lot slower for the first two runs for React v 15, but the third clear run performs about the same for both react versions. The source code can be found in the of my benchmark.
In general we don’t advise you to render 10K items. Use something like instead. However, this indeed seems like a perf regression. <sIt appears that we’re spending a little time in per each item, and it adds up with 10K items.</s(Scratch that, doesn’t appear to be the cause.)
This is a very simple scenario: we are unmounting 10,000 components. The bottleneck is somewhere in reconciliation. React 0.14 is reconciling fast right away: <img width="762" alt="screen shot 2016-07-08 at 22 06 01" src=""React 15 is reconciling slow at first (notice how long is compared to applying DOM updates): <img width="1097" alt="screen shot 2016-07-08 at 22 03 56" src=""But it warms up exactly after two mount-unmount cycles (notice how its size is less relative to DOM updates): <img width="928" alt="screen shot 2016-07-08 at 22 04 07" src=""
It looks like there is some sort of V8 optimization that doesn’t kick in until you unmount a lot of components.

I was able to drastically reduce time (from 2 seconds to 300 milliseconds) on React 15 by replacing statements with assignment in these two places:   This is probably not a real solution (I think just leaving them as means memory keeps growing, even if just for property keys). Still, I wonder why 0.14.x is not similarly penalized.
Replacing objects with ES6 Maps gives similar performance improvements there.
This was fixed in . Thank you very much for caring and providing specific instructions.
As a quick experiment, I ran the benchmarks under Firefox: both versions ran in the same speed as the 15.2 in Chrome (I mean: slow). I surely hope the fix would fix it in Firefox too !
Maybe putting these fields on the internal instances instead of global maps will help it in Firefox. Would you like to investigate why it's slow?
I gave it a look, and Firefox slowness is due to DOM being slow. I don’t think we can fix it.
I'd really appreciate a Firefox bug report with testcase here!
I filed with the information of this bug. I don't have the time to do a reduced testcase now though.
FWIW, removeChild is slow in Gecko because of layout. No idea whether setting display: none before removal or some such might speed up the process. It might help if done on the element on which removeChild is being called.
Thank you for filing!


Question: export const { disableInputAttributeSyncing, <ins> enableTrustedTypesIntegration, </ins> disableSchedulerTimeoutBasedOnReactExpirationTime, warnAboutSpreadingKeyToJSX, replayFailedUnitOfWorkWithInvokeGuardedCallback,

This is a weird one. Basically, if you add an event listener to the document in an effect that was triggered by an event. e.g. toggles some state, which triggers an effect, which adds a handler to the document. In the normal case the new event handler will "miss" the triggering event, e.g. the click handler won't respond to the click event that triggered it being (omg). HOWEVER, if you render a portal first, the timing changes slightly and the event handler will see the current event. React version: 17 the "show Message" button to see a message toggle in and out the "Render Portal" button (see a portal rendered into the body) the "show Message" button again and notice nothing happens The reason for the final behavior is the click event both opens and closes the message, (calls set state twice) <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: That they be consistent
17 only?
17 only! downstream issue
well tbh maybe this was present but not observable since before 17 you couldn't attach an event listener "higher up" so there wasn't any way to get in front of the current event
What sounds like a bug here is that is called synchronously at all. It should normally be deferred — which would avoid this issue. So it sounds like there's an unexpected effect flush. Would be nice to dig into why.
I'm sooo confused. I can't reproduce this anymore. The only thing I did was to update Chrome...
Can you still repro it?
bah sorry i was goofing around trying to find a workaround and didn't realize it was saving instead of forking. It should be back to being reproducible
Ok at least I can still sleep at night
What happens here is that the native event bubbles: On the root container On the body (portal target) This is why we get into dispatchEvent twice. Root container pass schedules an effect, and body pass flushes it. Seems like a bug that we flush the effect in this case.
To follow up on this — it does seem like a bug but we can't commit to prioritizing it at the moment.

There will be a bunch of work done to clean up and simplify related parts of the code in the coming months so we'll likely address it then. Have you found any userland workaround, or is this a hard blocker for you?
We've got a workaround that's simple and effective in theory . Need to let folks test it out a bit though. Alternatively I think adding listeners in a would work albeit pretty annoying to manage in an effect. For anyone looking, our current workaround is
What I noticed is that for an everything works fine but an actual user click causes the issue described: Edit: I think I'm try attaching a capture listener as well and then check in the bubble event listener if I also captured the event. That fixes the problem at least for mounts in the bubble phase. That looks promising so far: Edit2: Bisecting releases leads to good: 0.0.0-experimental- bad: 0.0.0-experimental- I used experimental releases since the release channel was released less often in that time. So the bug got introduced in Edit3: I don't think the timing of effects changed between 16 and 17. Looks like the timing of events changed due to the changes to the event delegation system. If you add the native listener to instead of , the code works fine. Edit4: ~When the portal is rendered into react attaches its event delegator onto the If I remove that event handler the message can be displayed again.~ See Edit5: Last bit: What makes this bug hard to track down with tests is that you naturally use but within React does not flush discrete updates. Though this is already documented in I'm generally suprised that passive effects are flushed synchronously at all but this does seem to be intended
It seems to me that the assertions in are not correct. The update that is scheduled in the passive effect is deferred as intended when flushing sync but the effect itself should not run when flushing synchronously. IMO would make more sense here. The test comment acknowledges that this is the opposite order and it seems to me that this issue is a good example why this order is problematic: Any side-effect that touches the DOM directly is out-of-order.

Not sure about the intended behaviour but it seems like having the following solve your issue (at least temporarely): On step 3, it displays the message correctly
You can also fix the issue by wrapping in a , like so:
Is there a fix in progress, for upcoming versions, for this bug? I am facing this issue , which cant be resolved because of this.
Could you explain in the Material-UI issue why this can't be resolved for you? We were under the impression that we worked around this bug for our specific usage. For updates on a fix, is the latest update. From what I gather the team is already experimenting with potential fixes. You can subscribe to this () github issue to get notified about updates. Asking for updates does not speed up delivery of said update.
The team has taken a closer look at this now that the related refactors are landing. We can't fix it in a general case without relying on some heuristic. Making all effects synchronous would be bad. Making all of them asynchronous also doesn't work because sometimes we need to flush earlier. The need to flush earlier relates to handling discrete events (like click) that need to be able to observe the already flushed state. A reasonable compromise is to make them synchronous at the end of discrete events (such as click), but asynchronous in other cases. This mirrors the recent changes we've made to state updates in Concurrent Mode to make it easier to adopt. So we this heuristic in Concurrent Mode: I checked that this issue in Concurrent Mode with the latest master commit and now consistently does not show the message (because clicks lead to synchronous effects). We've considered backporting this behavior to React 17. But at this point it's very risky because it's such a subtle change. It's also risky because it would be the first time that we rely on -based heuristics outside of Concurrent Mode. So it's kind of a new territory. Given that it's easy to work around, it doesn't seem like this risk is warranted in React 17. So we've concluded that, while unfortunate, it is safer to not try to fix it in React 17. But Concurrent Mode will have a more predictable behavior here. (Note that it's also quite likely that React 16 also had cases with over-flushing, but triggered under different conditions.)

I know this isn't the resolution that most people were hoping for.
Bug; Still clickAwayListener tests fails using React testing library. It seems because of react18.


Question: expect( Object.keys(testInstance.refs || {}).filter(key => testInstance.refs[key]) .length, <del> ).toEqual(1); </del> <ins> ).toEqual(2); </ins> ReactDOM.render(<TestComponent destroy={true} />, container); expect( Object.keys(testInstance.refs || {}).filter(key => testInstance.refs[key])

Do you want to request a feature or report a bug? Bug What is the current behavior? If you remove the ref from a mounted HostComponent on an update, it calls the original ref with null. If you remove the ref from a mounted ClassComponent on an update, it does not call the original ref with null. Note that it doesn't call ref1 (passed to FooInner as ref) with null Note that it does call ref1 (passed to div as ref) with null If you modify the ref from either a HostComponent or a ClassComponent (change from to ), the original ref (ref1) is called with null and the new ref (ref2) is called with the instance. (take the sandboxes above and change the second to What is the expected behavior? Honestly not sure but it should be consistent. The reason this is different is because for HostComponents, as long as . For ClassComponents, as long as -- which means if is null, the behavior is different (hence this issue). We should probably pick one and make it consistent. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Unsure - it for sure is an issue in latest/Fiber, but I haven't dug deep enough to see what happened in <16.


Question: // Compute `paths` and cache it. Guarding against cycles. cache.set(segment.id, null); <del> if (segment.nextSegments.length === 0) { </del> <ins> if (codePath.thrownSegments.includes(segment)) { paths = 0; } else if (segment.nextSegments.length === 0) { </ins> paths = 1; } else { paths = 0;

I believe this should be a valid case, because throw.
Hmm, I just realized throw should not be used for valid business case (GraphQL endpoint was updated). Render nothing (and request app update) is the correct approach.
I think we shouldn't warn on this.


Question: <span className="child2" /> ]); <del> shallowRenderer.render(<SomeComponent aNew="prop" />, {}); </del> <ins> shallowRenderer.render(<SomeComponent aNew="prop" />); </ins> var updatedResult = shallowRenderer.getRenderOutput(); expect(updatedResult.type).toBe('a');

I am trying to render a component using the preliminary shadow renderer support in TestUtils. A simple reproducible test case of my issue is this When I run this in my Jest test, I get: It looks like this error is thrown whenever the component being rendered has . I thought perhaps the context was required (although I haven't had any problems omitting it in my actual app), but even when using I get the same exception.
I think this is a known issue with shallow rendering. cc
thanks for the report. Context isn't meant to be supported with shallow rendering (i.e., we haven't tested it), but it looks like you may be able to work around this problem by passing an object as the second argument to : it looks like an additional argument was to the shallow rendering API in . What was the thinking here? Can we default this to an empty object?
Thanks, the workaround works great. And I see you posted a fix as well so looking forward to that.


Question: let runIdCounter: number = 0; let mainThreadIdCounter: number = 0; <ins> const isEnabledSharedArrayBuffer = // $FlowFixMe Flow doesn't know about SharedArrayBuffer typeof SharedArrayBuffer === 'function' && // We only use SharedArrayBuffer when cross origin isolation is enabled. typeof window !== 'undefined' && window.crossOriginIsolated === true; </ins> const profilingStateSize = 4; export const sharedProfilingBuffer = enableProfiling <del> ? // $FlowFixMe Flow doesn't know about SharedArrayBuffer typeof SharedArrayBuffer === 'function' </del> <ins> ? isEnabledSharedArrayBuffer </ins> ? new SharedArrayBuffer(profilingStateSize * Int32Array.BYTES_PER_ELEMENT) <del> : // $FlowFixMe Flow doesn't know about ArrayBuffer typeof ArrayBuffer === 'function' </del> <ins> : typeof ArrayBuffer === 'function' </ins> ? new ArrayBuffer(profilingStateSize * Int32Array.BYTES_PER_ELEMENT) : null // Don't crash the init path on IE9 : null;

React version: v17.0.1 http://localhost:3000 in Chrome 88 or 89, regular or Incognito mode DevTools: the warning is displayed Link to code example: https://react- Warning: No warning will be shown. As the warning shows, Chrome will require cross-origin isolation starting version 91 in order to use SharedArrayBuffer. To enable cross-origin isolation, the page needs to be loaded with COOP and COEP headers which I believe is out of React's control. You can learn more about this at As it's confusing for React users to see this warning every time they open the page, I'd propose two things: the message by using SAB only when cross-origin isolation is enabled. You can check it by boolean flag. that the page needs to send COOP and COEP headers to profile performance using SharedArrayBuffer. You can find an actionable guide here: The problematic code is here: FWIW, with cross-origin isolation, you'll be able to use too. cc:
I've created a PR to fix this.
Will this be back-ported to React 16? I have projects that can't upgrade yet because they rely on packages that aren't fully compatible with React 17 yet (e.g. Material-UI).
My workaround is to put a script in the file: <scriptif (!crossOriginIsolated) SharedArrayBuffer = ArrayBuffer </script
Why is this closed? just need to publish the solution?
Because the fix has been merged to master.
We don’t generally backport anything except critical security fixes. My understanding is that the only problem here is a warning. Not that something would actually break. Do you have evidence to the contrary?
Starting Chrome 91, will return on environments without cross-origin isolation. This shouldn't be a breaking change for React as far as I can tell. FWIW, you can emulate how it will behave in Chrome by launching it with a command line flag . Here's instructions:
React 17.0.2 was released with removed dependency on so this should be resolved.
We don't plan to backport this since there is no real breaking change for React here.
For later versions that Fix will not be available?
You mean for earlier ones? No, but also nothing would break. You can ignore the message.

use http-proxy-middleware package but works only in dev mode, so not in production. I'd suggest using a Nginx as proxy and inject the 2 http headers.


Question: continue; } <ins> var isReserved = name in RESERVED_SPEC_KEYS; invariant( !isReserved, 'ReactCompositeComponent: You are attempting to define a reserved ' + 'property, `%s`, that shouldn't be on the "statics" key. Define it ' + 'as an instance property instead; it will still be accessible on the ' + 'constructor.', name ); </ins> var isInherited = name in Constructor; <del> var result = property; if (isInherited) { var existingProperty = Constructor[name]; var existingType = typeof existingProperty; var propertyType = typeof property; invariant( existingType === 'function' && propertyType === 'function', 'ReactCompositeComponent: You are attempting to define ' + '`%s` on your component more than once, but that is only supported ' + 'for functions, which are chained together. This conflict may be ' + 'due to a mixin.', name ); result = createChainedFunction(existingProperty, property); } Constructor[name] = result; </del> <ins> invariant( !isInherited, 'ReactCompositeComponent: You are attempting to define ' + '`%s` on your component more than once. This conflict may be ' + 'due to a mixin.', name ); Constructor[name] = property; </ins> } }

This logs both and : This seems weird to me and inconsistent with the behavior for non-static functions. Can we change this to give an error too?


Question: expect(container.firstChild.getAttribute('value')).toBe('foo'); expect(container.firstChild.value).toBe('foo'); }); <ins> it('should not remove attributes for custom component tag', () => { const container = document.createElement('div'); ReactDOM.render(<my-icon size="5px" />, container); expect(container.firstChild.getAttribute('size')).toBe('5px'); }); </ins> }); });

Do you want to request a feature or report a bug? Bug What is the current behavior? The size prop can only be a number and I think this should be true for inputs and selects but not necessarily true for the rest of HTML tags or web components. 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: Sorry, it's a CodePen. This example uses a framework called OnsenUI that internally uses web components. In the OnsenUI framework there is an icon web component that transforms every size prop value into a string which is not attached to the DOM. I know that the example has more dependencies than React, BUT there is also a simple div (as simple as this ) which is also affected by this issue. What is the expected behavior? The size prop should be to the DOM when it is not a number on HTML tags that aren't inputs and selects. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? The affected versions are = 16.3 It works ok in versions <= 16.2 Browsers: All
The size prop can only be a number and I think this should be true for inputs and selects but not necessarily true for the rest of HTML tags or web components. What are the HTML tags that have a attribute except inputs and selects? With web components I am not seeing the issue: <img width="227" alt="screen shot 2018-04-26 at 7 51 53 pm" src="https://user-"
the attribute is an HTML attribute, not something that React provides. According to the HTML spec, is only allowed on and elements
I don't know why I wrote "rest of HTML tags", my bad . The example you provided works ok, but if I add something that doesn't seems like a valid size then it doesn't work. For example: Value | Works -------|------- 100 | Yes 10px | No 10e1 | Yes -1 | No Something changed in 16.3.

Version 16.3 <img width="853" alt="captura de pantalla 2018-04-26 a las 21 36 43" src="https://user-"Version 16.2 <img width="855" alt="captura de pantalla 2018-04-26 a las 21 37 10" src="https://user-" I suppose that it's fine to filter props when not passing the appropriate values when using HTML tags but I suppose that in web components the size attribute can be anything. Am I wrong? What do you think?
The web component code path shouldn't reject any attributes. If it does it's a bug.
The bug is . Before the we should add something like Please send a PR :-)
Ok, I will work on this tomorrow. I'm heading to bed. Thanks for your quick response.
Couldn't wait
Should be fixed in React 16.4.