profile
viewpoint
Dan Abramov gaearon @facebook http://twitter.com/dan_abramov Working on @reactjs. Co-author of Redux and Create React App. Building tools for humans.

acdlite/redux-router 2329

Redux bindings for React Router – keep your router state inside your Redux store

gaearon/babel-plugin-react-transform 1100

Babel plugin to instrument React components with custom transforms

alexkuz/react-json-tree 970

React JSON Viewer Component, Extracted from redux-devtools

bvaughn/react-devtools-experimental 965

Experimental rewrite of the React DevTools extension

gaearon/ama 223

Ask me anything!

cavinsmith/bdsm.js 54

Background Dominant Stripe Manipulator

acdlite/react 22

A declarative, efficient, and flexible JavaScript library for building user interfaces.

gaearon/awesome-react 17

A collection of awesome React libraries, resources and shiny things.

issue commentfacebook/react

Consider using reactjs.org instead of fb.me in react's error/warning messages

No worries. We appreciate the intent — it’s just unfortunate because that particular change isn’t something we can do.

I think your proposal with _redirect makes sense. Is this something you would be interested in implementing?

dehghani-mehdi

comment created time in 11 hours

Pull request review commentfacebook/react

[eslint-plugin-react-hooks] Report constant constructions

 const tests = {             `The 'handleNext' function makes the dependencies of ` +             `useEffect Hook (at line 11) change on every render. ` +             `Move it inside the useEffect callback. Alternatively, ` +-            `wrap the 'handleNext' definition into its own useCallback() Hook.`,+            `wrap the construction of 'handleNext' in its own useCallback() Hook.`,
  • wrap the [name] function body
  • wrap the [name] object creation

?

captbaritone

comment created time in 15 hours

pull request commentfacebook/react

[eslint-plugin-react-hooks] Report constant constructions

Gonna review this tomorrow morning.

captbaritone

comment created time in 17 hours

Pull request review commentfacebook/react

[eslint-plugin-react-hooks] Report constant constructions

 const tests = {             `The 'handleNext' function makes the dependencies of ` +             `useEffect Hook (at line 11) change on every render. ` +             `Move it inside the useEffect callback. Alternatively, ` +-            `wrap the 'handleNext' definition into its own useCallback() Hook.`,+            `wrap the construction of 'handleNext' in its own useCallback() Hook.`,

I don't think "construction" is a common term in this case. People don't think about declaring functions as "constructing" them.

captbaritone

comment created time in 17 hours

pull request commentfacebook/react

[eslint-plugin-react-hooks] Report constant constructions

One way to tell is to go through references and see what its usage is like. It might work. But keep in mind it might be tricky to determine. Like if an array is used with arr.map() for rendering, we wouldn't know with a simple heuristic if this mutates or not.

captbaritone

comment created time in 17 hours

pull request commentfacebook/react

[eslint-plugin-react-hooks] Report constant constructions

Should we leave the autofix for functions on the assumption that it's not very common for folks to mutate functions?

Yeah I think that's reasonable to keep.

captbaritone

comment created time in 18 hours

Pull request review commentfacebook/react

[eslint-plugin-react-hooks] Report constant constructions

 const tests = {         },       ],     },-    {-      code: normalizeIndent`-        function MyComponent(props) {-          let handleNext = () => {-            console.log('hello');-          };-          if (props.foo) {-            handleNext = () => {-              console.log('hello');-            };-          }-          useEffect(() => {-            return Store.subscribe(handleNext);-          }, [handleNext]);-        }-      `,-      errors: [-        {-          message:-            "The 'handleNext' function makes the dependencies of useEffect Hook " +-            '(at line 13) change on every render. To fix this, wrap the ' +-            "'handleNext' definition into its own useCallback() Hook.",-          // Normally we'd suggest moving handleNext inside an-          // effect. But it's used more than once.-          // TODO: our autofix here isn't quite sufficient because-          // it only wraps the first definition. But seems ok.

I suppose we could say that if the initial assignment is a construction, then it's invalid, and if you later assign it another construction we won't try to catch that.

Seems reasonable.

captbaritone

comment created time in 18 hours

pull request commentfacebook/react

[eslint-plugin-react-hooks] Report constant constructions

Currently we offer an automatic suggestion to wrap the declaration in useMemo, but that would cause a bug:

Yeah — this is really, really bad.

How do you feel about starting without an autofix at all? We can maybe add it later if it's too burdensome.

captbaritone

comment created time in 18 hours

pull request commentfacebook/react

[eslint-plugin-react-hooks] Report constant constructions

Should our suggested fix include an empty dependency array?

Can we suggested a filled-in array in the first place?

captbaritone

comment created time in 18 hours

push eventfacebook/create-react-app

Dan Abramov

commit sha 8e761d19d14f47afdbbcfa6e19ed50c8ea1a63f4

Add 3.4.3 to the changelog

view details

push time in 18 hours

issue closedfacebook/create-react-app

High severity vulnerability detected by audit in react-scripts 3.4.2 dependencies

Edit from maintainers: this is a false positive.

See https://github.com/facebook/create-react-app/issues/9469#issuecomment-672984368.

Describe the bug

After installing last version (3.4.2) of react-scripts, I got a high severity vulnerability (Remote Code Execution) from serialize-javascript (2.1.2) from terser-webpack-plugin (2.3.5), that is a dependency of react-scripts (3.4.2)

Did you try recovering your dependencies?

Yes npm --version 6.14.7

Which terms did you search for in User Guide?

NA

Environment

Environment Info:

current version of create-react-app: 3.4.1 running from C:\Users\fcha\AppData\Roaming\npm-cache_npx\16340\node_modules\create-react-app

System: OS: Windows 10 10.0.18363 CPU: (8) x64 Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz Binaries: Node: 11.10.0 - C:\Program Files\nodejs\node.EXE Yarn: Not Found npm: 6.14.7 - C:\Program Files\nodejs\npm.CMD Browsers: Edge: 44.18362.449.0 Internet Explorer: 11.0.18362.1 npmPackages: react: ^16.13.1 => 16.13.1 react-dom: ^16.13.1 => 16.13.1 (15.6.1) react-scripts: ^3.4.2 => 3.4.2 npmGlobalPackages: create-react-app: Not Found

Steps to reproduce

NA

Expected behavior

No vulnerabilities detected by audit

Actual behavior

High severity vulnerabilities detected by audit

                   === npm audit security report ===                        


                             Manual Review                                  
         Some vulnerabilities require your attention to resolve             
                                                                            
      Visit https://go.npm.me/audit-guide for additional guidance           

High Remote Code Execution

Package serialize-javascript

Patched in >=3.1.0

Dependency of react-scripts

Path react-scripts > terser-webpack-plugin > serialize-javascript

More info https://npmjs.com/advisories/1548

found 1 high severity vulnerability in 2114 scanned packages 1 vulnerability requires manual review. See the full report for details.

Reproducible demo

NA

closed time in 18 hours

FredChauviere

issue commentfacebook/create-react-app

High severity vulnerability detected by audit in react-scripts 3.4.2 dependencies

Fixed the false positive in react-scripts@3.4.3.

FredChauviere

comment created time in 18 hours

pull request commentfacebook/create-react-app

Update terser-webpack-plugin version

(I'll do this)

portexe

comment created time in 18 hours

PR closed facebook/create-react-app

Reviewers
Update terser-webpack-plugin version CLA Signed

Older versions of terser-webpack-plugin are using a highly vulnerable version of serialize-javascript. In order to fix this, we need to update the terser-webpack-plugin which has now addressed this vulnerability.

More info on the vulnerability located here

Screenshot:

Vulnerability

+1 -1

9 comments

1 changed file

portexe

pr closed time in 18 hours

pull request commentfacebook/create-react-app

Update terser-webpack-plugin version

Hmm. Actually this doesn't make sense either.

3.0.7 which we use on master already has the fix.

https://unpkg.com/browse/terser-webpack-plugin@3.0.7/package.json https://www.npmjs.com/advisories/1548

So what we need to do is update the version used by react-scripts@3 today.

portexe

comment created time in 18 hours

issue commentfacebook/create-react-app

High severity vulnerability detected by audit in react-scripts 3.4.2 dependencies

Note that even though there's no actual vulnerability, we'd still want the warning to go away. I explained the next steps in https://github.com/facebook/create-react-app/pull/9470#pullrequestreview-466091335 if you'd like to help move that forward.

FredChauviere

comment created time in 18 hours

pull request commentfacebook/create-react-app

Update terser-webpack-plugin version

As explained in https://github.com/facebook/create-react-app/issues/9469#issuecomment-672984368, there is no actual vulnerability here.

portexe

comment created time in 18 hours

issue commentfacebook/create-react-app

High severity vulnerability detected by audit in react-scripts 3.4.2 dependencies

There is no actual vulnerability here.

If you read the advisory, the attack has to do with having specially crafted object in the source. However, Terser Webpack Plugin uses serialize-javascript for disk caching. If the attacker can somehow "poison" the source code of your app, you have much bigger problems anyway. In other words, this vulnerability applies to the scenarios where serialize-javascript is used at runtime with untrusted input, but here it is used at build time with trusted input (your own source code).

FredChauviere

comment created time in 18 hours

push eventreactjs/react-gradual-upgrade-demo

Dan Abramov

commit sha 365f155663d0716eb3b35dbe1826e3dd0f828adb

Update README.md

view details

push time in a day

push eventreactjs/react-gradual-upgrade-demo

Jack Moore

commit sha 550b8c732ee55ee18770852449b6f3d08f62dab2

Add link to Next.js port (#1)

view details

push time in a day

PR merged reactjs/react-gradual-upgrade-demo

Add link to Next.js port

I built a Next.js clone of this demo and noticed that you're accepting PRs for links to alternative builds. Let me know if you wish to have a different formatting for the alternative build listing.

+4 -0

0 comment

1 changed file

jtmthf

pr closed time in a day

issue commentfacebook/react

React Fire: Modernizing React DOM

@morevolk-latei In your measurements, how much time is spent parsing 100 KB of ReactDOM?

gaearon

comment created time in a day

issue commentDefinitelyTyped/DefinitelyTyped

React 17 and types-only breaking changes

Seems like porting https://github.com/reactjs/react-gradual-upgrade-demo to TS and figuring out what the issues are is going to be the next step.

eps1lon

comment created time in a day

issue commentDefinitelyTyped/DefinitelyTyped

React 17 and types-only breaking changes

One important note about this release that might not be obvious from the blog post.

It is very important that React 17 is easy to upgrade to because for legacy screens in huge apps it might be the last release they will upgrade to.

This is why even already announced deprecations (like removing UNSAFE versions, legacy context, renderSubtree) are not included in this release. They will be in 18 instead.

The goal of 17 is to fix event delegation so that Gradual Upgrades become a feasible strategy for legacy apps when React 18 comes out. So any extra breaking changes in React 17 defeat the purpose.

Can we postpone any major breakages to 18 in typings as well?

eps1lon

comment created time in a day

issue commentDefinitelyTyped/DefinitelyTyped

React 17 and types-only breaking changes

Remove event.persist()?

It hasn’t been deleted, just doesn’t do anything now. So I don’t think it should be removed.

eps1lon

comment created time in a day

issue commentfacebook/create-react-app

npm audit vulnerability : react-scripts > webpack-dev-server > yargs > yargs-parser

I’m locking because the discussion is starting to go offtopic and we risk losing important information in a closed issue.

sonikamah

comment created time in 2 days

issue commentfacebook/create-react-app

npm audit vulnerability : react-scripts > webpack-dev-server > yargs > yargs-parser

@mike-flores this is not a clear report. Please file a new issue and describe what you’re reporting in more detail (“broken” how?)

sonikamah

comment created time in 2 days

issue commentfacebook/react

Not touched, and not clicked component gets a ghost mousedown event

I was thinking in a week or so.

baharev

comment created time in 2 days

issue commentfacebook/create-react-app

Dependencies pulled down don't match repo

I published 3.4.2 earlier today. It won't be in master because that already switched to 4.x

reinrl

comment created time in 2 days

issue closedreactjs/reactjs.org

Uncontrolled input with onChange handler

I was wondering whether I can use the input with the onChange handler without providing any value, when I tried the code it is working fine but I am not sure whether this method is correct or not. input

closed time in 2 days

sarang-naico

issue commentreactjs/reactjs.org

Uncontrolled input with onChange handler

Yes, this is expected to work.

sarang-naico

comment created time in 2 days

issue commenttesting-library/react-testing-library

Explore alternative event dispatch/simulation

The only change we did for React 17 was dispatching focusin as well when calling fireEvent.focus

Do you also dispatch focusout for the "left" element?

kentcdodds

comment created time in 2 days

push eventreactjs/reactjs.org

Dan Abramov

commit sha c30ff1e39b9fca747198c028a33300656a90e612

Add onFocusIn note

view details

push time in 2 days

issue commentfacebook/react

onFocusIn/onFocusOut events

I made a small example demonstrating the current behavior based on https://github.com/facebook/react/issues/6410#issuecomment-292895495:

https://codesandbox.io/s/strange-albattani-7tqr7?file=/src/App.js

export default function App() {
  return (
    <div
      tabIndex={1}
      onFocus={(e) => {
        console.log("focusin (self or child)");
        if (e.currentTarget === e.target) {
          console.log("focus (self)");
        }
        if (!e.currentTarget.contains(e.relatedTarget)) {
          console.log("focusenter");
        }
      }}
      onBlur={(e) => {
        console.log("focusout (self or child)");
        if (e.currentTarget === e.target) {
          console.log("blur (self)");
        }
        if (!e.currentTarget.contains(e.relatedTarget)) {
          console.log("focusleave");
        }
      }}
    >
      <input />
      <input />
    </div>
  );
}

Hopefully this helps as a quick reference when you need to decide on which check to use.

I think there's definitely room for improvement here but if we're talking about API changes, a detailed RFC would be the best way to move this forward: http://github.com/reactjs/rfcs

sophiebits

comment created time in 2 days

issue commenttesting-library/react-testing-library

Explore alternative event dispatch/simulation

If tests are passing you're probably all good. :-)

I commented on this thread because binding to document was brought up as a limitation.

kentcdodds

comment created time in 2 days

issue commentfacebook/react

Bug: onChange props is being swallowed in Higher-Order-Component

Thanks for looking @vkurchatkin

eakl

comment created time in 2 days

issue closedfacebook/react

Bug: useState() not working properly with requestAnimationFrame v/s this.setState() working fine...!!!

<!-- 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: 16.12.0

Link to code example:

  1. useState()
  2. this.setState()

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

About the code

Here I'm using Web Audio API for audio manipulation. In my code, AudioWorkbench.waveAnalyser.frequencyBinCount give me the length of Audio array and getByteTimeDomainData() update the Data array so there is no direct way to call the setState or useState so I used a temporary variable to update it by requestAnimationFrame. But while doing this with Hooks useState hooks variable does not change. I even use useEffect to see the update. Whereas with the React component everything works fine.

<!-- Please provide a CodeSandbox (https://codesandbox.io/s/new), 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: https://stackoverflow.com/help/mcve. -->

The current behavior

useState hooks not updating the state on every call of requestAnimationFrame while the setState works fine.

The expected behavior

Both should give the same result. Either they update the state or they should not.

closed time in 2 days

KushagraMehta

issue commentfacebook/react

DOM attribute stringification fixes

We briefly chatted about this with @sebmarkbage and he suggested it's still a bit too risky to put in 17.0 (for which we have an RC) but might be okay to put in 17.1 if we're confident it's not a breaking change and if there is exhaustive browser testing.

koto

comment created time in 2 days

issue commentfacebook/react

How should we set up apps for HMR now that Fast Refresh replaces react-hot-loader?

it's in React, but the react-dom implementation is only experimental, for one.

To be clear, the implementation in react-dom itself is stable, just like in React Native. It's just that the integrations are not all stable.

should it have a separate place in the React documentation, pointing to the additional libraries to be used with particular bundlers and platforms, as well as explaining some still existing gotchas, like with self-updating css modules.

This sounds reasonable. I'd be happy to take a PR adding it to the Advanced Guides section, maybe based on similar RN page.

shirakaba

comment created time in 2 days

issue commentfacebook/react

Global event handlers on document.body (or other containing element) run BEFORE react event handlers

17.x releases might have some new features though.

vitalif

comment created time in 2 days

issue commentfacebook/react

Global event handlers on document.body (or other containing element) run BEFORE react event handlers

I'd expect 18 to ship within a year or less but my estimates haven't been very accurate historically. Definitely don't want another two year gap there though.

vitalif

comment created time in 2 days

issue commentfacebook/react

Not touched, and not clicked component gets a ghost mousedown event

https://reactjs.org/blog/2020/08/10/react-v17-rc.html

baharev

comment created time in 2 days

pull request commentfacebook/react

Attach event listeners at the root of the tree instead of document

React 17 does this. https://reactjs.org/blog/2020/08/10/react-v17-rc.html

vjeux

comment created time in 2 days

issue commentfacebook/react

Events propagate to nested components after stopPropagation()

If you want to try it: https://reactjs.org/blog/2020/08/10/react-v17-rc.html

lrowe

comment created time in 2 days

issue commentfacebook/react

e.stopPropagation() seems to not be working as expect.

If you want to try it: https://reactjs.org/blog/2020/08/10/react-v17-rc.html

luokuning

comment created time in 2 days

pull request commentfacebook/react

[RFC] Per React container event listening/dispatching

We attach events to roots in 17. https://reactjs.org/blog/2020/08/10/react-v17-rc.html

chenglou

comment created time in 2 days

pull request commentfacebook/react

Listen DOM events in each React container

This was done in 17. https://reactjs.org/blog/2020/08/10/react-v17-rc.html

fcsonline

comment created time in 2 days

issue commenttesting-library/react-testing-library

Explore alternative event dispatch/simulation

We're attaching to roots in 17.

https://reactjs.org/blog/2020/08/10/react-v17-rc.html

kentcdodds

comment created time in 2 days

issue closedfacebook/react

React Fire: Modernizing React DOM


For latest status, see an update from June 5th, 2019: https://github.com/facebook/react/issues/13525#issuecomment-499196939


This year, the React team has mostly been focused on fundamental improvements to React.

As this work is getting closer to completion, we're starting to think of what the next major releases of React DOM should look like. There are quite a few known problems, and some of them are hard or impossible to fix without bigger internal changes.

We want to undo past mistakes that caused countless follow-up fixes and created much technical debt. We also want to remove some of the abstraction in the event system which has been virtually untouched since the first days of React, and is a source of much complexity and bundle size.

We're calling this effort "React Fire".

🔥 React Fire

React Fire is an effort to modernize React DOM. Our goal is to make React better aligned with how the DOM works, revisit some controversial past decisions that led to problems, and make React smaller and faster.

We want to ship this set of changes in a future React major release because some of them will unfortunately be breaking. Nevertheless, we think they're worth it. And we have more than 50 thousands components at Facebook to keep us honest about our migration strategy. We can't afford to rewrite product code except a few targeted fixes or automated codemods.

Strategy

There are a few different things that make up our current plan. We might add or remove something but here's the thinking so far:

  • Stop reflecting input values in the value attribute (https://github.com/facebook/react/issues/11896). This was originally added in React 15.2.0 via https://github.com/facebook/react/pull/6406. It was very commonly requested because people's conceptual model of the DOM is that the value they see in the DOM inspector should match the value JSX attribute. But that's not how the DOM works. When you type into a field, the browser doesn't update the value attribute. React shouldn't do it either. It turned out that this change, while probably helpful for some code relying on CSS selectors, caused a cascade of bugs — some of them still unfixed to this day. Some of the fallout from this change includes: https://github.com/facebook/react/issues/7179, https://github.com/facebook/react/issues/8395, https://github.com/facebook/react/issues/7328, https://github.com/facebook/react/issues/7233, https://github.com/facebook/react/issues/11881, https://github.com/facebook/react/issues/7253, https://github.com/facebook/react/pull/9584, https://github.com/facebook/react/pull/9806, https://github.com/facebook/react/pull/9714, https://github.com/facebook/react/pull/11534, https://github.com/facebook/react/pull/11746, https://github.com/facebook/react/pull/12925. At this point it's clearly not worth it to keep fighting the browser, and we should revert it. The positive part of this journey is that thanks to tireless work from our DOM contributors (@nhunzaker, @aweary, @jquense, and @philipp-spiess) we now have detailed DOM test fixtures that will help us avoid regressions.

  • Attach events at the React root rather than the document (https://github.com/facebook/react/issues/2043). Attaching event handlers to the document becomes an issue when embedding React apps into larger systems. The Atom editor was one of the first cases that bumped into this. Any big website also eventually develops very complex edge cases related to stopPropagation interacting with non-React code or across React roots (https://github.com/facebook/react/issues/8693, https://github.com/facebook/react/pull/8117, https://github.com/facebook/react/issues/12518). We will also want to attach events eagerly to every root so that we can do less runtime checks during updates.

  • Migrate from onChange to onInput and don’t polyfill it for uncontrolled components (https://github.com/facebook/react/issues/9657). See the linked issue for a detailed plan. It has been confusing that React uses a different event name for what's known as input event in the DOM. While we generally avoid making big changes like this without significant benefit, in this case we also want to change the behavior to remove some complexity that's only necessary for edge cases like mutating controlled inputs. So it makes sense to do these two changes together, and use that as an opportunity to make onInput and onChange work exactly how the DOM events do for uncontrolled components.

  • Drastically simplify the event system (https://github.com/facebook/react/issues/4751). The current event system has barely changed since its initial implementation in 2013. It is reused across React DOM and React Native, so it is unnecessarily abstract. Many of the polyfills it provides are unnecessary for modern browsers, and some of them create more issues than they solve. It also accounts for a significant portion of the React DOM bundle size. We don't have a very specific plan here, but we will probably fork the event system completely, and then see how minimal we can make it if we stick closer to what the DOM gives us. It's plausible that we'll get rid of synthetic events altogether. We should stop bubbling events like media events which don’t bubble in the DOM and don’t have a good reason to bubble. We want to retain some React-specific capabilities like bubbling through portals, but we will attempt to do this via simpler means (e.g. re-dispatching the event). Passive events will likely be a part of this.

  • classNameclass (https://github.com/facebook/react/issues/4331, see also https://github.com/facebook/react/issues/13525#issuecomment-417818906 below). This has been proposed countless times. We're already allowing passing class down to the DOM node in React 16. The confusion this is creating is not worth the syntax limitations it's trying to protect against. We wouldn't do this change by itself, but combined with everything else above it makes sense. Note we can’t just allow both without warnings because this makes it very difficult for a component ecosystem to handle. Each component would need to learn to handle both correctly, and there is a risk of them conflicting. Since many components process className (for example by appending to it), it’s too error-prone.

Tradeoffs

  • We can't make some of these changes if we aim to keep exposing the current private React event system APIs for projects like React Native Web. However, React Native Web will need a different strategy regardless because React Fabric will likely move more of the responder system to the native side.

  • We may need to drop compatibility with some older browsers, and/or require more standalone polyfills for them. We still care about supporting IE11 but it's possible that we will not attempt to smooth over some of the existing browser differences — which is the stance taken by many modern UI libraries.

Rollout Plan

At this stage, the project is very exploratory. We don't know for sure if all of the above things will pan out. Because the changes are significant, we will need to dogfood them at Facebook, and try them out in a gradual fashion. This means we'll introduce a feature flag, fork some of the code, and keep it enabled at Facebook for a small group of people. The open source 16.x releases will keep the old behavior, but on master you will be able to run it with the feature flag on.

I plan to work on the project myself for the most part, but I would very much appreciate more discussion and contributions from @nhunzaker, @aweary, @jquense, and @philipp-spiess who have been stellar collaborators and have largely steered React DOM while we were working on Fiber. If there's some area you're particularly interested in, please let me know and we'll work it out.

There are likely things that I missed in this plan. I'm very open to feedback, and I hope this writeup is helpful.

closed time in 2 days

gaearon

issue commentfacebook/react

React Fire: Modernizing React DOM

Hey all, it's been a while and we've tried some of these things on and off.

Let me give an update on each:

  • Stop reflecting input values in the value attribute (https://github.com/facebook/react/issues/11896). This was originally added in React 15.2.0 via https://github.com/facebook/react/pull/6406. It was very commonly requested because people's conceptual model of the DOM is that the value they see in the DOM inspector should match the value JSX attribute. But that's not how the DOM works. When you type into a field, the browser doesn't update the value attribute. React shouldn't do it either. It turned out that this change, while probably helpful for some code relying on CSS selectors, caused a cascade of bugs — some of them still unfixed to this day. Some of the fallout from this change includes: https://github.com/facebook/react/issues/7179, https://github.com/facebook/react/issues/8395, https://github.com/facebook/react/issues/7328, https://github.com/facebook/react/issues/7233, https://github.com/facebook/react/issues/11881, https://github.com/facebook/react/issues/7253, https://github.com/facebook/react/pull/9584, https://github.com/facebook/react/pull/9806, https://github.com/facebook/react/pull/9714, https://github.com/facebook/react/pull/11534, https://github.com/facebook/react/pull/11746, https://github.com/facebook/react/pull/12925. At this point it's clearly not worth it to keep fighting the browser, and we should revert it. The positive part of this journey is that thanks to tireless work from our DOM contributors (@nhunzaker, @aweary, @jquense, and @philipp-spiess) we now have detailed DOM test fixtures that will help us avoid regressions.

We still want to do this, but we've decided to "reserve" React 17 to have minimal possible breaking changes so that it can focus on the next item on this list. So this change will wait until React 18.

  • Attach events at the React root rather than the document (https://github.com/facebook/react/issues/2043). Attaching event handlers to the document becomes an issue when embedding React apps into larger systems. The Atom editor was one of the first cases that bumped into this. Any big website also eventually develops very complex edge cases related to stopPropagation interacting with non-React code or across React roots (https://github.com/facebook/react/issues/8693, https://github.com/facebook/react/pull/8117, https://github.com/facebook/react/issues/12518). We will also want to attach events eagerly to every root so that we can do less runtime checks during updates.

We're doing this in React 17. This turned out to be a huge chunk of work but thankfully it's finished.

  • Migrate from onChange to onInput and don’t polyfill it for uncontrolled components (https://github.com/facebook/react/issues/9657). See the linked issue for a detailed plan. It has been confusing that React uses a different event name for what's known as input event in the DOM. While we generally avoid making big changes like this without significant benefit, in this case we also want to change the behavior to remove some complexity that's only necessary for edge cases like mutating controlled inputs. So it makes sense to do these two changes together, and use that as an opportunity to make onInput and onChange work exactly how the DOM events do for uncontrolled components.

We'll likely come back to this but it's unclear how much churn is worth doing here. So this is still TBD.

  • Drastically simplify the event system (https://github.com/facebook/react/issues/4751). The current event system has barely changed since its initial implementation in 2013. It is reused across React DOM and React Native, so it is unnecessarily abstract. Many of the polyfills it provides are unnecessary for modern browsers, and some of them create more issues than they solve. It also accounts for a significant portion of the React DOM bundle size. We don't have a very specific plan here, but we will probably fork the event system completely, and then see how minimal we can make it if we stick closer to what the DOM gives us. It's plausible that we'll get rid of synthetic events altogether. We should stop bubbling events like media events which don’t bubble in the DOM and don’t have a good reason to bubble. We want to retain some React-specific capabilities like bubbling through portals, but we will attempt to do this via simpler means (e.g. re-dispatching the event). Passive events will likely be a part of this.

We've tried this early in 2019, and a truly minimal event system did not work out very well in our internal testing. There was quite a bit of cross-browser normalization React is doing that is still useful for people with older browsers, or in more niche areas like rich text input editors using contentEditable. That said, as a part of our work on attaching events to roots, we've removed a lot of abstraction from the event system so it's easier to understand and improve in the future. As a part of React 17, we're removing "event pooling" which has caused a lot of confusion, and we're also no longer bubbling the onScroll event. We will likely follow with stopping bubbling of media events in React 18, bringing React behavior closer to the browser one. We did save some bytes with the new event system, but they were taken by new features we're working on, so it won't lead to a bundle size decrease overall.

  • classNameclass (https://github.com/facebook/react/issues/4331, see also https://github.com/facebook/react/issues/13525#issuecomment-417818906 below). This has been proposed countless times. We're already allowing passing class down to the DOM node in React 16. The confusion this is creating is not worth the syntax limitations it's trying to protect against. We wouldn't do this change by itself, but combined with everything else above it makes sense. Note we can’t just allow both without warnings because this makes it very difficult for a component ecosystem to handle. Each component would need to learn to handle both correctly, and there is a risk of them conflicting. Since many components process className (for example by appending to it), it’s too error-prone.

This was the most controversial part of the proposal. Since then, we released Hooks, which encourage writing function components. In function components, we generally suggest using destructuring for props, but you can't write { class, ... } because it would be a syntax error. So overall it's not clear that this is ergonomic enough to actually follow through with. I think it's plausible we'll revisit this in the future, or at least make class not warn and let people do what they want. But for now, we'll shelving this idea.

gaearon

comment created time in 2 days

issue commentfacebook/react

Clean up top-level event listeners after unmounting all roots

If you want to try it: https://reactjs.org/blog/2020/08/10/react-v17-rc.html

mP1

comment created time in 2 days

issue commentfacebook/react

Attach event per react container root, rather than on the document

We did this. https://reactjs.org/blog/2020/08/10/react-v17-rc.html

chenglou

comment created time in 2 days

issue closedfacebook/react

Attach event per react container root, rather than on the document

@nathansobo will that help your event perf issues a bit? I'm not familiar with atom's plugin infrastructure, But this'll help if you have <Editor/><Plugin1/> (two renderComponents). Doesn't help if you have <Editor><Plugin1/></Editor> though, but I have some ideas to optimize events a bit more.

This is nonetheless an ok idea, I think. @spicyj

closed time in 2 days

chenglou

issue commentfacebook/react

ancestor's stopPropagation() prevents controlled <select> from working

If you want to try it, we released 17 RC yesterday with this change: https://reactjs.org/blog/2020/08/10/react-v17-rc.html

jkr2255

comment created time in 2 days

issue commentfacebook/react

Event listener attached to `document` will still be called after calling `event.stopPropagation()`

If you want to try it, we released 17 RC yesterday with this change: https://reactjs.org/blog/2020/08/10/react-v17-rc.html

VincentBel

comment created time in 2 days

issue commentfacebook/react

Native event.stopPropagation outside of React root cuts out React events

If you want to try it, we released 17 RC yesterday with this change: https://reactjs.org/blog/2020/08/10/react-v17-rc.html

kenticomartinh

comment created time in 2 days

issue commentfacebook/react

Global event handlers on document.body (or other containing element) run BEFORE react event handlers

If you want to try it, we released 17 RC yesterday with this change: https://reactjs.org/blog/2020/08/10/react-v17-rc.html

vitalif

comment created time in 2 days

delete tag facebook/create-react-app

delete tag : v3.4.2

delete time in 2 days

push eventfacebook/create-react-app

Dan Abramov

commit sha 5e703a568a687dacdc45f1211355ce4b1b586625

Add 3.4.2 to changelog

view details

push time in 2 days

created tagfacebook/create-react-app

tagv3.4.2

Set up a modern web app by running one command.

created time in 2 days

release facebook/create-react-app

v3.4.2

released time in 2 days

push eventreactjs/reactjs.org

QiChang Li

commit sha 304535ade1b30863f8622340b86b93742808e7a9

chore: supplementary title (#3191)

view details

push time in 2 days

push eventreactjs/reactjs.org

Dan Abramov

commit sha 1a6be469241afb6bae741191d94eedc43ebd5c07

Clarifications

view details

push time in 2 days

issue closedfacebook/create-react-app

"found 1 low severity vulnerability" warning while creating React App using "npx create-react-app" command.

<!-- Please note that your issue will be fixed much faster if you spend about half an hour preparing it, including the exact reproduction steps and a demo.

If you're in a hurry or don't feel confident, it's fine to report bugs with
less details, but this makes it less likely they'll get fixed soon.

In either case, please use this template and fill in as many fields below as you can.

Note that we don't provide help for webpack questions after ejecting.
You can find webpack docs at https://webpack.js.org/.

-->

Describe the bug

While creating React-App using npx create-react-app command this warning comes:

found 1 low severity vulnerability
    run `npm audit fix` to fix them, or `npm audit` for details

Did you try recovering your dependencies?

Tried: npm install -g npm@latest

Which terms did you search for in User Guide?

<!-- There are a few common documented problems, such as watcher not detecting changes, or build failing. They are described in the Troubleshooting section of the User Guide:

https://facebook.github.io/create-react-app/docs/troubleshooting

Please scan these few sections for common problems. Additionally, you can search the User Guide itself for something you're having issues with:

https://facebook.github.io/create-react-app/

If you didn't find the solution, please share which words you searched for. This helps us improve documentation for future readers who might encounter the same problem. -->

(Write your answer here if relevant.)

Environment

<!-- To help identify if a problem is specific to a platform, browser, or module version, information about your environment is required. This enables the maintainers quickly reproduce the issue and give feedback.

Run the following command in your React app's folder in terminal. Note: The result is copied to your clipboard directly.

npx create-react-app --info

Paste the output of the command in the section below. -->

current version of create-react-app: 3.4.1

System:

    OS: Windows 10 10.0.19041
    CPU: (8) x64 Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
Binaries:

    Node: 12.18.2 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 6.14.7 - C:\Program Files\nodejs\npm.CMD
Browsers:

    Edge: 44.19041.1.0
    Internet Explorer: 11.0.19041.1

npmPackages:

    react: ^16.13.1 => 16.13.1
    react-dom: ^16.13.1 => 16.13.1
    react-scripts: 3.4.1 => 3.4.1

npmGlobalPackages:

    create-react-app: Not Found

Steps to reproduce

  1. When we run create-react-app this issue arises.

Expected behavior

<!-- How did you expect the tool to behave? It’s fine if you’re not sure your understanding is correct. Just write down what you thought would happen. -->

To create a React App without any low severity vulnerability

Actual behavior

<!-- Did something go wrong? Is something broken, or not behaving as you expected? Please attach screenshots if possible! They are extremely helpful for diagnosing issues. -->

found 1 low severity vulnerability run npm audit fix to fix them, or npm audit for details

                === npm audit security report ===                        


                        Manual Review                                  
    Some vulnerabilities require your attention to resolve             
                                                                            
    Visit https://go.npm.me/audit-guide for additional guidance           
    Low             Prototype Pollution                                           

    Package         yargs-parser                                                  

    Patched in      >=13.1.2 <14.0.0 || >=15.0.1 <16.0.0 || >=18.1.2              

    Path            react-scripts > webpack-dev-server > yargs > yargs-parser

    More info       https://npmjs.com/advisories/1500

    found 1 low severity vulnerability in 1641 scanned packages
    1 vulnerability requires manual review. See the full report for details.

Reproducible demo

<!-- If you can, please share a project that reproduces the issue. This is the single most effective way to get an issue fixed soon.

There are two ways to do it:

* Create a new app and try to reproduce the issue in it.
  This is useful if you roughly know where the problem is, or can’t share the real code.

* Or, copy your app and remove things until you’re left with the minimal reproducible demo.
  This is useful for finding the root cause. You may then optionally create a new project.

This is a good guide to creating bug demos: https://stackoverflow.com/help/mcve Once you’re done, push the project to GitHub and paste the link to it below: -->

npx create-react-app

<!-- What happens if you skip this step?

We will try to help you, but in many cases it is impossible because crucial information is missing. In that case we'll tag an issue as having a low priority, and eventually close it if there is no clear direction.

We still appreciate the report though, as eventually somebody else might create a reproducible example for it.

Thanks for helping us help you! -->

closed time in 2 days

sunilpoojari

issue commentfacebook/create-react-app

"found 1 low severity vulnerability" warning while creating React App using "npx create-react-app" command.

Please see my reply in https://github.com/facebook/create-react-app/issues/9033#issuecomment-671847777.

There was no actual vulnerability here but we released react-scripts@3.4.2 to address the warning.

sunilpoojari

comment created time in 2 days

issue closedfacebook/create-react-app

found 4982 low severity vulnerabilities using create-react-app

<!-- Please note that your issue will be fixed much faster if you spend about half an hour preparing it, including the exact reproduction steps and a demo.

If you're in a hurry or don't feel confident, it's fine to report bugs with
less details, but this makes it less likely they'll get fixed soon.

In either case, please use this template and fill in as many fields below as you can.

Note that we don't provide help for webpack questions after ejecting.
You can find webpack docs at https://webpack.js.org/.

-->

Describe the bug

create-react-app showing message "found 4982 low severity vulnerabilities" after installing all dependencies.

Did you try recovering your dependencies?

<!-- Your module tree might be corrupted, and that might be causing the issues. Let's try to recover it. First, delete these files and folders in your project:

* node_modules
* package-lock.json
* yarn.lock

Then you need to decide which package manager you prefer to use. We support both npm (https://npmjs.com) and yarn (http://yarnpkg.com/). However, they can't be used together in one project so you need to pick one.

If you decided to use npm, run this in your project directory:

npm install -g npm@latest
npm install

This should fix your project.

If you decided to use yarn, update it first (https://yarnpkg.com/en/docs/install). Then run in your project directory:

yarn

This should fix your project.

Importantly, if you decided to use yarn, you should never run npm install in the project. For example, yarn users should run yarn add <library> instead of npm install <library>. Otherwise your project will break again.

Have you done all these steps and still see the issue? Please paste the output of npm --version and/or yarn --version to confirm. -->

Yes I did delete node_modules and package-lock.json and installed latest version of npm and then ran npm install but I still see the "found 4982 low severity vulnerabilities" message

Which terms did you search for in User Guide?

<!-- There are a few common documented problems, such as watcher not detecting changes, or build failing. They are described in the Troubleshooting section of the User Guide:

https://facebook.github.io/create-react-app/docs/troubleshooting

Please scan these few sections for common problems. Additionally, you can search the User Guide itself for something you're having issues with:

https://facebook.github.io/create-react-app/

If you didn't find the solution, please share which words you searched for. This helps us improve documentation for future readers who might encounter the same problem. -->

Environment

<!-- To help identify if a problem is specific to a platform, browser, or module version, information about your environment is required. This enables the maintainers quickly reproduce the issue and give feedback.

Run the following command in your React app's folder in terminal. Note: The result is copied to your clipboard directly.

npx create-react-app --info

Paste the output of the command in the section below. -->

Environment Info:

current version of create-react-app: 3.4.1 running from C:\Users\DELL\AppData\Roaming\npm\node_modules\create-react-app

System: OS: Windows 10 10.0.18362 CPU: (8) x64 Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz Binaries: Node: 12.18.1 - C:\Program Files\nodejs\node.EXE Yarn: Not Found npm: 6.14.5 - C:\Program Files\nodejs\npm.CMD Browsers: Edge: 44.18362.449.0 Internet Explorer: 11.0.18362.1 npmPackages: react: ^16.13.1 => 16.13.1 react-dom: ^16.13.1 => 16.13.1 react-scripts: 3.4.1 => 3.4.1 npmGlobalPackages: create-react-app: Not Found

Steps to reproduce

<!-- How would you describe your issue to someone who doesn’t know you or your project? Try to write a sequence of steps that anybody can repeat to see the issue. -->

(Write your steps here:)

  1. open command-line or terminal
  2. run npx create-react-app app-name
  3. wait till all dependencies are installed

Expected behavior

<!-- How did you expect the tool to behave? It’s fine if you’re not sure your understanding is correct. Just write down what you thought would happen. -->

it should show message similar to found 0 vulnerabilities

Actual behavior

<!-- Did something go wrong? Is something broken, or not behaving as you expected? Please attach screenshots if possible! They are extremely helpful for diagnosing issues. -->

terminal showing message "found 4982 low severity vulnerabilities"

image

Reproducible demo

<!-- If you can, please share a project that reproduces the issue. This is the single most effective way to get an issue fixed soon.

There are two ways to do it:

* Create a new app and try to reproduce the issue in it.
  This is useful if you roughly know where the problem is, or can’t share the real code.

* Or, copy your app and remove things until you’re left with the minimal reproducible demo.
  This is useful for finding the root cause. You may then optionally create a new project.

This is a good guide to creating bug demos: https://stackoverflow.com/help/mcve Once you’re done, push the project to GitHub and paste the link to it below: -->

https://github.com/Prajwal-Jadhav/test-app

<!-- What happens if you skip this step?

We will try to help you, but in many cases it is impossible because crucial information is missing. In that case we'll tag an issue as having a low priority, and eventually close it if there is no clear direction.

We still appreciate the report though, as eventually somebody else might create a reproducible example for it.

Thanks for helping us help you! -->

closed time in 2 days

Prajwal-Jadhav

issue commentfacebook/create-react-app

found 4982 low severity vulnerabilities using create-react-app

There was no actual vulnerability here.

Please see my reply in https://github.com/facebook/create-react-app/issues/9033#issuecomment-671847777.

I've cut a release of react-scripts which includes a dependency bump necessary for the audit message to go away.

Prajwal-Jadhav

comment created time in 2 days

issue commentfacebook/create-react-app

npm audit vulnerability : react-scripts > webpack-dev-server > yargs > yargs-parser

Hey all, I'd like to apologize for the delay here. We really dropped the ball on this, and I'm sorry for the frustration it caused. I've just cut react-scripts@3.4.2 which bumps us to webpack-dev-server@3.11.0 with the fix.

Again, I need to be clear that there was no actual vulnerability here at any point in time. It is unfortunate that in the JavaScript ecosystem, "audits" have an extremely low signal-noise ratio, and especially with the build tooling, very rarely reveal actual issues. That said, I totally recognize that this is not an argument you can use in an enterprise deployment situation.

As @tkw1536 notes, Yarn has a feature called "resolutions" which lets you override transitive dependencies. I strongly recommend to use it whenever you have a problem like this which hasn't been addressed soon enough (for which, as I said earlier, I'm sorry).

To prevent this from happening again, I'm adding a dedicated reporting mechanism for security issues (https://github.com/facebook/create-react-app/commit/5e41ca016c1a650774b1e04d126a12ca93743c30) to this repo. We're not watching every thread and CRA is largely community-maintained, so please don't hesitate to escalate an issue if it is an urgent security matter. Thank you!

sonikamah

comment created time in 2 days

push eventfacebook/create-react-app

Dan Abramov

commit sha 5e41ca016c1a650774b1e04d126a12ca93743c30

Create SECURITY.md

view details

push time in 2 days

issue commentfacebook/react

Bug: React-17.0.0-rc.0 react-reconciler focusedInstanceHandle crash

You can useLayoutEffect if being sync is important.

drcmda

comment created time in 2 days

issue commentfacebook/create-react-app

npm audit vulnerability : react-scripts > webpack-dev-server > yargs > yargs-parser

To be clear, the vulnerability has no actual effect on CRA apps. The description says it’s for a DDOS attack which is completely irrelevant because CRA doesn’t use WDS for production environments. (It doesn’t even have a production web server.)

While I agree that ideally a release should be cut to satisfy people affected by enterprise requirements, we are looking at a case of an overzealous audit checker, not an actual vulnerability that affects your apps.

sonikamah

comment created time in 2 days

push eventreactjs/reactjs.org

Craig Kovatch

commit sha 4ac8fd7f352e2650b4631448dae92dc6617c097d

Update 2020-08-10-react-v17-rc.md (#3190) Use modern syntax for a capture-phase event listener example: flags object rather than raw boolean

view details

push time in 2 days

PR merged reactjs/reactjs.org

Use modern syntax for a capture-phase event listener example: flags object rather than raw boolean CLA Signed

Using the flags object is still compatible with old browsers (evals to truthy), but makes the intent of the developer more clear, and allows for other flag additions (e.g. passive)

+2 -2

2 comments

1 changed file

craigkovatch

pr closed time in 2 days

Pull request review commentfacebook/react

Append text string to <Text> error message

   "271": "Failed to replay rendering after an error. This is likely caused by a bug in React. Please file an issue with a reproducing case to help us find it.",   "272": "The current renderer does not support hydration. This error is likely caused by a bug in React. Please file an issue.",   "273": "Nesting of <View> within <Text> is not currently supported.",-  "274": "Text strings must be rendered within a <Text> component.",

yarn extract-errors

yungsters

comment created time in 3 days

Pull request review commentfacebook/react

Append text string to <Text> error message

   "271": "Failed to replay rendering after an error. This is likely caused by a bug in React. Please file an issue with a reproducing case to help us find it.",   "272": "The current renderer does not support hydration. This error is likely caused by a bug in React. Please file an issue.",   "273": "Nesting of <View> within <Text> is not currently supported.",-  "274": "Text strings must be rendered within a <Text> component.",

Let's not touch this one. Instead a new one should be generated by running a script. (I think CI should tell its name?) Otherwise the message will be confusing for people running old versions and visiting the website.

yungsters

comment created time in 3 days

issue commentfacebook/react

Bug: React-17.0.0-rc.0 react-reconciler focusedInstanceHandle crash

Not aware of other places. If you narrow it down, file for sure!

drcmda

comment created time in 3 days

issue commentfacebook/react

Bug: React-17.0.0-rc.0 react-reconciler focusedInstanceHandle crash

(Maybe this is a good argument to make the check looser.)

drcmda

comment created time in 3 days

issue commentfacebook/react

Bug: React-17.0.0-rc.0 react-reconciler focusedInstanceHandle crash

I think if you return null from prepareToCommit that would fix it.

drcmda

comment created time in 3 days

pull request commentfacebook/react

Append text string to <Text> error message

Should there be a length limit? What if it's super long?

yungsters

comment created time in 3 days

startedreactjs/react-gradual-upgrade-demo

started time in 3 days

pull request commentfacebook/react

Release script should understand prereleases

Sounds good then.

gaearon

comment created time in 3 days

PR closed facebook/react

Release script should understand prereleases CLA Signed React Core Team

Without this change, I can't publish an RC as next.

+16 -0

8 comments

1 changed file

gaearon

pr closed time in 3 days

push eventreactjs/reactjs.org

Dan Abramov

commit sha 7d7c3c541f1613b246ec6640bfbf73a57dd60152

Update 2020-08-10-react-v17-rc.md

view details

push time in 3 days

push eventreactjs/react-gradual-upgrade-demo

Dan Abramov

commit sha 3cf1e9f266882fb13e6181bab052acd2e0eeef95

Link to the blog post

view details

push time in 3 days

delete branch reactjs/reactjs.org

delete branch : 17-rc

delete time in 3 days

push eventreactjs/reactjs.org

Dan Abramov

commit sha e36edae83c1fa1dea1809d5ade74b1a449ff10eb

React 17 RC release blog post (#3185) * New blog post * Apply suggestions from code review Co-authored-by: Toru Kobayashi <koba0004@gmail.com> * Add an illustration by @rachelnabors * Co-credit the post * Add changelog * say it again * Add a section Co-authored-by: Toru Kobayashi <koba0004@gmail.com> Co-authored-by: Rachel Nabors <rachelnabors@gmail.com>

view details

push time in 3 days

PR merged reactjs/reactjs.org

New release blog post CLA Signed react core team

Still needs the changelog

+355 -1

1 comment

3 changed files

gaearon

pr closed time in 3 days

pull request commentfacebook/react

Release script should understand prereleases

In your opinion, should prereleases be forbidden with getting tagged as next altogether?

gaearon

comment created time in 3 days

pull request commentfacebook/react

Release script should understand prereleases

Does tagging this RC as Next mean we can’t publish anything else to Next until after 17 is finalized?

No, I was just thinking it's "nextier" than what's on next now.

I didn't have a particular reason for tagging it as next.

gaearon

comment created time in 3 days

issue commentfacebook/react

Bug: onChange props is being swallowed in Higher-Order-Component

React has no concept of higher order components; this is an abstraction that only exists in your JavaScript code. So this concept cannot be responsible for a problem related to DOM events.

There is quite a lot of code in your sandbox. Please try to reduce it to the minimal reproducing case so we can take a look.

eakl

comment created time in 3 days

push eventgaearon/react

Dan Abramov

commit sha b7e0ce362b5fecb569baa1588ba9b0b7e3886424

Yarn lock

view details

push time in 3 days

push eventgaearon/react

Dan Abramov

commit sha 4a7b0ac41b318f5d5bce729536e803b81175c7c0

Release script should understand prereleases

view details

push time in 3 days

PR opened facebook/react

Release script should understand prereleases

Without this change, I can't publish an RC as next.

+16 -0

0 comment

1 changed file

pr created time in 3 days

create barnchgaearon/react

branch : prerelease

created branch time in 3 days

Pull request review commentfacebook/react

Bump versions for 17 RC

     "cjs/"   ],   "peerDependencies": {-    "react": "^17.0.0-alpha"+    "react": "17.0.0-rc.0"

I made them all strict. I think going forward we might want to keep it (and not just for RCs).

gaearon

comment created time in 3 days

PR opened facebook/react

Bump versions for 17 RC

Did this manually.

+39 -39

0 comment

23 changed files

pr created time in 3 days

push eventgaearon/react

Brian Vaughn

commit sha 0c52e24cb65a8f1c370184f58ee2d5601a3acd7f

Support inner component _debugOwner in memo (#19556) * Support inner component _debugOwner in memo * test with devtool context * remove memo test * Merged master; tweaked test and snapshot * Pass owner to createFiber fn when creating a memo component. Co-authored-by: Theodore Han <tqhan317@gmail.com>

view details

Kartik Choudhary

commit sha 2704bb5374e52ed548db96df2d975dae42158dfb

Add ReactVersion to SchedulingProfiler render scheduled marks (#19553) * Add ReactVersion to SchedulingProfiler render scheduled marks * Move ReactVersion to a new --react-init-* mark Co-authored-by: E-Liang Tan <eliang@eliangtan.com>

view details

Dan Abramov

commit sha ce37bfad5f61dcca7c2d0c0787bc65e64614c912

Remove resolutions from test renderer package.json (#19577)

view details

Dan Abramov

commit sha ed9bfe82bf02660f0fcf061f1e71e78574e0448f

Bump versions

view details

push time in 3 days

issue commentfacebook/react

Not touched, and not clicked component gets a ghost mousedown event

react@next and react-dom@next have the new behavior so please give it a try (and let us know if doesn't work as expected).

baharev

comment created time in 3 days

push eventreactjs/reactjs.org

Dan Abramov

commit sha 822ed5224a5496174ac10ec80cc5595992e3ea11

Add a section

view details

push time in 3 days

more