Question: matrix: fast_finish: true allow_failures: <del> - env: TEST_TYPE=lint </del> - env: TEST_TYPE=test:coverage - env: TEST_TYPE=perf:full - env: TEST_TYPE=test:webdriver:saucelabs:modern

We're blocked on a few things here. Current JSHint is incompatible with what we do with template strings. I have a PR up there to mostly fix it but I bet there are more things. So even after that I think we'll want to switch to using ESLint. However that has its own set of problems as it is still working on ES6/JSX support (mostly blocked on other libraries at this point it seems). I have a PR () up to start using eslint, but there are a few rules disabled (because of incompatibilities on their end) which are really important and enabling them is a blocker for this. [x] Use eslint () [x] Enable all appropriate rules [ ] Add custom rules (namely, must use string literals for 2nd argument)


Question: setContentDOMNode, setProjectRoots, setStatusListener, <ins> setDisconnectedCallback, </ins> startServer, openProfiler, };

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: title: Immutability Helpers - id: pure-render-mixin title: PureRenderMixin <ins> - id: perf title: Performance Tools </ins> - title: Reference items: - id: top-level-api

I'll let write these, but it would be nice to get them spot checked by and/or


Question: var assign = require('Object.assign'); var findDOMNode = require('findDOMNode'); var onlyChild = require('onlyChild'); <del> var warning = require('warning'); </del> ReactDefaultInjection.inject();

People lose hours of work debugging a simple issue: two versions of React being loaded at the same time. Because there is no warning right away when this happens, they usually discover the problem through invariant violations. Some of them are descriptive (e.g. ) and I think I even saw warning that said something like "check if two copies of React are loaded", but some are really cryptic: . Is there a reason why we don't want to warn right away when two copies of React are loaded?
There's probably no good way to find out if two copies of React are loaded (CommonJS modules are the antithesis of sharing a global scope, they're literally two duplicate but separate modules). But I would expect React to be clever enough to figure out that, say, a component is a React component even if it's not from the same copy of React.
I think it's lesser evil to put some flag on , like , than to spend any more time on this.
Should be preferable to just extend (or w/e) with simple duck-typing that warns if it looks like a ReactElement but isn't... or something like that. It's free and doesn't interfere with intentionally running multiple React instances.
I think that in the future, this will actually just work. In the meantime we can warn here:
Would it catch all of the issues listed above though? Usually the problem comes up when some component or helper library loads its own version. Will we get to in this case? Besides, does React truly support independent Reacts on page right now? Do they not interfere in any way at all if they aren't mixed (e.g. browser event handling)?
(To clarify, I was referring to comment)
I might be mistaken, but ignoring weird hacks then the only issue with multiple instances of React are when ReactElements from different instances gets mixed up. Depending on which API you feed them to, you're going to see lots of different errors though. So yeah... I think that should take care of all, or most at the very least. As long as you never stop event propagation or mount them inside each other it should be OK I think (but still not great though). Good point.
Just a confirmation from someone who just flushed 3 hours of debugging time down the toilet that, yes, this issue is hard to debug, please make at least a warning.

In my case I was having a weird exception (TypeError: Cannot read property 'firstChild' of undefined) caused by the fact that a component created with a different (uninitialised) copy of React was carrying a _owner = null, thereby breaking findComponentRoot().
We should already be warning in the case that an element from one copy of React is passed to in another: I guess the cases here are when nesting elements from different versions inside each other?
Yes. At least it was in my case. Nested elements created from different React versions.
Just my 2cents: I had the same issue today and my problem was using browserify 8.1.3 instead of 8.1.1 Hope it helps
The other issue with this is you can't reliably use the dependency injection mechanism, e.g. to change the batching strategy, while using components from multiple modules where each has it's own instance of React as a dependency. Even if they are the same version of React.
+1 ; thanks gaearon
said: "The other issue with this is you can't reliably use the dependency injection mechanism, e.g. to change the batching strategy, while using components from multiple modules where each has it's own instance of React as a dependency. Even if they are the same version of React." This.
The main workaround many modular React components are using is to specify React as a -- the parent module must provide React to prevent multiple copies. This is problematic because are on track to because they introduce .
I've seen this a lot as well, and had lots of requests to switch React to a (+) in my packages which I'm currently resisting for reasons mentioned. The most common frustration I've seen is when npm subtly installs two versions of React, and Browserify (correctly) includes both in the build. It can happen unexpectedly w/ package updates and breakage ensues. A warning from React that "hey, there is more than one of me on the page" seems like the most elegant way to warn developers early and direct them to an explanation of what's gone wrong / how to fix it. It's a side-effect of npm's dependency rules and node's behaviour that I end up with two Reacts when I just want one.

Looks like things will get better with (see npm/npm) but in the meantime I agree with about adding a "lesser evil" hack: ... there's a good argument to be made that this isn't React's problem to solve, but since it's a common problem and React can solve it, I think it would be great if it did.
A solution I found with was to alias all calls like so (example shown with grunt): so it isn't impossible to fix, but I'd make the argument that since this is such a common issue it needs to be highlighted more clearly in the React docs.
when using browserify it can happen just when requiring two different versions of React because of the way it handles deduplication. Requires with the same path and code between the two versions can end up getting de-duped. Modules where the code/require path was changed between versions get deduplicated and others don't. So I encountered this: (from React v1) is evaluated and it mixes in ReactBrowserComponentMixin as part of its spec .Class.injectMixin(ReactBrowserComponentMixin) is evaluated and it adds ReactBrowserComponentMixin to all classes subsequently created by ReactClass.createClass (shared between React v1 and v2 because it didn't change between the two versions of React) (from React v2) is evaluated and it tries to mix in ReactBrowserComponentMixin twice, once from ReactDOMSelect's own spec and once from the global injected mixin list. As long as modules can be stateful, this approach to deduplication seems horrifically unsafe. I'll file an issue with Browserify itself, I haven't yet verified if Webpack would have the same issue. Either way - I think it would make sense to handle it specifically in React given how it can trip newcomers up.
Reverting for now (in ) as we sort out some problems.
THANK YOU for this discussion. I was battling with an Invariant Violation bug for half the day yesterday and then came across this ticket this morning. My setup was using a browserify-shimmed version of React and react-router loaded from CDN. After reading this discussion I just opted to use the npm versions of these libs and the error went away. This is my first React project so debugging this problem was a pretty big headache. Thanks again for this discussion as it lead me to figure out the problem and move forward.

