Question:
Do you want to request a feature or report a bug? Report a bug What is the current behavior? There are cases where actions dispatched by 's dispatch function are reduced twice (in concurrent mode). As far as I can tell from my first quick read of the code of react-dom (so I might be totally wrong!), this happens, when a higher priority action is to a queue that already contains lower priority actions. On the first run, that is caused by for example an onClick handler (higher priority), the dispatched action is appended to the queue. On processing the queue the lower priority actions (for example from setInterval events) are ignored and the "onClick action" is reduced, but stays on the end of the queue, so that on the next time the queue is processed, that action gets reduced a second time. See a testcase at: Pressing the button increments the button (most of the time not always, depending if 'TICK' actions are in the queue) by two. What is the expected behavior? I'd expect a dispatched action to be only reduced once. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Tested with React 16.7.0-alpha.2 on Chrome (70.0.3538.110) and Safari (12.0.1) both on macOs
This does look like a bug. Want to dig into it?
I'd love to, but I am not sure I understand the implications on messing with the action queue, there are quit a lot of special cases and as I wrote that was my first read of any react implementation code :) Also it might take me a week or so, as I am pretty busy at the moment.
Actually I was wrong, the higher priority action should be reduced twice, the error is in where the memoizedState (action applied) overwrites the baseState (which should stay the last state before updates were skipped). I have a test that reproduced my bug and is fixed by correcting (while the other tests are still passing). I'll have that cleaned up tomorrow or Monday, so I'd take this issue.
Nice find :-)

return { memoizedState: hook.memoizedState, <del> baseState: hook.memoizedState, </del> <ins> baseState: hook.baseState, </ins> queue: hook.queue, baseUpdate: hook.baseUpdate,

ReactNoop.flush(); expect(ReactNoop.getChildren()).toEqual([span('Count: 8')]); }); <ins> // Regression test for https://github.com/facebook/react/issues/14360 it('handles dispatches with mixed priorities', () => { const INCREMENT = 'INCREMENT'; function reducer(state, action) { return action === INCREMENT ? state + 1 : state; } function Counter(props, ref) { const [count, dispatch] = useReducer(reducer, 0); useImperativeMethods(ref, () => ({dispatch})); return <Text text={'Count: ' + count} />; } Counter = forwardRef(Counter); const counter = React.createRef(null); ReactNoop.render(<Counter ref={counter} />); ReactNoop.flush(); expect(ReactNoop.getChildren()).toEqual([span('Count: 0')]); counter.current.dispatch(INCREMENT); counter.current.dispatch(INCREMENT); counter.current.dispatch(INCREMENT); ReactNoop.flushSync(() => { counter.current.dispatch(INCREMENT); }); expect(ReactNoop.getChildren()).toEqual([span('Count: 1')]); ReactNoop.flush(); expect(ReactNoop.getChildren()).toEqual([span('Count: 4')]); }); </ins> }); describe('useEffect', () => {


Question:
Do you want to request a feature or report a bug? report a bug What is the current behavior? When using Suspense, I see React.Suspense fallback layout instead of loaded component in IE 11 (IE network panel shows, that bundle was loaded) I can not reproduce this bug in 16.7.0-alpha.2! there is everything ok. 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? see the rendered component Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Tested on IE11 on windows 7 It reproduces only in 16.8.0-alpha.0 I can not reproduce this bug in 16.7.0-alpha.2, there is everything ok. In Chrome is everything ok in all versions.
the problem was with requirements for additional polyfills in newer version
Hmm which ones? I wouldn't expect that.
Could be the same as A reproducing example would be very helpful; that's unexpected.
can you try running this codesandbox and see if it runs on IE11? if not on codesandbox, try to run it locally. thanks!
I tested this in IE11 with as well as and both appear to work correctly. are you possibly using a polyfill? Which Promise polyfill are you using?
IE11 didn't throw any exceptions. So, that I don't know yet, what exactly polyfill do I need. I solved my problem with I can use only the core-js promise polyfill for 16.7.0-alpha.2 and it works. Im using browserstack for IE11. Unfortunately WeakSet polyfill (as recommended) dint't helped. This is the case without bug React 16.7.0-alpha.2 This is the buggy case React 16.7 I will try to find the exact polyfill, but I don't have any ideas yet :). I runned those examples locally, because they wan't work form sandbox, IE requires more stuff
<img width="1439" alt="screen shot 2019-01-14 at 9 52 58 pm" src="https://user-"
I found matching polyfills after reading and question about Weakmap You need to import not only the Promise, you need to add This is the working version for React 16.7
to clarify, I wasn’t suggesting that you use a polyfill, I was just asking if you were already using one. Just in case it might have been a bad implementation that was causing problems. If you only include the polyfill does it work as expected?
You're right, I just removed WeakSet and it also works.
Thank you for the hint with Sets!
Ah okay, in that case it's expected. React 16 requires both and . This is in the documentation: And in React 16 release notes: That it worked before without is a happy accident. Hope it helps!
It worked because IE11 has native Set implementation, but it isn't compliant. The issue is likely , where we use the API which IE11 doesn't support. maybe we should warn for this?
And how about the Promise ? :)
Ahh. Can you send a PR that just replaces it with an right after creation? I think we didn't want to rely on this.
If you use you need Promise by definition — it depends on you using dynamic which gives you a Promise.
For me, adding the polyfills for , and did not suffice. Instead, this is what worked for me in the :

// attach another listener to flip the boundary back to its normal state. const thenables: Set<Thenable> = (workInProgress.updateQueue: any); if (thenables === null) { <del> workInProgress.updateQueue = (new Set([thenable]): any); </del> <ins> workInProgress.updateQueue = (new Set(): any); workInProgress.updateQueue.add(thenable); </ins> } else { thenables.add(thenable); }


Question: <!-- 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? In , the shallow renderer will set instance state in so the and will be the same in , which is different with the behavior of real rendering. 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: given below class component: render with ReactDOM, the will return true since will be the old value : In shallow renderer, the behavior is different: What is the expected behavior? ShallowRenderer should not set the instance state in getDeriveStateFromProps, or in the we have no way to compare it. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I have tested this in master branch and 16.3, both not work. By the way this problem is related to airbnb/enzyme . If it's recoginzed as a bug I can provide a PR in next several days.

expect(log).toEqual([]); });  it('should pass previous state to shouldComponentUpdate even with getDerivedStateFromProps', () => { const divRef = React.createRef(); class SimpleComponent extends React.Component { constructor(props) { super(props); this.state = { value: props.value, }; } static getDerivedStateFromProps(nextProps, prevState) { if (nextProps.value === prevState.value) { return null; } return {value: nextProps.value}; } shouldComponentUpdate(nextProps, nextState) { return nextState.value !== this.state.value; } render() { return
value: {this.state.value}
; } } const div = document.createElement('div'); ReactDOM.render(<SimpleComponent value="initial" />, div); expect(divRef.current.textContent).toBe('value: initial'); ReactDOM.render(<SimpleComponent value="updated" />, div); expect(divRef.current.textContent).toBe('value: updated'); });  it('should call getSnapshotBeforeUpdate before mutations are committed', () => { const log = [];

this._updater, ); <del> this._updateStateFromStaticLifecycle(element.props); </del> <ins> if (typeof element.type.getDerivedStateFromProps === 'function') { const partialState = element.type.getDerivedStateFromProps.call( null, element.props, this._instance.state, ); if (partialState != null) { this._instance.state = Object.assign( {}, this._instance.state, partialState, ); } } </ins> if (element.type.hasOwnProperty('contextTypes')) { currentlyValidatingElement = element;

} } } <del> this._updateStateFromStaticLifecycle(props); </del> // Read state after cWRP in case it calls setState <del> const state = this._newState || oldState; </del> <ins> let state = this._newState || oldState; if (typeof type.getDerivedStateFromProps === 'function') { const partialState = type.getDerivedStateFromProps.call( null, props, state, ); if (partialState != null) { state = Object.assign({}, state, partialState); } } </ins> let shouldUpdate = true; if (this._forcedUpdate) {

this._instance.context = context; this._instance.props = props; this._instance.state = state; <ins> this._newState = null; </ins> if (shouldUpdate) { this._rendered = this._instance.render();

// Intentionally do not call componentDidUpdate() // because DOM refs are not available. } <del> _updateStateFromStaticLifecycle(props: Object) { if (this._element === null) { return; } const {type} = this._element; if (typeof type.getDerivedStateFromProps === 'function') { const oldState = this._newState || this._instance.state; const partialState = type.getDerivedStateFromProps.call( null, props, oldState, ); if (partialState != null) { const newState = Object.assign({}, oldState, partialState); this._instance.state = this._newState = newState; } } } </del> } let currentlyValidatingElement = null;

expect(result).toEqual(
value:1
); });  it('should pass previous state to shouldComponentUpdate even with getDerivedStateFromProps', () => { class SimpleComponent extends React.Component { constructor(props) { super(props); this.state = { value: props.value, }; } static getDerivedStateFromProps(nextProps, prevState) { if (nextProps.value === prevState.value) { return null; } return {value: nextProps.value}; } shouldComponentUpdate(nextProps, nextState) { return nextState.value !== this.state.value; } render() { return
{`value:${this.state.value}`}
; } } const shallowRenderer = createRenderer(); const initialResult = shallowRenderer.render( <SimpleComponent value="initial" />, ); expect(initialResult).toEqual(
value:initial
); const updatedResult = shallowRenderer.render( <SimpleComponent value="updated" />, ); expect(updatedResult).toEqual(
value:updated
); });  it('can setState with an updater function', () => { let instance;


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

): void { if (__DEV__) { currentHookNameInDev = 'useImperativeHandle'; <ins> warning( typeof create === 'function', 'Expected useImperativeHandle() second argument to be a function ' + 'that creates a handle. Instead received: %s.', create !== null ? typeof create : 'null', ); </ins> } // TODO: If deps are provided, should we skip comparing the ref itself? const nextDeps =

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

} } while (nextEffect !== null) { <ins> if (__DEV__) { setCurrentFiber(nextEffect); } </ins> const effectTag = nextEffect.effectTag; if (effectTag & (Update | Callback)) {

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

let effect = firstEffect; do { <ins> if (__DEV__) { setCurrentFiber(effect); } </ins> if (effect.effectTag & Passive) { let didError = false; let error;

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

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


Question:
<!-- 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. Behavior regression. What is the current behavior? Package throws when being required in Node. 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? should not throw in "pure" node (without providing fake document on global). Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? happens on 16.8.0 previous versions work.
We also got this issue after upgrading to 16.8.0
Found the fix and putting together a PR now edit: now on the case

); } <del> // stub element used by act() when flushing effects let actContainerElement = document.createElement('div'); </del> <ins> // a stub element, lazily initialized, used by act() when flushing effects let actContainerElement = null; </ins> /** * Utilities for making it easy to test React components.

SimulateNative: {}, act(callback: () => void): Thenable { <ins> if (actContainerElement === null) { // warn if we can't actually create the stub element if (__DEV__) { warningWithoutStack( typeof document !== 'undefined' && document !== null && typeof document.createElement === 'function', 'It looks like you called TestUtils.act(...) in a non-browser environment. ' + "If you're using TestRenderer for your tests, you should call " + 'TestRenderer.act(...) instead of TestUtils.act(...).', ); } // then make it actContainerElement = document.createElement('div'); } const result = ReactDOM.unstable_batchedUpdates(callback); </ins> // note: keep these warning messages in sync with // createReactNoop.js and ReactTestRenderer.js <del> const result = ReactDOM.unstable_batchedUpdates(callback); </del> if (__DEV__) { if (result !== undefined) { let addendum;

}); describe('act', () => { <del> it('works', () => { </del> <ins> it('can use .act() to batch updates and effects', () => { </ins> function App(props) { React.useEffect(() => { props.callback();

expect(called).toBe(true); }); <ins> it('warns and throws if you use TestUtils.act instead of TestRenderer.act in node', () => { // we warn when you try to load 2 renderers in the same 'scope' // so as suggested, we call resetModules() to carry on with the test jest.resetModules(); const {act} = require('react-dom/test-utils'); expect(() => { expect(() => act(() => {})).toThrow('document is not defined'); }).toWarnDev( [ 'It looks like you called TestUtils.act(...) in a non-browser environment', ], {withoutStack: 1}, ); }); </ins> }); });


Question:
This issue tracks tasks related to the React DOM implementation of the experimental React Events API () aka React Flare (our internal code-name for the project). The idea is to extend React's event system to include high-level events that allow for consistent cross-device and cross-platform behavior. Note: For now this is completely experimental and won't affect the open source builds of React. [ ] Document specific UX patterns that this enables and fixes. (inc. from my workplace post on styles, Dan & Brian dev tools, apps, etc.) [x] Every user-facing event should have a . Should we provide a standard way to derive data that might be common across events and require different logic for different positional information, e.g., point, delta, offset, etc? [ ] How to test discrete vs continuous events? [ ] Should we polyfill pointer events or not dispatch emulated touch/mouse events in the core, to avoid multiple event components needing to implement the same logic to ignore emulated events? [x] Investigate native pointer capture for retargeting events - This could be particularly useful for drag/swipe UX. [x] Limit all event components to have a single host node as child? If not enforced for all components, we might need this for Hover/Focus/Press at least. FYI [x] Optimize bundle output. [x] Replace magic object export with [x] Document core API for building responders [x] Stop propagation by default but scope to event module types. [x] Investigate ways to listen to root events without first needing to wait for a target event to be dispatched to the event component. [x] Remove from event object passed to callbacks like [x] Ensure discrete events do not unnecessarily force flush previous non-discrete events. [x] Ensure event responder get unmounted correctly and pending events (e.g. long press) properly get removed when doing so. Maybe an unmount lifecycle method needs adding to event responders? [x] Create a new synthetic event and dispatch mechanism that relies on the event being generated in the event responder module, rather than from React. This allows for the event to be better typed and have a much simpler implementation for how React fires the event when dispatched + it means we can avoid pulling in the current SyntheticEvent system and all its dependencies.[ ] Decide on prop name equivalents to RN and .[ ] Determine the potential use cases for DOM and events. [x] Cross browser and device/modality testing. [x] add functionality [x] Add README [x] Write unit tests [x] disabled [x] onBlur [x] onFocus [x] onFocusChange [x] onFocusVisibleChange to help attach this info to focus/blur events)[x] Cross browser and device/modality testing. [x] Determine event object data.[x] Write unit tests () [x] disabled [x] onHoverMove [x] onHoverChange [x] onHoverStart [x] onHoverEnd [x] delayHoverStart [x] delayHoverEnd [x] ensure doesn't respond to emulated mouse events [x] Add README [x] Add and props. [x] Rename events to , .[x] Cross browser and device/modality testing. [ ] Behaviour for selecting text within pressable. End press on selection event? Add a new props to configure the behaviour, like ? [x] Allow contextMenu to display when element is a link and ctrl is held down during press [x] Cancel long press if active press moves (exceeding threshold, IIRC RN uses 10px delta) [x] Reactivate when moving out-of-bounds press back into the responder region. [x] BUG: press start -move out of target -release -tap press. The second press doesn't cause to be called, even thought those events are dispatched to the core responder system. () [x] FYI: is needed on to prevent browser cancelling after . [x] Prevent contextMenu appearing during a long press on touch screens. [x] Account for UX involving interactions on links with modifier keys held. [x] Add to control when press is released after moving the pointer away from the press target. [x] Add README [x] Always prevent default on <aclicks. Maybe have an override to turn off behaviour? [x] Rename events to , (). [x] Change to (). [x] Change default to 500ms (see note in ) [x] Add keyboard support for all events. [x] Prevent scroll-down page when pressing Spacebar on keyboard to interact [x] Add and props. [x] Write unit tests () [x] disabled [x] onLongPress [x] onLongPressChange [x] onLongPressShouldCancelPress [x] onPress [x] onPressChange [x] onPressStart [x] onPressEnd [x] delayLongPress [x] delayPressStart [x] delayPressEnd [x] pressRententionOffset / pressRect [x] emulated mouse events [x] ~fix keyboard press events when metaKey is involved~ (this currently works the same way as native, so will leave it for now) [x] any special case anchor tag-related tests [ ] hitslop interactions [x] Determine event object data. Consider adding and (names tbd) to support userland customisation of focus repair. We could return the native elements. A use case to consider: being able to programmatically move focus to an element without allowing keyboards to focus the element (e.g., the document body, the root of a modal). In this case the element (other than a few special cases) must have . [ ] fires when an input element has been changed. This applies to , , and elements with or when is enabled. provides a callback with the event for the element that changed and a of the elment that changed (if a was supplied). [ ] is similar to , but only provides the value changed. This applies to , , and elements with or when is enabled. provides a and of the element that changed (if a was supplied). [ ] for when any elements trigger form submit. [ ] for when any keyboard keys are pressed. [ ] accepts an array of key strings that will get prevented from entering input. [ ] for when any any text selection occurs in any child elements. [ ] fires before a change is about to occur. This applies to , , and elements with or when is enabled. provides a callback with the event for the element that changed and a of the elment that changed (if a was supplied).[ ] Determine event object data (same as Pan) [ ] Cancelling drag. [ ] FYI: is needed on to prevent browser cancelling after . when combining with . [ ] Add README [ ] Cross browser and device/modality testing. [ ] Write unit tests.[ ] Write unit tests. [ ] Cross browser and device/modality testing. [ ] Cancelling pan. [ ] Add README [ ] FYI: is needed on to prevent browser cancelling after . [ ] Determine event object data.[x] [x] [ ] [ ] [ ] [ ] [ ] scroll directions [ ] Determine event object data FYI [ ] Combine into w/ event data. [ ] Cancelling swipe. [ ] Write comprehensive unit tests. [ ] Cross browser and device/modality testing. [ ] Add README [ ] Determine event object data (same as Pan) [ ] FYI: is needed on to prevent browser cancelling after . Consider whether we need this at all. Some browsers have a native hitslop and we could work with vendors on any potential improvements to the native system [ ] Figure out how to parent of hitslop. [ ] Measurement without reflows (ResizeObserver?) [ ] Add README [x] Figure out solution for SSR w/ non-touch interactions if no client-side JS [x] Add (). [x] Add SSR support[x] Add fields to event components and event targets. [x] Possibly add a or field to event responders? For example the responder module for ReactDOM could have the name . [ ] Expose some DEV only event triggering exports from event responder modules. i.e. [x] Add basic support for rendering event responders and event targets in the tree. Investigate removing object assign polyfill from individual event modules [x] Add internal interactive documentation / fiddle [ ] Investigate press event patterns on , , , etc. [x] Implement high-level components like Pressable (inc delays). [x] Nested Pressables should not bubble events. [x] Investigate accounting for element resizes when determining hit bounds, e.g., using resize observer for notifications
Added some proposed event object data. Suggest forwarding (or creating) the on all events to allow userland customization based on modality that triggered an event; non-standard type to Focus and Press events.
Tracking some regressions I'm uncovering that seem to have been caused by the changes in . is not called when moving within the responder region. Looks like no events are dispatched to the Press module in the bubble phase, which is also breaking the pressRetention functionality. and events are dispatched to the Hover module in the bubble phase (discovered while investigating the Hover runtime error).
In relation to those two regressions: could you add tests for them that fail, but skip them with a comment explaining they need to be fixed, linking to this issue? You don’t need to put them in Press-test or Hover-test, you can make specific isolated tests with them using a custom responder to demonstrate this breaking because of the linked PR (like how we test the onUnmount works). It seems like a bug in the capture/bubbling rather than a specific event responder module.
I got to the bottom of issue (1) and it turns out it's happening because different event modules can influence the propagation of the same synthetic event. In this case, was preventing the propagation of to the root but was listening to on the root.
We could make root events not get affected by target propagation stopping. We can move the target and the root event handling into separate functions, so that this logic handling root events continues to run. Right now, when a target event handle stopsPropagation, the early return skips over too events too. So we'd move this block of code out:
Yeah I played around with modifying that section of code to do just that. But I think you could still end up in situations where 2 different types of event components are listening to the same event defined as a and the inner component is stopping propagation to the outer, e.g., . That's why I mentioned the idea of limiting control over propagation to within event components of the same type, but haven't thought through the implications enough.
Hi guys. Great work! Will React.unstable_createEventComponent support observers api like ResizeObserver and IntersectionObserver?
Event responder modules are free to use whatever DOM APIs they want, so they could definitely use and . We may even need to use them in some of the core responders soon.
Question regarding potential scroll module - have you considered adding smth like property? It's highly useful to know if the scroll was triggered programatically or by user and it's also highly hard to determine this in user space.
What's an example of scroll being programmatically triggered without your knowledge?
I feel like every change to in code is not user introduced.
But that's easy to detect because you're using a programmatic API
It does get a bit difficult when the scrolling trigger is far from the listener, and making them aware of each other introduces fragile coupling. We've had a few such cases in DevTools. Especially if the focus signal is reactive to some state change.
Here's what I ask: if you have a request please take the time to provide plenty of context. What are the use cases? How are things difficult? How do you imagine a solution might work? etc.
In example showing a "sticker" with a date at the top of the message feed. When a scroll is induced programmatically (or by the browser) then it's distracting to show such thing, but when a user scrolls on their own it makes sense from the UX perspective. Well, it's not a clear way of determining that in onScroll, so some kind of other tracking flags have to be introduced to solve this. It's in general tricky to handle all possible reasons of why scroll has been triggered: it can be caused by wheel (but also wheel doesnt always mean that scroll will happen - u can have other interactions dependant on the wheel), but also you can wheel over inner scrollable element which won't trigger the scroll of the component in question touchmove - but you probably have to calculate this based on some deltas etc keyboard - space, page up, page down, end, home, arrows And those are just things that user can do. Other than that UI might get mutated (even by React, so we can't really track it in userland) and thus trigger scroll event, and as mentioned setting scrollTop also triggers scroll event. And even if u manage to track all reasons of user-induced scrolling it's unobvious when to clear you your flag(s) because you have to consider inertia scrolling etc The solution would be to figure out best heuristics of detecting this. Can't give much detail right now, because this truly is an overcomplicated problem for such a "simple" thing. Web
I don't quite understand the use case you're describing.
Consider another one - a floating "scroll to bottom" button which covers part of the chat feed. We'd like to show such when a user is scrolling on their own (with a delay etc) and hide it after they stop scrolling so we don't cover part of the chat feed constantly. And we i.e. have to work around for situations like mobile keyboard triggering onScroll (cause of the resize etc).
Given the grand retooling happening to the event system here, I would like to re-raise the following request under this umbrella, from TL;DR: listen to / rather than / native events.
Hey guys, looks pretty cool this experimental event system. I wonder if there is still work to do, I would like to contribute to this. I see there are some pending tasks in the checklist but no open issues about them
We're not longer working on this particular approach and will be exploring other ways to work with the DOM event system in the future. We've concluded that the "Flare" event system is too high-level an abstraction and we'd like to explore something that is a bit more familiar to developers familiar with the DOM (e.g., addEventListener) and React's existing tools (e.g., hooks). Our goal is still to make it possible for library authors to work with passive events, capture/bubble phase, custom events, and events occurring on the document from within a React function reducing the amount of event-related code needed in ReactDOM. Ultimately building both intermediate abstractions like the Responder Event system and high-level abstractions like (which we prototyped in Flare) should be possible in user-space.
That's a bummer - this API looked awesome and I had high hopes for it. I guess you have good reasons for not pursuing this, I'm eager to learn with what alternative you will come up with.

if ((props.onLongPress || props.onLongPressChange) && !state.isLongPressed) { const delayLongPress = calculateDelayMS( props.delayLongPress, <del> 0, </del> <ins> 10, </ins> DEFAULT_LONG_PRESS_DELAY_MS, );

state.isLongPressed = true; state.longPressTimeout = null; <del> if ( props.onPressChange && props.onLongPressShouldCancelPress && props.onLongPressShouldCancelPress() ) { dispatchPressChangeEvent(false); } </del> if (props.onLongPress) { const longPressEventListener = e => { props.onLongPress(e);

let ReactDOM; let Press; <del> describe('Press event responder', () => { </del> <ins> const DEFAULT_LONG_PRESS_DELAY = 1000; const createPointerEvent = type => { const event = document.createEvent('Event'); event.initEvent(type, true, true); return event; }; const createKeyboardEvent = (type, data) => { return new KeyboardEvent(type, { bubbles: true, cancelable: true, ...data, }); }; describe('Event responder: Press', () => { </ins> let container; beforeEach(() => {

container = null; });  it('should support onPress', () => { let buttonRef = React.createRef(); let events = []; function handleOnPress1() { events.push('press 1'); } function handleOnPress2() { events.push('press 2'); } function handleOnMouseDown() { events.push('mousedown'); } function handleKeyDown() { events.push('keydown'); } function Component() { return ( <Press onPress={handleOnPress1}> <Press onPress={handleOnPress2}> <button ref={buttonRef} onMouseDown={handleOnMouseDown} onKeyDown={handleKeyDown}> Press me! </button> </Press>   describe('onPressStart', () => { let onPressStart, ref; beforeEach(() => { onPressStart = jest.fn(); ref = React.createRef(); const element = ( <Press onPressStart={onPressStart}>
  </Press> );  }   ReactDOM.render(element, container); });   ReactDOM.render(<Component />, container);   it('is called after "pointerdown" event', () => { ref.current.dispatchEvent(createPointerEvent('pointerdown')); expect(onPressStart).toHaveBeenCalledTimes(1); });   const mouseDownEvent = document.createEvent('Event'); mouseDownEvent.initEvent('mousedown', true, true); buttonRef.current.dispatchEvent(mouseDownEvent);   it('ignores emulated "mousedown" event', () => { ref.current.dispatchEvent(createPointerEvent('pointerdown')); ref.current.dispatchEvent(createPointerEvent('mousedown')); expect(onPressStart).toHaveBeenCalledTimes(1); });   const mouseUpEvent = document.createEvent('Event'); mouseUpEvent.initEvent('mouseup', true, true); buttonRef.current.dispatchEvent(mouseUpEvent);   // No PointerEvent fallbacks it('is called after "mousedown" event', () => { ref.current.dispatchEvent(createPointerEvent('mousedown')); expect(onPressStart).toHaveBeenCalledTimes(1); }); it('is called after "touchstart" event', () => { ref.current.dispatchEvent(createPointerEvent('touchstart')); expect(onPressStart).toHaveBeenCalledTimes(1); }); // TODO: complete delayPressStart tests // describe('delayPressStart', () => {}); });   expect(events).toEqual(['mousedown', 'press 2', 'press 1']);   describe('onPressEnd', () => { let onPressEnd, ref; beforeEach(() => { onPressEnd = jest.fn(); ref = React.createRef(); const element = ( <Press onPressEnd={onPressEnd}>
 </Press> ); ReactDOM.render(element, container); }); it('is called after "pointerup" event', () => { ref.current.dispatchEvent(createPointerEvent('pointerdown')); ref.current.dispatchEvent(createPointerEvent('pointerup')); expect(onPressEnd).toHaveBeenCalledTimes(1); });   events = []; const keyDownEvent = new KeyboardEvent('keydown', { key: 'Enter', bubbles: true, cancelable: true,   it('ignores emulated "mouseup" event', () => { ref.current.dispatchEvent(createPointerEvent('touchstart')); ref.current.dispatchEvent(createPointerEvent('touchend')); ref.current.dispatchEvent(createPointerEvent('mouseup')); expect(onPressEnd).toHaveBeenCalledTimes(1); }); // No PointerEvent fallbacks it('is called after "mouseup" event', () => { ref.current.dispatchEvent(createPointerEvent('mousedown')); ref.current.dispatchEvent(createPointerEvent('mouseup')); expect(onPressEnd).toHaveBeenCalledTimes(1); }); it('is called after "touchend" event', () => { ref.current.dispatchEvent(createPointerEvent('touchstart')); ref.current.dispatchEvent(createPointerEvent('touchend')); expect(onPressEnd).toHaveBeenCalledTimes(1); }); // TODO: complete delayPressStart tests // describe('delayPressStart', () => {}); }); describe('onPressChange', () => { let onPressChange, ref; beforeEach(() => { onPressChange = jest.fn(); ref = React.createRef(); const element = ( <Press onPressChange={onPressChange}>
 </Press> ); ReactDOM.render(element, container); }); it('is called after "pointerdown" and "pointerup" events', () => { ref.current.dispatchEvent(createPointerEvent('pointerdown')); expect(onPressChange).toHaveBeenCalledTimes(1); expect(onPressChange).toHaveBeenCalledWith(true); ref.current.dispatchEvent(createPointerEvent('pointerup')); expect(onPressChange).toHaveBeenCalledTimes(2); expect(onPressChange).toHaveBeenCalledWith(false); }); }); describe('onPress', () => { let onPress, ref; beforeEach(() => { onPress = jest.fn(); ref = React.createRef(); const element = ( <Press onPress={onPress}>
 </Press> ); ReactDOM.render(element, container);  });  buttonRef.current.dispatchEvent(keyDownEvent); // press 1 should not occur as press 2 will preventDefault expect(events).toEqual(['keydown', 'press 2']);   it('is called after "pointerup" event', () => { ref.current.dispatchEvent(createPointerEvent('pointerdown')); ref.current.dispatchEvent(createPointerEvent('pointerup')); expect(onPress).toHaveBeenCalledTimes(1); });  });  it('should support onPressStart and onPressEnd', () => { let divRef = React.createRef(); let events = [];   describe('onLongPress', () => { let onLongPress, ref; beforeEach(() => { onLongPress = jest.fn(); ref = React.createRef(); const element = ( <Press onLongPress={onLongPress}>
 </Press> ); ReactDOM.render(element, container); }); it('is called if press lasts default delay', () => { ref.current.dispatchEvent(createPointerEvent('pointerdown')); jest.advanceTimersByTime(DEFAULT_LONG_PRESS_DELAY - 1); expect(onLongPress).not.toBeCalled(); jest.advanceTimersByTime(1); expect(onLongPress).toHaveBeenCalledTimes(1); });   function handleOnPressStart() { events.push('onPressStart'); }   it('is not called if press is released before delay', () => { ref.current.dispatchEvent(createPointerEvent('pointerdown')); jest.advanceTimersByTime(DEFAULT_LONG_PRESS_DELAY - 1); ref.current.dispatchEvent(createPointerEvent('pointerup')); jest.advanceTimersByTime(1); expect(onLongPress).not.toBeCalled(); });   function handleOnPressEnd() { events.push('onPressEnd'); }   describe('delayLongPress', () => { it('can be configured', () => { const element = ( <Press delayLongPress={2000} onLongPress={onLongPress}>
 </Press> ); ReactDOM.render(element, container); ref.current.dispatchEvent(createPointerEvent('pointerdown')); jest.advanceTimersByTime(1999); expect(onLongPress).not.toBeCalled(); jest.advanceTimersByTime(1); expect(onLongPress).toHaveBeenCalledTimes(1); }); it('uses 10ms minimum delay length', () => { const element = ( <Press delayLongPress={0} onLongPress={onLongPress}>
 </Press> ); ReactDOM.render(element, container); ref.current.dispatchEvent(createPointerEvent('pointerdown')); jest.advanceTimersByTime(9); expect(onLongPress).not.toBeCalled(); jest.advanceTimersByTime(1); expect(onLongPress).toHaveBeenCalledTimes(1); }); /* it('compounds with "delayPressStart"', () => { const delayPressStart = 100; const element = ( <Press delayPressStart={delayPressStart} onLongPress={onLongPress}>
 </Press> ); ReactDOM.render(element, container); ref.current.dispatchEvent(createPointerEvent('pointerdown')); jest.advanceTimersByTime(delayPressStart + DEFAULT_LONG_PRESS_DELAY - 1); expect(onLongPress).not.toBeCalled(); jest.advanceTimersByTime(1); expect(onLongPress).toHaveBeenCalledTimes(1); }); */ }); });   function Component() { return ( <Press onPressStart={handleOnPressStart} onPressEnd={handleOnPressEnd}>
Press me!
   describe('onLongPressChange', () => { it('is called when long press state changes', () => { const onLongPressChange = jest.fn(); const ref = React.createRef(); const element = ( <Press onLongPressChange={onLongPressChange}>
  </Press> );  }   ReactDOM.render(element, container);   ReactDOM.render(<Component />, container);   ref.current.dispatchEvent(createPointerEvent('pointerdown')); jest.advanceTimersByTime(DEFAULT_LONG_PRESS_DELAY); expect(onLongPressChange).toHaveBeenCalledTimes(1); expect(onLongPressChange).toHaveBeenCalledWith(true); ref.current.dispatchEvent(createPointerEvent('pointerup')); expect(onLongPressChange).toHaveBeenCalledTimes(2); expect(onLongPressChange).toHaveBeenCalledWith(false); }); }); describe('onLongPressShouldCancelPress', () => { it('if true it cancels "onPress"', () => { const onPress = jest.fn(); const onPressChange = jest.fn(); const ref = React.createRef(); const element = ( <Press onLongPress={() => {}} onLongPressShouldCancelPress={() => true} onPressChange={onPressChange} onPress={onPress}>
 </Press> ); ReactDOM.render(element, container); // NOTE: onPressChange behavior should not be affected ref.current.dispatchEvent(createPointerEvent('pointerdown')); expect(onPressChange).toHaveBeenCalledTimes(1); jest.advanceTimersByTime(DEFAULT_LONG_PRESS_DELAY); ref.current.dispatchEvent(createPointerEvent('pointerup')); expect(onPress).not.toBeCalled(); expect(onPressChange).toHaveBeenCalledTimes(2); }); }); // TODO //describe('`onPress*` with movement', () => { //describe('within bounds of hit rect', () => { /** ┌──────────────────┐ *  │  ┌────────────┐  │ *  │  │ VisualRect │  │ *  │  └────────────┘  │ *  │     HitRect    X │ <= Move to X and release *  └──────────────────┘ */   const pointerEnterEvent = document.createEvent('Event'); pointerEnterEvent.initEvent('pointerdown', true, true); divRef.current.dispatchEvent(pointerEnterEvent);   //it('"onPress*" events are called when no delay', () => {}); //it('"onPress*" events are called after a delay', () => {}); //});   const pointerLeaveEvent = document.createEvent('Event'); pointerLeaveEvent.initEvent('pointerup', true, true); divRef.current.dispatchEvent(pointerLeaveEvent);   //describe('beyond bounds of hit rect', () => { /** ┌──────────────────┐ *  │  ┌────────────┐  │ *  │  │ VisualRect │  │ *  │  └────────────┘  │ *  │     HitRect      │ *  └──────────────────┘ *                   X   <= Move to X and release */   expect(events).toEqual(['onPressStart', 'onPressEnd']);   //it('"onPress" only is not called when no delay', () => {}); //it('"onPress*" events are not called after a delay', () => {}); //it('"onPress*" events are called when press is released before measure completes', () => {}); //}); //}); describe('nested responders', () => { it('dispatch events in the correct order', () => { let events = []; const ref = React.createRef(); const createEventHandler = msg => () => { events.push(msg); }; const element = ( <Press onPress={createEventHandler('outer: onPress')} onPressChange={createEventHandler('outer: onPressChange')} onPressStart={createEventHandler('outer: onPressStart')} onPressEnd={createEventHandler('outer: onPressEnd')}> <Press onPress={createEventHandler('inner: onPress')} onPressChange={createEventHandler('inner: onPressChange')} onPressStart={createEventHandler('inner: onPressStart')} onPressEnd={createEventHandler('inner: onPressEnd')}>
 </Press> </Press> ); ReactDOM.render(element, container); ref.current.dispatchEvent(createPointerEvent('pointerdown')); ref.current.dispatchEvent(createPointerEvent('pointerup')); expect(events).toEqual([ 'pointerdown', 'inner: onPressStart', 'inner: onPressChange', 'outer: onPressStart', 'outer: onPressChange', 'pointerup', 'inner: onPressEnd', 'inner: onPressChange', 'inner: onPress', 'outer: onPressEnd', 'outer: onPressChange', 'outer: onPress', ]); events = []; ref.current.dispatchEvent(createKeyboardEvent('keydown', {key: 'Enter'})); // Outer press should not occur as inner press will preventDefault expect(events).toEqual(['keydown', 'inner: onPress']); });  }); });


Question:
Feature requested GitHub has just released the Security Policy feature, by writing the file a new tab with security informations should appear in the repository. You can check the It will really improve people trusting in open source security standards
Added in the above commit

<ins> # Reporting Security Issues If you believe you have found a security vulnerability in React, we encourage you to let us know right away. We will investigate all legitimate reports and do our best to quickly fix the problem. Please refer to the following page for our responsible disclosure policy, reward guidelines, and those things that should not be reported: https://www.facebook.com/whitehat </ins>


Question:
<!-- 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? In shallow renderer, The returned callback from is not the same one between two rerendering even though the dependencies are the same. But will work as expected. For example, the following test won't work: If returned the same callback between two rendering (I think) the assertion should pass. but the same (almost) logic will work with , in the shallow renderer test suite (See ). 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 created a branch in and you can run the failed shallow renderer test in . What is the expected behavior? should return the memoized callback when the dependencies unchanged even in shallow renderer. I tried to look into this and I found out that in shallow renderer just returns the original callback argument (See ) but will compare the dependencies between rendering. I'm not sure if it's intended (So it's expected that will not memoize callback in shallow renderer). If it's triaged as a bug I'm glad to send a pr for this :) Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? react
yup, this looks like a miss on our part. Would you like to send a PR? :)
thanks for reply :-) I'd try to make a PR in a few days.
I don't think it's a miss on our part. It was an intentional decision since it's mostly an optimization, and unclear why it would be important for shallow rendering to do that. Can you explain why it matters?
It’s important for shallow rendering to match production as much as possible, since shallow rendering is a testing tool.
Agree to Even it's optimization I think there might be still case that we want to make sure we've really do the optimization (though not guaranteed in production) in code.
Is this still open to be worked on?
For this code and statement: Isn't it creating two instances, and then rendering each of them independently? AFAIK this is not two renderings of the same, but instead two different elements. If I have a component rendered in different places those are independent of each other. They keep the same callback between re-renders, but not across all the instances.
The shallow renderer has moved to If this is still relevant, please feel free to file this issue there. Thanks!

Let's call the callback from the `CommentForm` when the user submits the form: <del> ```javascript{6} </del> <ins> ```javascript{10} </ins> // tutorial18.js var CommentForm = React.createClass({ handleSubmit: function(e) {


Question: Currently the simple event plugin defines a priority for the event but not all events go through the SimpleEventPlugin. That's just one of several EventPlugins. The remaining ones now get the wrong priority associated with them. E.g. I think all of these should be discrete: change compositionend compositionstart compositionupdate selectionchange textinput These show up too but I don't know if they're even bridged. dblclick pointerenter pointerleave Flare defines its own priorities.

// eslint-disable-next-line no-fallthrough case 'mouseenter': case 'mouseleave': <ins> case 'pointerenter': case 'pointerleave': </ins> return ContinuousEventPriority; case 'message': { // We might be in the Scheduler callback.


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

 /** * Copyright (c) Facebook, Inc. and its affiliates. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @emails react-core */ 'use strict'; describe('ReactDOMShorthandCSSPropertyCollision', () => { let ReactFeatureFlags; let React; let ReactDOM; beforeEach(() => { jest.resetModules(); ReactFeatureFlags = require('shared/ReactFeatureFlags'); ReactFeatureFlags.warnAboutShorthandPropertyCollision = true; React = require('react'); ReactDOM = require('react-dom'); }); it('should warn for conflicting CSS shorthand updates', () => { const container = document.createElement('div'); ReactDOM.render(
, container); expect(() => ReactDOM.render(
, container), ).toErrorDev( 'Warning: Removing a style property during rerender (fontStyle) ' + 'when a conflicting property is set (font) can lead to styling ' + "bugs. To avoid this, don't mix shorthand and non-shorthand " + 'properties for the same value; instead, replace the shorthand ' + 'with separate values.' + 'n    in div (at **)', ); // These updates are OK and don't warn: ReactDOM.render(
, container); ReactDOM.render(
, container); expect(() => ReactDOM.render(
, container, ), ).toErrorDev( 'Warning: Updating a style property during rerender (font) when ' + 'a conflicting property is set (fontStyle) can lead to styling ' + "bugs. To avoid this, don't mix shorthand and non-shorthand " + 'properties for the same value; instead, replace the shorthand ' + 'with separate values.' + 'n    in div (at **)', ); expect(() => ReactDOM.render(
, container), ).toErrorDev( 'Warning: Removing a style property during rerender (font) when ' + 'a conflicting property is set (fontStyle) can lead to styling ' + "bugs. To avoid this, don't mix shorthand and non-shorthand " + 'properties for the same value; instead, replace the shorthand ' + 'with separate values.' + 'n    in div (at **)', ); // A bit of a special case: backgroundPosition isn't technically longhand // (it expands to backgroundPosition{X,Y} but so does background) ReactDOM.render(
, container, ); expect(() => ReactDOM.render(
, container), ).toErrorDev( 'Warning: Removing a style property during rerender ' + '(backgroundPosition) when a conflicting property is set ' + "(background) can lead to styling bugs. To avoid this, don't mix " + 'shorthand and non-shorthand properties for the same value; ' + 'instead, replace the shorthand with separate values.' + 'n    in div (at **)', ); ReactDOM.render(
, container, ); // But setting them  at the same time is OK: ReactDOM.render(
, container, ); expect(() => ReactDOM.render(
, container), ).toErrorDev( 'Warning: Removing a style property during rerender (background) ' + 'when a conflicting property is set (backgroundPosition) can lead ' + "to styling bugs. To avoid this, don't mix shorthand and " + 'non-shorthand properties for the same value; instead, replace the ' + 'shorthand with separate values.' + 'n    in div (at **)', ); // A bit of an even more special case: borderLeft and borderStyle overlap. ReactDOM.render(
, container, ); expect(() => ReactDOM.render(
, container), ).toErrorDev( 'Warning: Removing a style property during rerender (borderStyle) ' + 'when a conflicting property is set (borderLeft) can lead to ' + "styling bugs. To avoid this, don't mix shorthand and " + 'non-shorthand properties for the same value; instead, replace the ' + 'shorthand with separate values.' + 'n    in div (at **)', ); expect(() => ReactDOM.render(
, container, ), ).toErrorDev( 'Warning: Updating a style property during rerender (borderStyle) ' + 'when a conflicting property is set (borderLeft) can lead to ' + "styling bugs. To avoid this, don't mix shorthand and " + 'non-shorthand properties for the same value; instead, replace the ' + 'shorthand with separate values.' + 'n    in div (at **)', ); // But setting them  at the same time is OK: ReactDOM.render(
, container, ); expect(() => ReactDOM.render(
, container), ).toErrorDev( 'Warning: Removing a style property during rerender (borderLeft) ' + 'when a conflicting property is set (borderStyle) can lead to ' + "styling bugs. To avoid this, don't mix shorthand and " + 'non-shorthand properties for the same value; instead, replace the ' + 'shorthand with separate values.' + 'n    in div (at **)', ); }); });

 /** * Copyright (c) Facebook, Inc. and its affiliates. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. * * @emails react-core */ 'use strict'; describe('ReactDOMShorthandCSSPropertyCollision', () => { let React; let ReactDOM; beforeEach(() => { jest.resetModules(); React = require('react'); ReactDOM = require('react-dom'); }); it('should warn for conflicting CSS shorthand updates', () => { const container = document.createElement('div'); ReactDOM.render(
, container); expect(() => ReactDOM.render(
, container), ).toErrorDev( 'Warning: Removing a style property during rerender (fontStyle) ' + 'when a conflicting property is set (font) can lead to styling ' + "bugs. To avoid this, don't mix shorthand and non-shorthand " + 'properties for the same value; instead, replace the shorthand ' + 'with separate values.' + 'n    in div (at **)', ); // These updates are OK and don't warn: ReactDOM.render(
, container); ReactDOM.render(
, container); expect(() => ReactDOM.render(
, container, ), ).toErrorDev( 'Warning: Updating a style property during rerender (font) when ' + 'a conflicting property is set (fontStyle) can lead to styling ' + "bugs. To avoid this, don't mix shorthand and non-shorthand " + 'properties for the same value; instead, replace the shorthand ' + 'with separate values.' + 'n    in div (at **)', ); expect(() => ReactDOM.render(
, container), ).toErrorDev( 'Warning: Removing a style property during rerender (font) when ' + 'a conflicting property is set (fontStyle) can lead to styling ' + "bugs. To avoid this, don't mix shorthand and non-shorthand " + 'properties for the same value; instead, replace the shorthand ' + 'with separate values.' + 'n    in div (at **)', ); // A bit of a special case: backgroundPosition isn't technically longhand // (it expands to backgroundPosition{X,Y} but so does background) ReactDOM.render(
, container, ); expect(() => ReactDOM.render(
, container), ).toErrorDev( 'Warning: Removing a style property during rerender ' + '(backgroundPosition) when a conflicting property is set ' + "(background) can lead to styling bugs. To avoid this, don't mix " + 'shorthand and non-shorthand properties for the same value; ' + 'instead, replace the shorthand with separate values.' + 'n    in div (at **)', ); ReactDOM.render(
, container, ); // But setting them  at the same time is OK: ReactDOM.render(
, container, ); expect(() => ReactDOM.render(
, container), ).toErrorDev( 'Warning: Removing a style property during rerender (background) ' + 'when a conflicting property is set (backgroundPosition) can lead ' + "to styling bugs. To avoid this, don't mix shorthand and " + 'non-shorthand properties for the same value; instead, replace the ' + 'shorthand with separate values.' + 'n    in div (at **)', ); // A bit of an even more special case: borderLeft and borderStyle overlap. ReactDOM.render(
, container, ); expect(() => ReactDOM.render(
, container), ).toErrorDev( 'Warning: Removing a style property during rerender (borderStyle) ' + 'when a conflicting property is set (borderLeft) can lead to ' + "styling bugs. To avoid this, don't mix shorthand and " + 'non-shorthand properties for the same value; instead, replace the ' + 'shorthand with separate values.' + 'n    in div (at **)', ); expect(() => ReactDOM.render(
, container, ), ).toErrorDev( 'Warning: Updating a style property during rerender (borderStyle) ' + 'when a conflicting property is set (borderLeft) can lead to ' + "styling bugs. To avoid this, don't mix shorthand and " + 'non-shorthand properties for the same value; instead, replace the ' + 'shorthand with separate values.' + 'n    in div (at **)', ); // But setting them  at the same time is OK: ReactDOM.render(
, container, ); expect(() => ReactDOM.render(
, container), ).toErrorDev( 'Warning: Removing a style property during rerender (borderLeft) ' + 'when a conflicting property is set (borderStyle) can lead to ' + "styling bugs. To avoid this, don't mix shorthand and " + 'non-shorthand properties for the same value; instead, replace the ' + 'shorthand with separate values.' + 'n    in div (at **)', ); }); });

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

export const enableSelectiveHydration = false; export const enableChunksAPI = false; export const exposeConcurrentModeAPIs = __EXPERIMENTAL__; <del> export const warnAboutShorthandPropertyCollision = false; </del> <ins> export const warnAboutShorthandPropertyCollision = true; </ins> export const enableSchedulerDebugging = false; export const debugRenderPhaseSideEffectsForStrictMode = true; export const disableJavaScriptURLs = false;

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

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

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


Question:
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-"

font-family: var(--font-family-sans); } <ins> .Source { padding: 0.25rem; border-top: 1px solid var(--color-border); } .SourceHeaderRow { display: flex; align-items: center; } .SourceHeader { flex: 1 1; font-family: var(--font-family-sans); } .SourceOneLiner { font-family: var(--font-family-monospace); font-size: var(--font-size-monospace-normal); white-space: nowrap; overflow: hidden; text-overflow: ellipsis; max-width: 100%; margin-left: 1rem; } </ins> .Component, .Owner { color: var(--color-component-name);

* @flow */ <ins> import {copy} from 'clipboard-js'; </ins> import React, {useCallback, useContext} from 'react'; import {TreeDispatcherContext, TreeStateContext} from './TreeContext'; import {BridgeContext, StoreContext} from '../context';

hooks, owners, props, <ins> source, </ins> state, } = inspectedElement;

))}
 )}  {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)}

 ); }