Leaving details of my case for future searchers: I got the error "Invariant Violation: Could not find the drag and drop manager in the context of Card. Make sure to wrap the top-level component of your app with configureDragDropContext" Also turned out I had two React versions loaded. The problem was Webpack. I was using "npm link <folder" for one of my packages, which also depends on React. Seems webpack has problems handling symbolic links, or it's my fault configuring it improperly. Anyway, the problem was fixed by installing the package into my local node_modules directory.
Thanks for this, I'm gonna add it to the relevant explanation gist for React DnD.
Would like to have this too. Haven't figured out a way to get GitHub cc'd (rather than bcc'd) without explicitly participating, sorry for the noise.
There's a button :)
I think that still doesn't CC you but only BCC, sadly. Moreover, I'm watching the repo already, but I have a different inbox for when GitHub CCs me.
Fyi: Ongoing PR
Fixed by , hopefully.
If it helps the next person googling, is yet another sign of this problem.
and counting... I've got this one: I'm looking everywhere for the sneaky react twin, but no luck. doesn't show any duplicates The other possibilities I've read about are double-loading the react script, webpack double-bundling, or react/addons causing trouble, so those are what I'm working on now. Insidious.
As you've hopefully set up correctly, then simply remove and reinstall everything, that usually fixes it unless there's some incorrectly configured module.
I tried to git clone the repo and reinstall, but that wasn't the issue. Eventually I noticed that the error was only happening after the first navigation (similar to this ) and started taking apart my navigation menu. Turns out that for some reason putting a from react-router inside a from react-boostrap was causing react to go nuts. I posted my findings on .
I think it also might have had something to do with my not using the generated from react-router as the root of my component hierarchy. I was wrapping it in a higher level-component that accepts my flux instance and passes it on as context.

Isolating the issue into gave me the following error:
The nested links thing is due to invalid HTML and we have a new warning for that in 0.14.
By the way I got that new warning a few days ago and it's beautiful, great work. :+1:
I'm getting this error: when using npm link to require a module I'm working on. I can't be 100% sure that it's caused by having multiple versions of React, but the error does go away when I just paste the npm module directly into my app instead of using it via npm link. I don't get this error when using my npm module the normal way (react is a dev dependency so I don't think it gets installed in node modules). Has anyone else run into this issue and come up with a fix? Thanks!
I got this error while running 0.14-rc1 and 0.14-beta3 together
Please do not report random problems in this issue. File new issues.
Seriously. This has taken me 3 days to figure out that my random error about unmounting the _mouseMoveTracker twice in fixed-data-table is caused by two reacts... This is not good that this bug seemingly can't be fixed? Why can React not just put the version number on the window object and never add itself again if it's there already? This is better than the hours and hours wasted by many people with this!
I thought we fixed this in 0.14 (); is it not displaying a warning?
Yep, I just upgraded to 0.14.2 everywhere (including inside the module) and somehow deleting react from nodemodules/react-datatable/nodemodules/ fixed my bug! (see here ). Maybe there is something wrong with my webpack config? It's weird that this fixed it. Is this having two of the identical version included a subtle variant on this bug?
Part of the problem is react-datatable having as a non-peer dependency (cc which can cause NPM to fetch a separate react installation for just that module.
Okay - thanks - I'll try adding this as a peer dep, however when I want to run the build for my module if developing the datatable from within my main project, what is the best way to accomplish this without issues?
you might try upgrading to , then .

has improvements in how it handles dependencies and is better about avoiding multiple instances of a given package, since it installs with a flat structure instead of nesting dependencies within packages. This, along with moving from to in a library I am writing, solved my similar problems.
Another 4 hours lost. My webpack config now is:
Can you say what symptom you experienced? Also, if you are using the prebuilt I would recommend using the prebuilt react- as well and using in your webpack config since the secret property is unstable and will change in the next version (hence its name).
yes, the problem was in prebuild version of React. The second instance of React came from require('react'). It did work somehow until React 0.14 migration. And even more: It work after partial code removal! This lead me to wrong way of long debugging. I agree, this is my fault. But I still expect something like: every time, instead of rare warning: after which I spent hours to find out whats wrong with my refs... It seems like it is very common problem, and it is have to be more detailed and have better documentation.
same issue with webpack and loading manually.
Is it still an issue to load more than one version of React on a page, even if those instances are managing totally separate DOM trees and aren't being explicitly instantiated as globals? Like if, say, I had a package with and as dependencies, and they both depended on different versions of React, with npm as the dependency manager, could they be used together on one page?
No, that should work now if both are on a recent version of React.
Could you please point me out what would be the behavior of React if , let say , we want to introduce a widget including React in a host page that has an older version of it and the possible workaround to make it work? Thanks
Old versions of React are probably only tripped up by data-reactid IDs in the DOM that it didn't generate. If you're doing only client-side rendering with your widget, it should only have a data-reactroot attribute and no data-reactid so there shouldn't be any conflict.
Just ran into problems again today when I accidentally had 16.4.2 and 16.5.0 installed in a project, no warning from React.

To make matters worse, the duplicate versions were caused by a bug in that ...
Was there any resolution as to whether or not this is possible and/or a good idea? It seems like it'd provide developers with useful information.
Project A uses React 16 wherein Project B uses React 15, Lets say Project A is package got used in Project B - can that work?
Would Preact and React have the same issue described here? I’m asking because I’m using single-spa for a platform play at a large company of distributed teams.
It sounds to me like there are two separate issues here: you have two different copies of the library loaded and in use anywhere on a page in separate components that don't interact with each other? you have components from two different bundles, each with their own copy of the library, interact with each other (eg. the function from one library receiving an element created with from the other library) I don't know about the status with modern versions of React. In the case of Preact (1) should be fine but since it does have some global state you could run into problems in situation (2). Please file an issue in the repository if you'd like to discuss further.
This appears to be a bad link.
For someone encountering this at the moment - does anyone have any tips on identifying the cause and debugging the issue? I've used the check from the hooks page (how I discovered this) which confirms I've got 2 instances loaded: I believe I'm doing things by the book, in a monorepo react, react-dom etc are all always . What steps would you recommend after this?


Question: expect(node.value).toBe('0'); }); <ins> it('should have the correct target value', function() { var handled = false; var handler = function(event) { expect(event.target.nodeName).toBe('INPUT'); handled = true; }; var stub = <input type="text" value={0} onChange={handler} />; var container = document.createElement('div'); var node = React.render(stub, container); node.value = 'giraffe'; var fakeNativeEvent = new function() {}; fakeNativeEvent.target = node; fakeNativeEvent.path = [node, container]; ReactTestUtils.simulateNativeEventOnNode( EventConstants.topLevelTypes.topInput, node, fakeNativeEvent ); expect(handled).toBe(true); }); </ins> it('should not set a value for submit buttons unnecessarily', function() { var stub = <input type="submit" />; stub = ReactTestUtils.renderIntoDocument(stub);

I tried updating from to . Something has changed in between these releases that is making it so that in onChange's synthetic event is undefined.
This appears to be related to a bug in . does not accept the argument and does not pass it on to . However that's not the only fix needed, also needs to pass something in place of the that expects. Also it seems has the same issue with being passed. I tried fixing this myself. However I have issues with the test setup and/or the test utils seem incapable of triggering from .
Yes I can confirm I have this issue too! This unfortunately makes the beta unusable in my app. The is null while the native event has a target
Same issue. The workaround is using instead of . But that's kinda wrong :(
Same here, but you can use for now.
Excuse me. I'm a beginners of React. Can I ask a question? Why can I use "jsx -watch src/build" to translate "" file to plain JavaScrip?
In fact, I can't see any result after do all steps
I don't know, but this is not the place for asking such questions. Ask this on Stackoverflow or IRC / Slack channels maybe
Thank you for your answer.


Question: import type {SourceConsumer} from './astUtils'; const SOURCE_MAP_REGEX = / ?sourceMappingURL=([^s'"]+)/gm; <del> const ABSOLUTE_URL_REGEX = /^https?:///i; </del> const MAX_SOURCE_LENGTH = 100_000_000; type AST = mixed;

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: <del> reactjs.org </del>  No newline at end of file <ins> react.dev </ins>

React GitHub page () ( branch) currently pointing to and then it redirects to So many redirects, can we update the content of file with , if it ok to do, then I am very happy to do the same and I'll contribution in real open source project.
Thanks for pointing this out
Thanks I thought I would get an opportunity to merge the code :(( Is it good to raise a pull request together when we raise any issue, and we know the fix of that issue?


Question: warning( false, <del> 'Don't set .props.' + propName + ' of the React component' + elementInfo + '. Instead, specify the correct value when ' + 'initially creating the element.' + ownerInfo </del> <ins> 'Don't set .props.%s of the React component%s. ' + 'Instead, specify the correct value when ' + 'initially creating the element.%s', propName, elementInfo, ownerInfo </ins> ); }

Ditto on invariant. But I think those are ok already.
I'd take this if I had a bit more detail. I looked at a few thought the codebase and couldn't understand.
Thanks


Question: printOperations, start, stop, <ins> isRunning, </ins> // Deprecated: printDOM, getMeasurementsSummaryMap,

I've tested the new Perf tools on one of the screens in one app I'm working on and it works great :) One thing I wanted also on the old one Perf tools was to be able to check whether the Perf tools are started or stopped, so basically exposing 's variable. My use for that is that I have a keyboard shortcut (in development) bound to start/stop the Perf tools and currently I'm forced to maintain such a variable myself to know whether to start or stop (which gets out of sync if I start/stop the perf tools without the keyboard shortcut). If you don't think it's worthwhile to expose feel free to close this issue.
is not a public API by itself, at least not yet. I’m open to adding to though, as it’s the public API. Would you like to send a PR?
Yeah I'll send a PR :) Should this method on check 's , which is not currently exposed, or should keep track of that state separately?
Yeah, we can add to and to with the real state being in .
the PR should be against which branch? ?
Yep!
I've opened the PR


Question: return true; } if (requestedBundleTypes.length > 0) { <del> const isAskingForDifferentType = requestedBundleTypes.every( requestedType => bundleType.indexOf(requestedType) === -1 </del> <ins> const isAskingForDifferentType = requestedBundleTypes.some( requestedType => !bundleType.includes(requestedType) </ins> ); if (isAskingForDifferentType) { return true;

React version: 18.x.x up to latest the React repository. : either: - the output of the function logs within the script. Relevant code: Relevant function: The function, responsible for determining whether to include a bundle in the build output, contains incorrect logic for filtering when multiple bundle types are specified. Specifically, the following line causes the issue: This code uses with to check if all requested bundle types are missing in the current bundle type. However, when multiple types are specified, it should skip a bundle only if none of the requested types are present. Here's an example of the incorrect behavior observed during debugging: In this case, even though the is and doesn't include , is incorrectly evaluated as , leading to the bundle not being skipped. The function should correctly filter bundles based on multiple requested types. In the example above, the expected behavior is that should be for the bundle type, as it does not include the type. In general, the function should return (skip the bundle) only if none of the requested types are included in the current bundle type.

<!-- 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.x.x up to latest Node version: 16.x.x up to latest the React repository. : either: - Link to code example: Relevant code: (line 72) Relevant function: The current behavior: When running the commands or , a is thrown: . This is evident in the provided screenshot. The error originates from the function in . The problem stems from how the value is handled. In these specific commands, is passed as an array (e.g., ), but the code incorrectly wraps it in another array: The function then attempts to apply the method to each element of , expecting them to be strings. However, due to the erroneous wrapping, it encounters an array instead, leading to the TypeError. The expected behavior: The or commands should run without errors. The value should be handled correctly even when passed as an array, and bundle type filtering should work as expected. Additional information: The or commands work without issues because the value is passed as a string or undefined. The function generates and arrays based on the provided names ( or ). These arrays are used for bundle filtering in the function.


Question: expect(node.value).toBe('foobar'); }); <ins> it('should not render value as an attribute', function() { var stub = <textarea value="giraffe" onChange={emptyFunction} />; stub = renderTextarea(stub); var node = stub.getDOMNode(); expect(node.getAttribute('value')).toBe(null); }); </ins> it('should display `value` of number 0', function() { var stub = <textarea value={0} />; stub = renderTextarea(stub);

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: checkMergeArrayArgs: function(one, two) { invariant( Array.isArray(one) && Array.isArray(two), <del> 'Critical assumptions about the merge functions have been violated. ' + 'This is the fault of the merge functions themselves, not necessarily ' + 'the callers.' </del> <ins> 'Tried to merge arrays, instead got %s and %s.', one, two </ins> ); },

Passing a function with some properties (simply the wrong thing) into yields rather cryptic: especially since the message says it is not the caller's fault.
One could add an invariant to But it is strange that the invariants in and don't mention arrays and objects, respectively.
is also a very contextual name (I have no idea what the author meant). I agree that these messages could be better.


Question: var CSSProperty = require('CSSProperty'); <ins> var camelizeStyleName = require('camelizeStyleName'); </ins> var dangerousStyleValue = require('dangerousStyleValue'); var hyphenateStyleName = require('hyphenateStyleName'); var memoizeStringOnly = require('memoizeStringOnly'); <ins> var warning = require('warning'); </ins> var processStyleName = memoizeStringOnly(function(styleName) { return hyphenateStyleName(styleName); }); <ins> if (__DEV__) { var warnedStyleNames = {}; var warnHyphenatedStyleName = function(name) { if (warnedStyleNames.hasOwnProperty(name) && warnedStyleNames[name]) { return; } warnedStyleNames[name] = true; warning( false, 'Unsupported style property ' + name + '. Did you mean ' + camelizeStyleName(name) + '?' ); }; } </ins> /** * Operations for dealing with CSS properties. */

We happen to "support" hyphenated keys to the style object on initial render (because we attempt to hyphenate camelcased keys) but those styles will never be updated on subsequent renders because we never attempt to unhyphenate. So we should warn when we see a hyphenated style.
Some browsers support assigning with hyphenated keys, but probably not all do.
AFAIK only Webkit does. (And I guess by association, Blink)
Perhaps another one for you!
OK
Sorry for the long delay, been busy. I'll try to do this today.
No problem, whenever you have time.
Curious: why do we not want to hyphenate names on subsequent updates, and instead show a warning? Because there should be “one way to do that”?
Yes, this matches our existing practice of requiring camel-cased attributes in general, which makes it easier to make warpper components that modify props in some way because you only need to look in one place to find the original value. In addition, you don't need to worry about what happens if someone were to specify both and in the same style block. (One last advantage: if the warnings happen only in the dev version, then there's no runtime cost in the production build.)
Do you think it's worth adding for the sake of providing a suggestive warning? (e.g. )
There you go! I also updated the docs about prefix, since it's not clear right now.
A warning would be very helpful, this just sucked up a lot of my time. If anyone is interested, chrome seems to handle hyphenated CSS props OK but FF doesn't


Question: strictModeBadge = ( <a className={styles.StrictModeNonCompliant} <del> href="https://fb.me/devtools-strict-mode" </del> <ins> href="https://react.dev/reference/react/StrictMode" </ins> rel="noopener noreferrer" target="_blank" title="This component is not running in StrictMode. Click to learn more.">

The Strict mode warning badge points to which points to the strict mode section in instead of . Badge: <img width="273" alt="Screenshot 2023-05-16 at 20 20 59" src=""Code: Every time No response No response No response No response No response No response
Thanks for spotting, anyone interested in opening a PR with updating it to
interested, can i proceed and open a PR ? here is the PR
Sorry mate I did not see your comment before starting
Thanks for your contributions Have to go with , as commented a bit earlier.


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

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: } } <ins> if (__DEV__) { if ((flags & HookInsertion) !== NoHookEffect) { setIsRunningInsertionEffect(true); } } </ins> safelyCallDestroy(finishedWork, nearestMountedAncestor, destroy); <ins> if (__DEV__) { if ((flags & HookInsertion) !== NoHookEffect) { setIsRunningInsertionEffect(false); } } </ins> if (enableSchedulingProfiler) { if ((flags & HookPassive) !== NoHookEffect) {

Following up on (/cc ) React version: 18.0.0-rc.3-next-- an update (e.g. ) from within Link to code example: Update is applied and no warning is issued. According to cannot schedule updates. But seems to "work". Maybe this is just incidental because it's the first render? I got the impression that this should definitely cause a warning (not implemented) but I wonder if we also should consistently drop updates from ?


Question: if (request.status === CLOSED) { return; } <ins> if (request.destination !== null) { // We're already flowing. return; } </ins> request.destination = destination; try { flushCompletedChunks(request, destination);

When using for e.g. Cloudflare Workers runtimes, I'm noticing this error on the server: I'm assuming this results in the following malformed chunk being sent to the stream: Which results in the client failing: I put together a reproduction here, powered by for the Workers runtime: Could this be related to the "fundamentally flawed" nature of Web Streams implementations in e.g. Cloudflare Workers runtime? Is something going on with corking/uncorking, as per Maybe something's wrong with Miniflare's polyfill and this is a non-issue, coming from ? Finally, it's possible something is wrong with the Vite version of the example I've put together. I could try rebuilding with webpack if it's determined none of these items apply.
Have you looked at what chain of assumptions leads to this? It seems like it would be good to understand what different state machines are involved and why something's happening in CF that doesn't happen in the browser.
Have you looked at what chain of assumptions leads to this? after lots of digging, here's what we've discovered: The difference between Cloudflare/Oxygen Workers runtimes and the browser comes down to how the is consumed after being passed to . In the browser and , this is how the stream (via ) is consumed: This presumably results in a single . In the worker runtime, is read through an : Importantly, this results in getting called multiple times as more data is enqueued and as the reader sees fit. This is an assumption on my part, so I could be wrong here. When combined with Suspense boundaries, callbacks trigger . At the same time, repeated requests from the stream reader also call . This results in the following error on the server: You can also reproduce this directly in the browser by attempting to read the stream with . Here is a new fixture with a reproduction of the issue, including a couple test cases that show the different errors you'll see based on the number of Suspense boundaries you have: If this seems like a legitimate bug to you, a couple ideas I had: Should there be some sort of check like in ? Should we splice completed boundaries earlier to account for concurrency so they are removed from the array and not re-flushed? Here are some other resources and scratch notes:
~We'll fix this reentrancy bug somehow.

However, right now it's a bit lower priority because CloudFlare technically don't support ReadableStreams and so you have to go through the polyfill and any subtle differences might be due to the polyfill. To really know if we fixed this issue we should apply this to native CloudFlare ReadableStreams... which I'm told is coming. So that's how we know if it actually worked. Until then, the support for CloudFlare workers is... partial.~ On a second thought this should probably fix it. I think I finally understand how it's supposed to work now.
Please take another look and see if this fixes all the issues you've noticed.
works like a charm! Thanks for taking the time to look at it and get it fixed


Question: render() { instance = this; return ( <del> <> </del> <ins> <React.Fragment> </ins> <Yield value="first" /> {this.state.count} <Yield value="last" /> <del> </> </del> <ins> </React.Fragment> </ins> ); } }

: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks


Question: let suspenseState: null | SuspenseState = fiber.memoizedState; let suspenseInstance: null | SuspenseInstance = suspenseState !== null ? suspenseState.dehydrated : null; <del> invariant( suspenseInstance, 'Expected to have a hydrated suspense instance. ' + 'This error is likely caused by a bug in React. Please file an issue.', ); </del> <ins> if (suspenseInstance === null) { // This Suspense boundary was hydrated without a match. return nextHydratableInstance; } </ins> return getNextHydratableInstanceAfterSuspenseInstance(suspenseInstance); }

Do you want to request a feature or report a bug? Bug What is the current behavior? React 16.10.0 has broken all applications (and potentially other SSR solutions). It appears you cannot in conjunction with a client-side component. ! CodeSandbox: What is the expected behavior? Not entirely sure -- I'm opening this issue to discuss. The provided example worked in React 16.9.0 (and prior releases containing Suspense). Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? / is broken. / works.
Thanks for reporting! We'll have a fix out soon; in the meantime, please downgrade back to 16.9.0.
I believe technically we don't support conditionally rendering a Suspense boundary when server rendering. It just happened to (accidentally) work before. We'll either fix so it matches the old behavior or provide a more graceful error or fallback behavior.
The issue is that the error only occurred on the server. So if you conditionally rendered it, you’d miss (intentionally?) the error we logged to let you know not to use Suspense with SSR. The issue is that the accidental semantics this lead to, on the client, is not actually the semantics we want SSR Suspense to have. That’s why it was not yet available for SSR. We’ll at least need this fallback behavior to behave reasonably when the server renders the boundary. Now the question is if we can preserve the old accidental behavior if the server was conditionally excluding the boundary on the server. And if that’s even a good idea.
I've just found that error today only in my production build of Nextjs. There was no such error yesterday. But I am having React and didn't update any packages. Is it possible?
please file a separate issue. I’d recommend including a reproducing example on codesandbox or as a git repo.
I got the same error on version but it still not resolved <img width="1219" alt="Screen Shot 2019-09-28 at 23 05 56" src="https://user-"
The key issue here is that with the new model (behind the flag), this would be considered a hydration error. Something caused a mismatch.

We don't know if this is because the boundary was intentionally conditionally rendered, or if it was because something completely different was conditionally hydrated. E.g. consider this . If it rendered the div on the server but not on the client, then the Suspense boundary would have a mismatch because it finds the div where it expected its own content. I believe we will at least have to make this a hydration error log in DEV mode. So we'll need to find a fix in regardless. However, as a courtesy we can probably delay that log so there's time to coordinate a fix. Now the other question is what the runtime semantics should be. In this case, we're already in an error state for hydration so it's not considered normal semantics. I see two possible semantics: 1) it attempts to hydrate using the content of the Suspense boundary. 2) it client-renderers the Suspense boundary content without hydrating and then continues which will likely delete the existing siblings that already had such content. For (1) it gets quite strange if something suspends because in that case, it would try to hydrate using the fallback's content against the real content which could cause very strange effects. Normally we favor deleting and regenerating content in these cases because it avoids risks like transferring state or clicks to the wrong target which can cause severe negative effects. Therefore my preferred semantics here is actually that it regenerates on the client. This is not what currently assumes will happen though.
We have a fix for this. I'll release momentarily as 16.10.1. Release branch is here:
This is now fixed in .
please file a new issue with a reproducing example, either on codesandbox, or as a git repo. Thank you!


Question: for (var i = 0; i < expectedFeatures.length; i++) { if (!expectedFeatures[i]) { <del> console.error( </del> <ins> warning( false, </ins> 'One or more ES5 shims expected by React are not available: ' + 'https://fb.me/react-warning-polyfills' );

Do we want to do this now? mentioned this but I forgot about it until this morning.
That would be nice but shouldn't be blocking. We can make that 0.15.


Question: throwOnInvalidObjectType(returnFiber, newChild); } <ins> if (__DEV__) { if (!disableNewFiberFeatures && typeof newChild === 'function') { warnOnFunctionType(); } } </ins> if (!disableNewFiberFeatures && typeof newChild === 'undefined') { // If the new child is undefined, and the return fiber is a composite // component, throw an error. If Fiber return types are disabled,

When returns instead of accidentally, Fiber does not catch this.
Looks like a bug. Why does it happen?
It looks like does behind the flag, but with the latest alpha release, those paths aren't hit since it's . . edit: that check is actually fine, I still forget how invariant works sometimes It does also but it will actually crash if you try to return , which seems like another issue. Try changing to in the example above and it will crash the tab.
Warning, the link below will cause an infinite loop and might crash the tab/browser __ showing that returning will cause an infinite loop. And showing the endless barrage of errors: I can open a separate issue for this if you'd like
The infinite loop is probably or
Got it, thanks. As for the function issue, I think this would be fixed if those invariant checks in were moved out of a block, or to the correct code path if this warning should be done elsewhere now.
Right now we treat unknown types as empty. We have a special case for since it's almost always a bug (early return). I don't think we decided what we'll do for other unsupported values. We can either warn and treat as empty, or throw.
One disadvantage to throwing versus warning is that it requires an extra check in production, for null. EDIT: I guess we
I think using just a warning would make it too easy for components to silently fail. Existing behavior is to throw as well. is already in the bundle, it's just dead code right now. Can we safely move it outside of the check?
I was actually about to ask if we could make this type of render work? I have various components (Foo, Goo, Hoo, etc.) that I need to conditionally render. Right now I use : if would work, instead I could use the map method on the components array:
You can just wrap it in for the same effect.
I made a list of different things which I think we should (dis)allow as return values. It's based on what we did in 15, but with support for numbers/strings/arrays. The ones with asterisk are the ones we currently silently skip (but used to error on). The ones with two asterisks are the ones we always skipped. IMO we should at least warn about them.

Need to evaluate how many more conditions this would add. We probably need to start with warnings anyway because we might already happen to rely on some of them at FB since we enabled new features a while ago. I only feel strongly about here because it’s a really common one. For example if you misunderstand components and return rather than .
Since seems harmless, and seems rare, looks like the actionable item here is just to warn on . Whether as a host child (e.g. of a ) or as a return value.


Question: (typeof src === 'string' || src == null) && (typeof srcSet === 'string' || srcSet == null) && props.fetchPriority !== 'low' && <del> pictureTagInScope === false && </del> <ins> pictureOrNoScriptTagInScope === false && </ins> // We exclude data URIs in src and srcSet since these should not be preloaded !( typeof src === 'string' &&

<!-- 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: deleteListener(this, propKey); } } else if (isCustomComponent(this._tag, nextProps)) { <del> if (propKey === CHILDREN) { nextProp = null; </del> <ins> if (!RESERVED_PROPS.hasOwnProperty(propKey)) { DOMPropertyOperations.setValueForAttribute( getNode(this), propKey, nextProp ); </ins> } <del> DOMPropertyOperations.setValueForAttribute( getNode(this), propKey, nextProp ); </del> } else if (this._namespaceURI === DOMNamespaces.svg) { <del> DOMPropertyOperations.setValueForSVGAttribute( getNode(this), propKey, nextProp ); </del> <ins> if (!RESERVED_PROPS.hasOwnProperty(propKey)) { DOMPropertyOperations.setValueForSVGAttribute( getNode(this), propKey, nextProp ); } </ins> } else if ( DOMProperty.properties[propKey] || DOMProperty.isCustomAttribute(propKey)) {

See for a basic example. I'm assuming there's some step in the new SVG code that we just need to remove the key if we consume it as a React prop.
Going to leave this open to ensure we block even though wrote fix before I finished submitting (do you ever sleep Dan!?)
I sleep incrementally. FWIW the fix is in


Question: <ins> function Component(props) { let value; const object = { set value(v) { value = v; }, }; object.value = props.value; return <div>{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: string displayName ``` <del> 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). </del> <ins> 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

The link to "JSX in depth" in the "displayName" section on the "Component Specs and Lifecycle" page points to This url is not correct, the correct url is:
Thanks! Fixed in . You can close this.


Question: ReactFeatureFlags.debugRenderPhaseSideEffectsForStrictMode = false; React = require('react'); ReactNoop = require('react-noop-renderer'); <ins> ({Suspense} = React); </ins> }); function span(prop) {

<!-- 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: var ReactCurrentOwner = require('ReactCurrentOwner'); var assign = require('Object.assign'); <ins> var warning = require('warning'); </ins> var canDefineProperty = require('canDefineProperty'); // The Symbol used to tag the ReactElement type. If there is no native Symbol

The props and are reserved by React, and used internally. Component authors may attempt to access these properties (thinking they could read the value, as per ). We could use (in dev mode) to warn if or is accessed, and point the user to a note/discussion somewhere. That way, users who actually run into the issue will always get a timely message that sends them directly to the relevant explanation/discussion. This would be a good first bug, if we decide we actually want to do it.
This sounds like a great idea to me!
Yeah this seems reasonable.
hi, I am interested in working on this; as I am looking forward to contribute. Kindly show me the way. Thanks in advance!
Take a look at , that should give you a good start and a good idea of what we would be looking for.
Thanks Checking it out right away.
I have taken a look at the pull request, and associated code review comments. It seems the warn-once policy is required here, as implemented in I am not sure I fully understand how this module achieves this, so I am reading it now. As per the code review comments in , I am using the URLs instead of StackOverflow URLs. But the comments over there also mentioned that the PR might break some test cases. I am not sure about the edge cases here. I feel like I could use some help on understanding this. Instead of using GitHub issue comments, is it possible to use some chat-platform such as IRC or slack room or Gitter?
The module achieves deduplication by setting a boolean if it has already warned. The comments about breaking tests are referring to the failing unit tests. Just run and to verify that everything is working before pushing your changes. There are many places where you can discuss, including the IRC channel and/or reactiflux. There are also github issues (which is what our core team predominantly uses), as well as several other channels. The community is pretty big, but nothing is quite as good as reading through the code and github issues, IMHO.
Sorry, I was away. is ready to be reviewed.


Question: transformer: React.PropTypes.func, renderCode: React.PropTypes.bool, showCompiledJSTab: React.PropTypes.bool, <ins> showLineNumbers: React.PropTypes.bool, </ins> editorTabTitle: React.PropTypes.string },

is a tool for transforming jsx into js. If the supplied code contains syntax errors, the error displays an line number but since the code field doesn't have line numbers its hard to identify the actual line itself. !


Question: ); }); <del> it('should warn if the render function provided does not use the forwarded ref parameter', () => { function arityOfZero() { return null; } </del> <ins> it('should not warn if the render function provided does not use any parameter', () => { const arityOfZero = () => <div ref={arguments[1]} />; React.forwardRef(arityOfZero); }); </ins> <del> const arityOfOne = props => null; </del> <ins> it('should warn if the render function provided does not use the forwarded ref parameter', () => { const arityOfOne = props => <div {...props} />; </ins> <del> expect(() => React.forwardRef(arityOfZero)).toWarnDev( 'forwardRef render functions accept two parameters: props and ref. ' + </del> <ins> expect(() => React.forwardRef(arityOfOne)).toWarnDev( 'forwardRef render functions accept exactly two parameters: props and ref. ' + </ins> 'Did you forget to use the ref parameter?', {withoutStack: true}, ); <ins> }); </ins> <del> expect(() => React.forwardRef(arityOfOne)).toWarnDev( 'forwardRef render functions accept two parameters: props and ref. ' + 'Did you forget to use the ref parameter?', </del> <ins> it('should not warn if the render function provided use exactly two parameters', () => { const arityOfTwo = (props, ref) => <div {...props} ref={ref} />; React.forwardRef(arityOfTwo); }); it('should warn if the render function provided expects to use more than two parameters', () => { const arityOfThree = (props, ref, x) => <div {...props} ref={ref} x={x} />; expect(() => React.forwardRef(arityOfThree)).toWarnDev( 'forwardRef render functions accept exactly two parameters: props and ref. ' + 'Any additional parameter will be undefined.', </ins> {withoutStack: true}, ); });

<!-- 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? A feature (an improvement) What is the current behavior? When defining more than two parameters for a React.forwardRef render function a warning message stating "forwardRef render functions accept two parameters: props and ref. Did you forget to use the ref parameter?" gets logged. 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? Option 1 Overall the message could be more explicit on accepting exactly two parameters. Also, when the arity is greater than 2 the second part of the message may be omitted. For instance: ""forwardRef render functions accept exactly two parameters: props and ref" Option 2 If defining more than 2 arguments to the function is ok, which may be the case since the real goal for this warning is just to make sure people use the ref parameter, I think the message could not be shown for arity 2, therefore chaging the condition of to . Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? 0 which is the one that includes this new warning
Happy to take a PR for “option 1”. The purpose of accepting more arguments is not clear to me because they’d never get filled in.
Cool. I will make a PR tonight
We might want to add a note about an argument rest as well? also warning in a confusing manor since it's transpiled to use directly
I think it shouldn't warn about 0 arguments.
Should be fixed in 16.5.1
This warning is still visible in react 17.0.1
I've just got this error after running npm update. (React v17)
Just put a debugger and saw that these errors ar comming from MUI
Me too
Yes, I am reporting this issue as well. Will create a ticket for MUI if there isn't one already.

Hey all, if you're receiving this from MUI, do you happen to be using the x-date-picker imported from mui/lab? If so, switch to the separated mui/x-date-picker npm package. The date picker from mui/lab has been deprecated and it's improperly using forwardRef: <img width="1326" alt="Screen Shot 2022-06-15 at 10 04 42 AM" src="https://user-"
yes, that was the reason, already switched. Thanks for letting others know
Hello all, in my own component (Reactjs+TypeScript) I want to use forwarded ref optionally. I have achieved this with a default value - it works fine. The second param looks like this: Unfortunatelly in browser Im getting this irritating warning, even if I pass the ref from the top component. Can I suppress the warning or is there another solution with TypeScript in such cases? Especially the warning is very annoying in jest logs.


Question: var flattenChildren = require('flattenChildren'); var instantiateReactComponent = require('instantiateReactComponent'); var shouldUpdateReactComponent = require('shouldUpdateReactComponent'); <ins> var traverseAllChildren = require('traverseAllChildren'); var warning = require('warning'); function instantiateChild(childInstances, child, name) { // We found a component instance. var keyUnique = (childInstances[name] === undefined); if (__DEV__) { warning( keyUnique, 'flattenChildren(...): Encountered two children with the same key, ' + '`%s`. Child keys must be unique; when two children share a key, only ' + 'the first child will be used.', name ); } if (child != null && keyUnique) { childInstances[name] = instantiateReactComponent(child, null); } } </ins> /** * ReactChildReconciler provides helpers for initializing or updating a set of

Flattening children to an array is 20 times faster than flattening to an object. For long list of elements, this shows up on the initial render flame graphs as pretty hot.


Question: ); } }); <ins> PageOneContent = React.createFactory(PageOneContent); </ins> /** Application page two component. */ var PageTwoContent = React.createClass({

When I run the in examples jquery-mobile in the chromium browser, I get: Uncaught TypeError: Cannot read property '__reactAutoBindMap' of (anonymous function)
I can confirm. Works fine with React version “0.12.2", but "0.13.0-alpha.2" gives: Uncaught TypeError: Cannot read property '__reactAutoBindMap' of undefined ReactClass.createClass.Constructor (anonymous function) The jquery-mobile example is using component constructors in a way which makes the new version explode. gaearon lays is out here:
We'll make sure all the examples are working before we release 0.13 final but until then there's a non-trivial change they'll be broken at any point in time. Check out the latest stable branch for the working examples.


Question: } } <ins> function makeDelayedText(Model) { let error, _resolve, _reject; let promise = new Promise((resolve, reject) => { _resolve = () => { promise = null; resolve(); }; _reject = e => { error = e; promise = null; reject(e); }; }); function DelayedText({children}, data) { if (promise) { throw promise; } if (error) { throw error; } return <Model>{children}</Model>; } return [DelayedText, _resolve, _reject]; } </ins> it('should resolve HTML using W3C streams', async () => { function Text({children}) { return <span>{children}</span>;

When using for e.g. Cloudflare Workers runtimes, I'm noticing this error on the server: I'm assuming this results in the following malformed chunk being sent to the stream: Which results in the client failing: I put together a reproduction here, powered by for the Workers runtime: Could this be related to the "fundamentally flawed" nature of Web Streams implementations in e.g. Cloudflare Workers runtime? Is something going on with corking/uncorking, as per Maybe something's wrong with Miniflare's polyfill and this is a non-issue, coming from ? Finally, it's possible something is wrong with the Vite version of the example I've put together. I could try rebuilding with webpack if it's determined none of these items apply.
Have you looked at what chain of assumptions leads to this? It seems like it would be good to understand what different state machines are involved and why something's happening in CF that doesn't happen in the browser.
Have you looked at what chain of assumptions leads to this? after lots of digging, here's what we've discovered: The difference between Cloudflare/Oxygen Workers runtimes and the browser comes down to how the is consumed after being passed to . In the browser and , this is how the stream (via ) is consumed: This presumably results in a single . In the worker runtime, is read through an : Importantly, this results in getting called multiple times as more data is enqueued and as the reader sees fit. This is an assumption on my part, so I could be wrong here. When combined with Suspense boundaries, callbacks trigger . At the same time, repeated requests from the stream reader also call . This results in the following error on the server: You can also reproduce this directly in the browser by attempting to read the stream with . Here is a new fixture with a reproduction of the issue, including a couple test cases that show the different errors you'll see based on the number of Suspense boundaries you have: If this seems like a legitimate bug to you, a couple ideas I had: Should there be some sort of check like in ? Should we splice completed boundaries earlier to account for concurrency so they are removed from the array and not re-flushed? Here are some other resources and scratch notes:
~We'll fix this reentrancy bug somehow.

However, right now it's a bit lower priority because CloudFlare technically don't support ReadableStreams and so you have to go through the polyfill and any subtle differences might be due to the polyfill. To really know if we fixed this issue we should apply this to native CloudFlare ReadableStreams... which I'm told is coming. So that's how we know if it actually worked. Until then, the support for CloudFlare workers is... partial.~ On a second thought this should probably fix it. I think I finally understand how it's supposed to work now.
Please take another look and see if this fixes all the issues you've noticed.
works like a charm! Thanks for taking the time to look at it and get it fixed


Question: expect(element.props).toEqual({foo:'56'}); }); <ins> it('treats a null key as omitted but warns', function() { spyOn(console, 'warn'); var element = React.createFactory(ComponentFactory)({ key: null, foo: '56' }); expect(element.type).toBe(ComponentClass); expect(element.key).toBe(null);  // as opposed to string 'null' expect(element.ref).toBe(null); expect(element.props).toEqual({foo:'56'}); expect(console.warn.argsForCall.length).toBe(1); expect(console.warn.argsForCall[0][0]).toContain( 'will be treated as equivalent to the string 'null'' ); }); </ins> it('preserves the context on the element', function() { var Component = React.createFactory(ComponentFactory); var element;

In 0.11, the code assigned implicit keys to both children. In 0.12, it gives the error and renders only "foo", because the key is cast to a string in ReactElement before it gets checked against null in traverseAllChildren: I guess it's okay if this is intentional but it broke a part of KA in the upgrade. (cc
hm. Yea, this was intentional to ensure more stable types through out the system. I don't think null should be treated as a valid "non-value" to align it with defaultProps, default arguments and default values in destructuring. The intention of "null" is to symbolize a missing object. However, this can be of any type. It's weird that is coerced into . It should be left as . For refs, we expect them to become objects so it is valid to have there to represent a missing value. We have a two options: 1) Allow any value to be coerced to strings. 2) Throw on non-string values. 3) Don't coerce to string and start using maps as keys. E.g. Dates would become by reference instead of by value. would be treated as a key and would still be duplicate.
Maybe we can support meaning no key for a 0.12 with a warning, then drop support in 0.13? Just trying to avoid breaking things (that are impossible to grep for) without a warning. (I have no idea if we have other places in our code that do this by accident…)
They don't in prod though, right? I thought we had a fallback for duplicate values that would be essentially the same?
No, that code previously outputted and outputs just with 0.12. We ignore all children after the first with a given key.
oh. fine, warning for one version and then swap behavior. Want to send a PR?
Will do.


Question: return executeDispatchesAndRelease(e, false); }; <ins> var getDictionaryKey = function(inst) { return '.' + inst._rootNodeID; }; </ins> /** * This is a unified interface for event plugins to be installed and configured. *

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: props: Object, resumableState: ResumableState, renderState: RenderState, <del> pictureTagInScope: boolean, </del> <ins> pictureOrNoScriptTagInScope: boolean, </ins> ): null { const {src, srcSet} = props; if (

<!-- 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:
))}
 )}  {source !== null && ( <Source fileName={source.fileName} lineNumber={source.lineNumber} /> )}
 ); } // This function is based on packages/shared/describeComponentFrame.js function formatSourceForDisplay(fileName: string, lineNumber: string) { const BEFORE_SLASH_RE = /^(.*)[/]/; let nameOnly = fileName.replace(BEFORE_SLASH_RE, ''); // In DEV, include code for a common special case: // prefer "folder/index.js" instead of just "index.js". if (/^index./.test(nameOnly)) { const match = fileName.match(BEFORE_SLASH_RE); if (match) { const pathBeforeSlash = match[1]; if (pathBeforeSlash) { const folderName = pathBeforeSlash.replace(BEFORE_SLASH_RE, ''); nameOnly = folderName + '/' + nameOnly; } } } return `${nameOnly}:${lineNumber}`; } type SourceProps = {| fileName: string, lineNumber: string, |}; function Source({fileName, lineNumber}: SourceProps) { const handleCopy = () => copy(`${fileName}:${lineNumber}`); return (

source
 <Button onClick={handleCopy} title="Copy to clipboard"> <ButtonIcon type="copy" /> </Button>

 {formatSourceForDisplay(fileName, lineNumber)}

 ); }

Do you want to request a feature or report a bug? Feature. What is the current behavior? The new DevTools doesn't show the component file path as did the v3 version. What is the expected behavior? It would be great to show the component file path, it's a really important feature when working in a large codebase. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React DevTools v4 is affected, v3 had it.
Please be more specific in your feedback. This is not helpful.
I agree with , in this new version (v4), we cannot get file locations which really slows development time, fix this asap.
You can get your component file path by clicking in the "Log this component data to the console", icon is like a bug, and then copy the path from the Console.
File info isn't shown in the top level UI anymore because there are a lot of important things fighting for space in that UI. You can still see it using the debug button though. ! Is this enough to satisfy your use case Seems like it should be?
I think doing 4 clicks for something so basic is way to much. Putting it at the bottom (or top) of the info panel doesn't seem like it would block anything, since it's quite empty and would be very helpful (at least a copy path button would be small) !
To counter this, I don't think people use this info / look for this info often- so I'm not sure it needs to be available at a glance. I think putting less accessed info behind a click or two isn't so unreasonable. I don't think 4 clicks is right. You have to click to select an element to begin with. Then it's: the bug console or type "Esc" to open the bottom console to expand the logged element (at which point the file info is already visible) Your screenshot looks like a pretty extreme edge case. Many people run this extension docked to the bottom 1/4th or so of their browser window, where there is much less height and adding it to the bottom would require scrolling.
Even 3 clicks is a lot. I know I used it multiple times a day, so does my co-workers.

Maybe adding an option to display it at the bottom would be a good compromise? Even off my default is fine, but the ones that use it would be able to turn it on. IMO, dev tools should help developers do their jobs better/faster, and an option would fulfill that purpose without impeeding others.
I agree with the old place that this piece of information where was way more accessible and easier to reach than now.
Please show the component file path by scrolling. It is very important for large projects. Doing it in 3 clicks is waste of time.
I agree with , in large projects this is such a waste of time, just put it in the old place as it was much much better.
I don't think further comments just saying "please add this" add much value. Copy-pasting Dan's response from another issue as I think it also applies here: We appreciate your feedback but s are enough to help prioritize tasks.
I had the chance to look into this a bit last night and this morning and here are my thoughts. I don't think this was intentional, but the screenshot in the comment above is pretty misleading: <img width="234" alt="Screen Shot 2019-12-10 at 8 20 04 AM" src="https://user-"Source paths are never this short. In practice, the string would always either need to be truncated- so it would not end up showing the file name or line number: <img width="337" alt="Screen Shot 2019-12-10 at 8 23 58 AM" src="https://user-"Or it would need to be the file name only, without the path: <img width="337" alt="Screen Shot 2019-12-10 at 8 22 19 AM" src="https://user-"Neither of which is actually that helpful if your goal is to copy a file path so that you can open it in an external editing tool. If we were to display the full string, and allow it to wrap, it would take up even more space.

<img width="337" alt="Screen Shot 2019-12-10 at 8 27 43 AM" src="https://user-"The only place I feel somewhat okay about putting the info is at the bottom, but I think this will often mean that in practice, it's not visible without scrolling (since most components have several props/state that would push it down): <img width="334" alt="Screen Shot 2019-12-10 at 8 33 32 AM" src="https://user-"I guess I could always make it a configurable option- but more options means more maintenance burden and I don't think this clears the bar for one. Maybe the best compromise would be to show the name only, at the bottom, and have a copy button for the full path with line number: <img width="335" alt="Screen Shot 2019-12-10 at 8 44 27 AM" src="https://user-"This would still require a bit of scrolling but... I don't think there's any way around that without harming the common case UX.
Thanks
This is already much better. Having a single option to make it copy the full path would be the best way though, since it's simple and all editors support opening by full path.
This is literally that. The partial path is shown but the copy button copies the full path. That's what I was trying to say with this:
Ah sorry I misunderstood! Thank you very much!
Still, we can get a file source by clicking the right-side source icon. <img width="1440" alt="Screenshot 2019-12-11 at 11 52 02 AM" src="https://user-"


Question: return function(done) { spawn( <del> process.execPath, </del> <ins> path.join('node_modules', '.bin', 'flow' + extension), </ins> [ <del> path.join('node_modules', '.bin', 'flow' + extension), </del> 'check', '.', ],

"npm run lint" fails on Windows, at least Windows 7. Error: Screenshot: ! I found this but I couldn't fix it anyway. What might it be?
I encountered the same problem. If you look into the code in , you'll find the following code: which spawns a new process using the command "node node_modules.bin .". The command tries to interpret a batch file using node. However node can interpret js files only. That's why there's a SyntaxError. A change like this should work as expected:
Would you like to send a PR if you have a working fix?
Sure. I'll fix the same problem in gulp flow task too.
I rolled this into


Question: this.getName() || 'a component' ); warning( <ins> !inst.getDefaultProps || inst.getDefaultProps.isReactClassApproved, 'getDefaultProps was defined on %s, a plain JavaScript class. ' + 'This is only supported for classes created using React.createClass. ' + 'Use a static property to define defaultProps instead.', this.getName() || 'a component' ); warning( </ins> !inst.propTypes, 'propTypes was defined as an instance property on %s. Use a static ' + 'property to define propTypes instead.',

I am working on a very simple component with default props. And I simply render it without any props (). But I got an empty object from console output. I am using react 0.13.1, chrome 41, OSX 10.10. Any idea what is going wrong?
Es6 classes need defaultProps as a static property. Navigation.defaultProps = {...}
Thanks. Maybe update this in documentation :) ? I will be happy to send in a PR
has some commentary on docs and es6. I agree that I’d like to see better docs on the class syntax. I’m just a guy who happened to see your issue really quickly :)
does reference this. It might be good to also put some documentation in to make it a bit easier to find. I'm going to close this out since it's invalid but I'd love to see a PR with more docs :)
I think you should have also seen a runtime warning for this?
not really, though
Thanks, looks like an oversight. Fix incoming…


Question: | `tabIndex=(string 'false')`| (initial)| `<number: -1>` | | `tabIndex=(string 'on')`| (initial)| `<number: -1>` | | `tabIndex=(string 'off')`| (initial)| `<number: -1>` | <del> | `tabIndex=(symbol)`| (initial, warning)| `<number: -1>` | </del> <ins> | `tabIndex=(symbol)`| (initial, warning, ssr error, ssr mismatch)| `<number: -1>` | </ins> | `tabIndex=(function)`| (initial, warning)| `<number: -1>` | | `tabIndex=(null)`| (initial)| `<number: -1>` | | `tabIndex=(undefined)`| (initial)| `<number: -1>` |

See the original report in The problem is that SVG is case sensitive, and so naïvely setting and relying on insensitivity won't work with it. The good news is it seems like is the only valid with this problem. We just missed it because it applies both to HTML and SVG. I think the fix is to add it back to the whitelist.
simple example where tabbing works & doesn't work depending on case Note that the console does not state the error did you mean not being Not really sure why this is but it does display in our app.
Thanks for confirming this issue, I've been struggling to identify the reason my svg component stopped working after the update. A component made of clickable <circleshave lost both focus and blur functionality, because "tabIndex" is rendered in the camelCase style and then ignored by the browser. I've tried adding the property "tabindex" to the <circletag in the jsx, but it was swallow by React and not rendered to the final component.
React has been released. Please update , , and (if you use it) to this version and let us know if it solved the issue! We’d appreciate if you could test before Monday when we plan to get out.
apologies just seeing this message now. Yes. The issue is resolved with the beta, rc & 16.1


Question: expect(root).toMatchRenderedOutput('FooBar'); expect(ref.current).not.toBe(null); }); <ins> // Regression test for #14310 it('supports defaultProps defined on the memo() return value', async () => { const Add = React.memo(props => { return props.inner + props.outer; }); Add.defaultProps = { inner: 2, }; const LazyAdd = lazy(() => fakeImport(Add)); const root = ReactTestRenderer.create( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={2} /> </Suspense>, { unstable_isConcurrent: true, }, ); expect(root).toFlushAndYield(['Loading...']); expect(root).toMatchRenderedOutput(null); // Mount await Promise.resolve(); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('4'); // Update (shallowly equal) root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={2} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('4'); // Update root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={3} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('5'); // Update (shallowly equal) root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={3} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('5'); // Update (explicit props) root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={1} inner={1} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('2'); // Update (explicit props, shallowly equal) root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={1} inner={1} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('2'); // Update root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={1} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('3'); }); it('merges defaultProps in the correct order', async () => { let Add = React.memo(props => { return props.inner + props.outer; }); Add.defaultProps = { inner: 100, }; Add = React.memo(Add); Add.defaultProps = { inner: 2, outer: 0, }; const LazyAdd = lazy(() => fakeImport(Add)); const root = ReactTestRenderer.create( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={2} /> </Suspense>, { unstable_isConcurrent: true, }, ); expect(root).toFlushAndYield(['Loading...']); expect(root).toMatchRenderedOutput(null); // Mount await Promise.resolve(); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('4'); // Update root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd outer={3} /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('5'); // Update root.update( <Suspense fallback={<Text text="Loading..." />}> <LazyAdd /> </Suspense>, ); root.unstable_flushAll(); expect(root).toMatchRenderedOutput('2'); }); </ins> });

With this: If I render again after it resolves, it won't get the default prop value. This is a bug.


Question: isEffect, ); return; // Handled <ins> case 'TSAsExpression': visitFunctionWithDependencies( callback.expression, declaredDependenciesNode, reactiveHook, reactiveHookName, isEffect, ); return; // Handled </ins> case 'Identifier': if (!declaredDependenciesNode) { // No deps, no problems.

React version: 17.0.1 Setup eslint with as parser Cast a function passed to Link to code example: The following error was reported The rule should interpret the function argument correctly and know that it is already inline.
It looks like it is something that would be easy to support, but the question is: why would you do that?
Heh, a fair question. In my case, I needed it in order to support generics for a hook that helps manage state for asynchronous calls like mutations: Without the cast, TS doesn't know that the shape of the args object is the same. On the return statement, TS warns: This remains true even if I make the args a generic type too, so I think the issue is unavoidable.
TS is correct there. A function that has the same input type & return type as is not assignable to . might have other properties attached to it as well, which won't be attached to . For your particular situation, the type for can be a function that has the same argument & return types as , but should not be . Casting it as is lying to typescript.
Ahhh. Thanks With that hint I was able to fix my types and obviate the cast. That said, I would recommend keeping this issue open, since there will always be cases where folks will have to resort to casts like these, whether due to limitations in TS's expressiveness or (as in this case and I suspect most cases) one's ability to understand the type complexities and specify the types correctly. Sadly, not everyone has access to a to help them out when the types get complex.


Question: // autoFocus is polyfilled/normalized by AutoFocusMixin // autoFocus: HAS_BOOLEAN_VALUE, autoPlay: HAS_BOOLEAN_VALUE, <ins> capture: MUST_USE_ATTRIBUTE | HAS_BOOLEAN_VALUE, </ins> cellPadding: null, cellSpacing: null, charSet: MUST_USE_ATTRIBUTE,

Consider following snippet: Expected DOM Current behaviour Demo: W3C Specs:
I made a pull request, but was a bit faster. The pull requests are different, so maybe it is good that there are two. :smile:
That's wonderful, Thx!


Question: --dark-color-expand-collapse-toggle: #8f949d; --dark-color-link: #61dafb; --dark-color-modal-background: rgba(0, 0, 0, 0.75); <ins> --dark-color-primitive-hook-badge-background: rgba(0, 0, 0, 0.25); --dark-color-primitive-hook-badge-text: rgba(255, 255, 255, 0.7); </ins> --dark-color-record-active: #fc3a4b; --dark-color-record-hover: #a2e9fc; --dark-color-record-inactive: #61dafb;

I mostly use the "dark" theme which these badges looked good in. The "light" theme is broken though. No contrast.


Question: `), ).toMatchSnapshot(); }); <ins> it('uses custom identifiers for $RefreshReg$ and $RefreshSig$', () => { expect( transform( `export default function Bar () { useContext(X) return <Foo /> };`, { freshOptions: { refreshReg: 'import.meta.refreshReg', refreshSig: 'import.meta.refreshSig', }, }, ), ).toMatchSnapshot(); }); </ins> });

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: ); props.defaultValue = null; <del> props.value = value != null ? value : this.state.value; </del> <ins> props.value = null; </ins> props.onChange = this._handleChange; // Always set children to the same thing. In IE9, the selection range will

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: 'release:setup', 'clean', 'build', <del> 'gem-react-source:release', 'gem-react-source:pack', </del> 'release:bower', 'release:starter', 'compress',

I'm not sure how much value there really is in this. react-rails already stopped using it and just builds the files in itself. cc
(I'm currently running to find out how many there might be - looks like this script may take a day to hit the end point for every gem in the registry)
:+1: I made but it's just a toy :)