Question:
Hi, long time user, first time issuer. I think I found a bug with the Profiler component. When I click on the button at the top nothing happens and there appears to be no new files in my Downloads folder. I think it might be silently failing and that's why I am not getting any response. Has anyone else ran into this issue? Another thing I would like to mention is that I haven't looked through all of the documentation material about the new Profiler. I only read , so if this issue is addressed elsewhere I apologize and also request the source to that solution. Thank you for your time! Versions: *
It seems that this is happening because of the call in the util function. I'll investigate this further.
I fixed the issue. I'll open a PR later today :)

const {profilerStore} = store; const inputRef = useRef<HTMLInputElement | null>(null); <ins> const downloadRef = useRef<HTMLAnchorElement | null>(null); </ins> const {dispatch: modalDialogDispatch} = useContext(ModalDialogContext);

return; } <del> if (profilingData !== null) { </del> <ins> if (profilingData !== null && downloadRef.current !== null) { </ins> const profilingDataExport = prepareProfilingDataExport(profilingData); const date = new Date(); const dateString = date

}) .replace(/:/g, '-'); downloadFile( <ins> downloadRef.current, </ins> `profiling-data.${dateString}.${timeString}.json`, JSON.stringify(profilingDataExport, null, 2), );

onChange={handleFiles} tabIndex={-1} /> <ins> <a ref={downloadRef} className={styles.Input} /> </ins> <Button disabled={isProfiling} onClick={uploadData}

// Without this, we would see a "Download failed: network error" failure. let downloadUrl = null; <del> export function downloadFile(filename: string, text: string): void { </del> <ins> export function downloadFile( element: HTMLAnchorElement, filename: string, text: string, ): void { </ins> const blob = new Blob([text], {type: 'text/plain;charset=utf-8'}); if (downloadUrl !== null) {

downloadUrl = URL.createObjectURL(blob); <del> const element = document.createElement('a'); </del> element.setAttribute('href', downloadUrl); element.setAttribute('download', filename); <del> element.style.display = 'none'; ((document.body: any): HTMLBodyElement).appendChild(element); </del> element.click(); <del> ((document.body: any): HTMLBodyElement).removeChild(element); </del> } export function truncateText(text: string, maxLength: number): string {


Question:
Do you want to request a feature or report a bug? bug What is the current behavior? When using the latest Dev tools (v4.0.5) on my project, when I inspect react-redux elements that use connect() devtools crashes. I can't map from my crash to the actual source but the code is react devtools: up one level of stack is react: and up one level is react-redux: () 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'll have to try and make a small repro, but I hope there's something obvious given the info above. It's not clear to me if react-redux is doing something or if its devtools. This behavior existed in v3 and i was hoping it'd get magically fixed with v4 but it remains. What is the expected behavior? Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? This is in an electron app w/ react-redux v7.1.0 and react v16.8.3 (have to use this due to the version of react native i'm on)
Unfortunately this is a bug with React that was fixed via PR and released with v16.8.4. Thank you for the detailed bug report though! Originally reported here:

Let's make the form interactive. When the user submits the form, we should clear it, submit a request to the server, and refresh the list of comments. To start, let's listen for the form's submit event and clear it. <del> ```javascript{3-12,15,20} </del> <ins> ```javascript{3-13,16,21} </ins> // tutorial16.js var CommentForm = React.createClass({ handleSubmit: React.autoBind(function() { var author = this.refs.author.getDOMNode().value.trim(); var text = this.refs.text.getDOMNode().value.trim(); if (!text || !author) { <del> return; </del> <ins> return false; </ins> } // TODO: send request to the server this.refs.author.getDOMNode().value = ''; this.refs.text.getDOMNode().value = ''; <ins> return false; </ins> }), render: function() { return (

#### Events <del> React attaches event handlers to components using a camelCase naming convention. We attach an onKeyUp handler to the text field, check if the user has entered text and pressed the enter key and then clear the form fields. </del> <ins> React attaches event handlers to components using a camelCase naming convention. We attach an `onSubmit` handler to the form that clears the form fields when the form is submitted with valid input. We always return `false` from the event handler to prevent the browser's default action of submitting the form. (If you prefer, you can instead take the event as an argument and call `preventDefault()` on it – read more about [event handling](event-handling.html).) </ins> `React.autoBind()` is a simple way to ensure that a method is always bound to its component. Inside the method, `this` will be bound to the component instance.

this.props.onCommentSubmit({author: author, text: text}); this.refs.author.getDOMNode().value = ''; this.refs.text.getDOMNode().value = ''; <ins> return false; </ins> }), render: function() { return (


Question:
Using 0.4.0 is giving me this error on a large number of files: I narrowed down that file to the simplest thing that causes it: Originally posted by in
Fixed in 0.4.1

// The signature call is split in two parts. One part is called inside the function. // This is used to signal when first render happens. <ins> if (path.node.body.type !== 'BlockStatement') { path.node.body = t.blockStatement([ t.returnStatement(path.node.body), ]); } </ins> path .get('body') .unshiftContainer(

`), ).toMatchSnapshot(); }); <ins> it('can handle implicit arrow returns', () => { expect( transform(` export default () => useContext(X); export const Foo = () => useContext(X); module.exports = () => useContext(X); const Bar = () => useContext(X); const Baz = memo(() => useContext(X)); const Qux = () => (0, useContext(X)); `), ).toMatchSnapshot(); }); </ins> });

// Jest Snapshot v1, https://goo.gl/fbAQLP <ins> exports[`ReactFreshBabelPlugin can handle implicit arrow returns 1`] = ` var _s = $RefreshSig$(), _s2 = $RefreshSig$(), _s3 = $RefreshSig$(), _s4 = $RefreshSig$(), _s5 = $RefreshSig$(), _s6 = $RefreshSig$(); export default _s(() => { _s(); return useContext(X); }, "useContext{}"); export const Foo = () => { _s2(); return useContext(X); }; _s2(Foo, "useContext{}"); _c = Foo; module.exports = _s3(() => { _s3(); return useContext(X); }, "useContext{}"); const Bar = () => { _s4(); return useContext(X); }; _s4(Bar, "useContext{}"); _c2 = Bar; const Baz = _c4 = memo(_c3 = _s5(() => { _s5(); return useContext(X); }, "useContext{}")); const Qux = () => { _s6(); return 0, useContext(X); }; _s6(Qux, "useContext{}"); _c5 = Qux; var _c, _c2, _c3, _c4, _c5; $RefreshReg$(_c, "Foo"); $RefreshReg$(_c2, "Bar"); $RefreshReg$(_c3, "Baz$memo"); $RefreshReg$(_c4, "Baz"); $RefreshReg$(_c5, "Qux"); `; </ins> exports[`ReactFreshBabelPlugin does not consider require-like methods to be HOCs 1`] = ` const A = require('A');


Question:
Do you want to request a feature or report a bug? I want to report a bug. What is the current behavior? Event handlers on elements are fired twice, when hovering from one element onto the next. 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? Event handlers should only fire once. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.8.4 ReactDOM 16.8.4 Chrome 76.0.3809.132 Firefox 69.0 (64-Bit) Edge 44..267.0
After testing it again and again, I found how to reproduce it: Step 1, render a new component inside a rendered component; Step 2, inside the new component, mouse enter a node from its sibling. Current result: onMouseEnter is called more than once. Demo: We may change the issue title because it's not related with . I've made a test and fixture for this: Hope the information can be helpful. I still have no idea how to fix it. If there's no one working on this, I would like to pick this up. There's a similar issue Do you have any advice?
Go for it,
Let's close this? I see the fix was merged in .

import FixtureSet from '../../FixtureSet'; import MouseMovement from './mouse-movement'; <ins> import MouseEnter from './mouse-enter'; </ins> const React = window.React;

return ( <FixtureSet title="Mouse Events"> <MouseMovement /> <ins> <MouseEnter /> </ins> </FixtureSet> ); }

 import TestCase from '../../TestCase'; const React = window.React; const ReactDOM = window.ReactDOM; const MouseEnter = () => { const containerRef = React.useRef(); React.useEffect(function() { const hostEl = containerRef.current; ReactDOM.render(<MouseEnterDetect />, hostEl, () => { ReactDOM.render(<MouseEnterDetect />, hostEl.childNodes[1]); }); }, []); return ( <TestCase title="Mouse Enter" description="" affectedBrowsers="Chrome, Safari, Firefox"> <TestCase.Steps>
Mouse enter the boxes below, from different borders
 </TestCase.Steps> <TestCase.ExpectedResult> Mouse enter call count should equal to 1;
 Issue{' '}  #16763 {' '} should not happen.
 </TestCase.ExpectedResult>
 </TestCase> ); }; const MouseEnterDetect = () => { const [log, setLog] = React.useState({}); const firstEl = React.useRef(); const siblingEl = React.useRef(); const onMouseEnter = e => { const timeStamp = e.timeStamp; setLog(log => { const callCount = 1 + (log.timeStamp === timeStamp ? log.callCount : 0); return { timeStamp, callCount, }; }); }; return ( <React.Fragment>
 Mouse enter call count: {log.callCount || ''}

 </React.Fragment> ); }; export default MouseEnter;

accumulateEnterLeaveDispatches(leave, enter, from, to); <ins> if (isOutEvent && from && nativeEventTarget !== fromNode) { return [leave]; } </ins> return [leave, enter]; }, };

expect(childEnterCalls).toBe(1); expect(parentEnterCalls).toBe(0); });  // Test for https://github.com/facebook/react/issues/16763. it('should call mouseEnter once from sibling rendered inside a rendered component', done => { const mockFn = jest.fn(); class Parent extends React.Component { constructor(props) { super(props); this.parentEl = React.createRef(); } componentDidMount() { ReactDOM.render(<MouseEnterDetect />, this.parentEl.current); } render() { return
; } } class MouseEnterDetect extends React.Component { constructor(props) { super(props); this.firstEl = React.createRef(); this.siblingEl = React.createRef(); } componentDidMount() { this.siblingEl.current.dispatchEvent( new MouseEvent('mouseout', { bubbles: true, cancelable: true, relatedTarget: this.firstEl.current, }), ); expect(mockFn.mock.calls.length).toBe(1); done(); } render() { return ( <React.Fragment>

 </React.Fragment> ); } } ReactDOM.render(<Parent />, container); });  });


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

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

export default function EditableValue({ className = '', <del> dataType, </del> initialValue, overrideValueFn, path,

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

{isEditable ? ( <EditableValue  dataType={dataType}   initialValue={value}  overrideValueFn={((overrideValueFn: any): OverrideValueFn)} path={path}  initialValue={value}  /> ) : ( {displayValue}

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

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

}); }, []); <del> return useMemo( () => ({ editableValue, hasPendingChanges: smartStringify(initialValue) !== editableValue, isValid, parsedValue, reset, update, }), [editableValue, initialValue, isValid, parsedValue], ); </del> <ins> return { editableValue, hasPendingChanges: smartStringify(initialValue) !== editableValue, isValid, parsedValue, reset, update, }; </ins> } export function useIsOverflowing(


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

document.body.removeChild(parentContainer); });  it('regression test: Suspense + hydration in legacy mode ', () => { const element = document.createElement('div'); element.innerHTML = '
Hello World
'; ReactDOM.hydrate( <React.Suspense>
Hello World
 </React.Suspense>, element, ); });  });

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); }


Question:
<!-- 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? Throw exception, don't run tests. SyntaxError: missing ) after argument list 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: one of the commands: yarn debug-test yarn debug-test-persistent yarn debug-test-build-devtools chrome://inspect and press “Inspect”. What is the expected behavior? Possibility debug tests. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.2.0 and higher. Chrome 77.0.3865.120 Windows 10. Older version React hasn't this feature.
fixed in

"lint": "node ./scripts/tasks/eslint.js", "lint-build": "node ./scripts/rollup/validate/index.js", "postinstall": "node node_modules/fbjs-scripts/node/check-dev-engines.js package.json", <ins> "debug-test": "cross-env NODE_ENV=development node --inspect-brk node_modules/.bin/jest --config ./scripts/jest/config.source.js --runInBand", </ins> "test": "cross-env NODE_ENV=development jest --config ./scripts/jest/config.source.js", "test-prod": "cross-env NODE_ENV=production jest --config ./scripts/jest/config.source.js", "test-prod-build": "yarn test-build-prod",


Question:
<!-- 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? Throw exception, don't run tests. SyntaxError: missing ) after argument list 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: one of the commands: yarn debug-test yarn debug-test-persistent yarn debug-test-build-devtools chrome://inspect and press “Inspect”. What is the expected behavior? Possibility debug tests. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.2.0 and higher. Chrome 77.0.3865.120 Windows 10. Older version React hasn't this feature.
fixed in

"lint-build": "node ./scripts/rollup/validate/index.js", "extract-errors": "yarn build --type=dev --extract-errors", "postinstall": "node node_modules/fbjs-scripts/node/check-dev-engines.js package.json && node ./scripts/flow/createFlowConfigs.js && node ./scripts/yarn/downloadReactIsForPrettyFormat.js", <del> "debug-test": "cross-env NODE_ENV=development node --inspect-brk node_modules/.bin/jest --config ./scripts/jest/config.source.js --runInBand", </del> <ins> "debug-test": "cross-env NODE_ENV=development node --inspect-brk node_modules/jest/bin/jest.js --config ./scripts/jest/config.source.js --runInBand", </ins> "test": "cross-env NODE_ENV=development jest --config ./scripts/jest/config.source.js", "test-persistent": "cross-env NODE_ENV=development jest --config ./scripts/jest/config.source-persistent.js", <del> "debug-test-persistent": "cross-env NODE_ENV=development node --inspect-brk node_modules/.bin/jest --config ./scripts/jest/config.source-persistent.js --runInBand", </del> <ins> "debug-test-persistent": "cross-env NODE_ENV=development node --inspect-brk node_modules/jest/bin/jest.js --config ./scripts/jest/config.source-persistent.js --runInBand", </ins> "test-prod": "cross-env NODE_ENV=production jest --config ./scripts/jest/config.source.js", "test-prod-build": "yarn test-build-prod", "test-build": "cross-env NODE_ENV=development jest --config ./scripts/jest/config.build.js", "test-build-prod": "cross-env NODE_ENV=production jest --config ./scripts/jest/config.build.js", "test-build-devtools": "cross-env NODE_ENV=development jest --config ./scripts/jest/config.build-devtools.js", <del> "debug-test-build-devtools": "cross-env NODE_ENV=development node --inspect-brk node_modules/.bin/jest --config ./scripts/jest/config.build-devtools.js", </del> <ins> "debug-test-build-devtools": "cross-env NODE_ENV=development node --inspect-brk node_modules/jest/bin/jest.js --config ./scripts/jest/config.build-devtools.js", </ins> "test-dom-fixture": "cd fixtures/dom && yarn && yarn prestart && yarn test", "flow": "node ./scripts/tasks/flow.js", "flow-ci": "node ./scripts/tasks/flow-ci.js",


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

} const {types: t} = babel; <ins> const refreshReg = t.identifier(opts.refreshReg || '$RefreshReg$'); const refreshSig = t.identifier(opts.refreshSig || '$RefreshSig$'); </ins> const registrationsByProgramPath = new Map(); function createRegistration(programPath, persistentID) {

const sigCallID = path.scope.generateUidIdentifier('_s'); path.scope.parent.push({ id: sigCallID, <del> init: t.callExpression(t.identifier('$RefreshSig$'), []), </del> <ins> init: t.callExpression(refreshSig, []), </ins> }); // The signature call is split in two parts. One part is called inside the function.

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

skipEnvCheck: true, // To simplify debugging tests: emitFullSignatures: true, <ins> ...options.freshOptions, </ins> }, ], ...(options.plugins || []),

`), ).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> });

$RefreshReg$(_c2, "Bar"); `; <ins> exports[`ReactFreshBabelPlugin uses custom identifiers for $RefreshReg$ and $RefreshSig$ 1`] = ` var _s = import.meta.refreshSig(); export default function Bar() { _s(); useContext(X); return <Foo />; } _s(Bar, "useContext{}"); _c = Bar; ; var _c; import.meta.refreshReg(_c, "Bar"); `; </ins> exports[`ReactFreshBabelPlugin uses original function declaration if it get reassigned 1`] = ` function Hello() { return
Hi
;