We’re not yet asking application authors to try the release.

People won't listen (like me).

For example, TikTok has upgraded to React 18 already (https://twitter.com/Brooooook_lyn/status/1402632529270632456?s=20)

Since people want to try out fresh things immediately, I think a list of what is blocking people from upgrading is helpful and can reduce other one's time-wasting.

<!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. -->

React version: 17.0.2

Steps To Reproduce

1. Render a button and a scrollable list with a height of 150px. The list should contain an array of 15 items, making sure to set the key prop of each item to unique values.
2. Observe that you can see around 8 of the original 15 list items in view.
3. On clicking the button, insert 15 more items into the beginning of the list, once again making sure to set the key prop of each item to unique values.
4. Observe that you can now see around 8 of the new list items in view.

<!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. -->

Link to code example: https://codesandbox.io/s/keen-sound-7q5yf?file=/src/App.js

<!-- Please provide a CodeSandbox (https://codesandbox.io/s/new), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: https://stackoverflow.com/help/mcve. -->

The current behavior

If the scroll position is at the very top of a list, after inserting new items at the beginning of the list, the new items are now visible.

The expected behavior

If the scroll position is at the very top of a list, after inserting new items at the beginning of the list, the original items should remain visible.

NOTE: When the scroll position is 1 or more pixels from the top of a list, after inserting new items at the beginning of the list, the new items remain visible as expected.

Hi! Can you clarify what would be the purpose of an issue like this? We’re not yet asking application authors to try the release.

The Alpha is focused on the library maintainers, and there will be a several months period before the Beta. It’s expected things would need adjustment early on, and I’m worried making a list of popular libraries before the authors even got a chance to try the release might be a bit premature.

We are committed to working with library authors and helping find recommendations where they’re unclear, including on this issue tracker. I’m just not sure that making a public list is the right way to kick this off.

What do you think?

https://github.com/ReactTraining/react-router/issues/7870

I do not have permission to post https://github.com/reactwg/react-18/discussions. Please open and pin a new issue in that repo to list all widely-used library that does not work with React 18 or need special handling.

This issue seems to be solved by https://github.com/facebook/react/pull/18031

<!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory.

Before submitting a pull request, please make sure the following is done:

1. Fork the repository and create your branch from master.
2. Run yarn in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (yarn test). Tip: yarn test --watch TestName is helpful in development.
5. Run yarn test --prod to test in the production environment. It supports the same options as yarn test.
6. If you need a debugger, run yarn debug-test --watch TestName, open chrome://inspect, and press "Inspect".
7. Format your code with prettier (yarn prettier).
8. Make sure your code lints (yarn lint). Tip: yarn linc to only check changed files.
9. Run the Flow type checks (yarn flow).
10. If you haven't already, complete the CLA.

Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html -->

Summary

<!-- Dependabot npm and yarn fixtures dom handlebars 4.7.7 -->

<!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory.

Before submitting a pull request, please make sure the following is done:

1. Fork the repository and create your branch from master.
2. Run yarn in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (yarn test). Tip: yarn test --watch TestName is helpful in development.
5. Run yarn test --prod to test in the production environment. It supports the same options as yarn test.
6. If you need a debugger, run yarn debug-test --watch TestName, open chrome://inspect, and press "Inspect".
7. Format your code with prettier (yarn prettier).
8. Make sure your code lints (yarn lint). Tip: yarn linc to only check changed files.
9. Run the Flow type checks (yarn flow).
10. If you haven't already, complete the CLA.

Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html -->

Summary

<!-- it hadn't been solved-->

@mmnoo that's sort of what I was saying. Think of it is less as "rules", and think of it as "how is this going to potentially change behavior in my application?".

I can't give specifics, because I don't know your app and I don't know what side effects you're considering doing here.

If the "side effect" is logging to the console or writing to localStorage, then while it's technically "breaking the rules", it's meaningless in the grand scheme and won't cause bugs.

If it's, say, making an HTTP DELETE call at the wrong time... then that could be very bad for your app :)

So, try to think about behavior based on the stated way React is going to execute things, not "am I breaking the rules".

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

<!-- 0 failure: 0 warning:

1 markdown notices DangerID: danger-id-stable; -->

Comparing: 1a106bdc2abc7af190b791d13b2ead0c2c556f7a...4b09c091809081be04a87986c45f8164a6ec7c0c

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

<p align="right"> Generated by :no_entry_sign: <a href="https://danger.systems/js">dangerJS</a> against 4b09c091809081be04a87986c45f8164a6ec7c0c </p>

Hi @houssemchebeb!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

Summary

Fix typo in react-devtools-shared

Hi. I just published a library and it contains a wrapper around Portals and it dodges this event bubbling behaviour by portal-ling the portal itself. I didn't really test the implementation but feel free to check it out.

Portal Renderer code - https://github.com/nibmz7/nimz-app/blob/main/core/utils/Portal/PortalRenderer.tsx Portal code - https://github.com/nibmz7/nimz-app/blob/main/core/utils/Portal/index.tsx The library if you intend to try it out - https://www.npmjs.com/package/nimz-utils

I haven't tried the library out myself actually 😅. If it doesn't work, you may copy for portals over to your project.

Just a suggestion

In React 18 , React should accept extra params to setState function so dev can specify what changed in more general terms that he/she can use in React.memo() to determine if that changes should re-render the specific component with the new data

it should be something like this

setState(
  [...state.users, user], 
  {action:'USER_ADDED', id : 'some_id'}
);

the broadcast can be any arbitrary data

and then in the User component, we can catch that broadcast in React.memo() like this

const User= (user)=>{
   // component code   
}

export default React.memo(User, (prev, next, brodcast)=>{
  if(broadcast?.action === 'ACTION_ADDED'  &&  next.id !== broadcast.id){
   // should not re-render this component
   return true;
 }
 return false;
});

this should work with batch setState as well just instead of object, broadcast should have an array of broadcasts

this will save the devs from deep comparison of props if it holds a lot of data nodes in it.

@markerikson that is a very useful explanation, thanks for taking the time to write it.

I think I have another solution to my specific problem that is less convoluted than a useEffect. (Munging ui (focus) state with data state as a tradeoff).

If I were to pollute my reducer with a side effect and there was no downside to redundant calls to that side effect, is there still a risk of issues with your understanding?

Just curious where rules can be bent. Not meaning to call all of FP ideology as I quite like it. Although when blindly followed anything start to feel that way :)

What’s the idiomatic way to do cleanup for things that aren’t async, but just require disposal?

Here is one example above (I like it and go back to it because I know it well - but it's similar for other sync APIs going forward):

const ac = new AbortController();
const { signal } = ac;
const element = getElementSomeHow();
element.addEventListener('click', onClick, { signal });
element.addEventListener('mousedown', onMouseDown, { signal });
element.addEventListener('mouseup', onMouseUp, { signal });
// eventually we want to cleanup
ac.abort(); // removes all listeners

@gaearon that's a good point, if you look carefully you'll see a bunch of the other APIs we have are more IDisposable than CancellationToken. The addEventListener example above is a good example.

Given the web converged on "disinterest semantics" for cancellation (cancellation is a request rather than an error) - the line between "cancellation" and "disposing a resource" is hair-thin (dispose a resource but cancel an action mostly).

However - for React in particular I think these sort of semantics make a ton of sense:

• Something like IDisposable typically means "you have to dispose it now when the user does .dispose. It typically comes with life-time management guarantees (like try using in the JS proposal case) which is the opposite of what frameworks would want (to control the lifecycle).
• Cancellation semantics like with AbortSignal mean "the producer upstream has expressed disinterest in this action" (data fetching, uploads, sockets listening, file actions, workers etc) - this gives React and the calling code a lot more flexibility.

_{Note: A logical next step is to loop in some more WHATWG involved folks.}

_{Note 2: I'm happy to loop in some of the .NET folks as well as some of the .NET folks who moved from C# to TS if that'd help but I'd like to keep the scope of the ask/discussion here small - aligning React with web platform APIs with regards to AbortSignal. Stuff like explicit resource management would be great to have but would not map well to React's use case where the framework needs to control the lifetime of resources rather than the calling code.}

I think conceptually it doesn’t feel like the right fit to me because (in .NET terms) effect cleanup is more like IDisposable than CancellationToken. But that’s just my hunch so I would need to see more comparisons to understand if there’s a real problem or I’m making it up.

What’s the idiomatic way to do cleanup for things that aren’t async, but just require disposal?

Yes, it's the undefined that's the problem for the cleanup case :)

I suspect it'll be even more so when concurrent mode becomes "the norm".

Though really - between "force everyone to return a function" and "take an AbortSignal argument like web APIs" I'd pick the latter as it makes for a much nicer API that "throws you to the pit of success" more often.

if react threw an error (at least in developer builds) if a function isn't returned from useEffect that would also be a nice change.

Hmm. I thought we are throwing an error if what you return is neither undefined nor a function.

Website or app

i was using local host

Repro steps

i was adding redux devtools

How often does this bug happen?

Every time

DevTools package (automated)

react-devtools-extensions

DevTools version (automated)

4.13.5-0ae5290b54

Error message (automated)

Could not inspect element with id 38

Error call stack (automated)

No response

Error component stack (automated)

at InspectedElementContextController (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:31392:3)
    at Suspense
    at ErrorBoundary_ErrorBoundary (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:30033:5)
    at div
    at InspectedElementErrorBoundaryWrapper (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:30176:3)
    at NativeStyleContextController (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:32661:3)
    at div
    at div
    at OwnersListContextController (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:28268:3)
    at SettingsModalContextController (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:28709:3)
    at Components_Components (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:34512:52)
    at ErrorBoundary_ErrorBoundary (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:30033:5)
    at PortaledContent (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:30147:5)
    at div
    at div
    at ProfilerContextController (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:34138:3)
    at TreeContextController (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:24945:3)
    at SettingsContextController (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:25548:3)
    at ModalDialogContextController (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:30234:3)
    at DevTools_DevTools (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:37241:3)

GitHub query string (automated)

https://api.github.com/search/issues?q=Could not inspect element with id 38 in:title is:issue is:open is:public label:"Component: Developer Tools" repo:facebook/react

As a second alternative - if react threw an error (at least in developer builds) if a function isn't returned from useEffect that would also be a nice change.

Though I think doing the standard web thing is probably(?) good

Thanks for the response.

We did consider this API during useEffect design. At that point, we made an explicit decision against it. There are a few reasons. useEffect by itself is an escape hatch. The goal is to eventually have a better high-level replacement for 90% cases. Your examples include data fetching.

That decision probably made sense - now (or soon) might be a good time to reconsider that decision since the web APIs themselves changed. Note that in the past AbortSignal was used only for fetch but right now it's supported in a lot more areas. See the other event example for one.

In Node.js all the APIs converged around cancellation with signals too. Data fetching isn't 90% of the problematic cases IMO - as more and more web APIs converge around the web cancellation primitive this will be easier and easier.

We know async effects are commonplace today, and React makes them a bit convoluted. That is intentional. We don't want to make that pattern too convenient because ultimately writing effects is hard.

I agree with that last statement wholeheartedly - writing effects is hard. Writing async code and writing side effects is hard - this is why it's so important we make the "correct" thing more obvious.

Right now in a large(ish) codebase I see a lot:

useEffect(async () => {
  // no cleanup
}, []);
useEffect(() => {
  (async () => {
    
  })(); 
}); // still no cleanup

I think having AbortSignal as an argument makes the fact cleanup should happen a lot more obvious (I'd hope) much like what promises did to APIs compared to callbacks.

I've got this error today as well on Firefox 89. Adding to OP's report, this happens when refreshing the page while the dev console is open with the Components tab shown:

Im curious on the reasoning for the React team not prioritizing this.

I'm not on the React team, but I can think of at least a few possible reasons off the top of my head:

• The team is small (only a handful of engineers)
• The team has been focused on the changes that are planned for React 18, which center around Concurrent Rendering and Suspense (per Introducing React 18 and the other threads in that discussion group)
• This may not be a thing that they feel is necessary or sufficiently useful
• Even if they do plan to try it at some point, it may be very low priority compared to the current work that they're trying to get out the door

(Other than FP ideology, I wonder what the other reasons for avoiding effects in reducers are. Will it necessarily result in a a reasonable bug risk? More research needed there on my part)

There's excellent reasons for this, and it's not just "ideology".

In Concurrent Rendering, React can and will start rendering components, only to pause and throw away the results. Because of that, React expects that the rendering process truly is "pure" with no side effects.

React calls your reducers at a couple points in the lifecycle and rendering process. It apparently does sometimes try to call it immediately when the update is queued to see if there's a chance of bailing out early. Assuming it keeps going, then it will normally get called during the rendering phase.

So, if you start putting side effects in reducers, you will almost definitely see unexpected behavior because those effects are running even if the component isn't getting updated at that point.

Note that I'm not saying that the feature being asked for in this thread is bad, impossible, or unwanted.

I'm just observing that the React team has limited resources and other major priorities atm, and that proposed workarounds that involve side effects in reducer functions are likely going to cause problems in real apps.

I suppose this is still not fixed in React 18 alpha. We still have hopes for stable 18 release.

Sometimes responding to changes on the entire store will make sense. Other times it wont.

In my case, I want to know when the store is updated with my item in a very specific scenario so I can do a thing related to the updated item. I want my code to be declarative and read nicely. So dispatch({ type: 'doVeryVerySpecificThingEdgeCase', payload: id}}).then(respondAndDoSomething(id)) or using a callback makes a whole lot more sense than having to store that id in some component state (and know when to trigger clearing it), and then listening to store changes with an effect which grabs that id and then call respondAndDoSomethingWithId(id) after checking 500 conditionals to make sure I only call it when a very specific edge case scenario occurs.

With the latter, I need to make extra sure respondAndDoSomething(id) doesnt get called too much and its unlikely to be colocated anywhere near the actual logic that triggered it (because now its in useEffect magic which leans much more to the imperative than to the declarative in this case)

Why does it matter when an action was delivered? What's that mean - it was applied to the store by the reducer? The effect of the action is an updated store. The only event a component should be interested in, due to an action, is that the store was updated, and it can use a selector to react to that event.

Im curious on the reasoning for the react team not prioritizing this.

Using a useEffect with state in the dependency array wont work for me. Not with maintainable or clean code anyway. I have added a new record to my state collection which results in a bunch of inputs being created/recreated from that collection. I want to focus on the new input from the record I created without tracking it by id in some new component state variable for current focus in a useEffect (which would likely interfere with the browsers focus behaviour and open a fragile can of worms).

I should be able to listen for the reducer to finish and focus the input within the function scope where I call dispatch rather than creating some complicated confusing useEffect magic code that is prone to overreach for the purpose of input focus at least. Avoiding what to me feels like an inappropriate overuse of useEffect, makes the code way easier to reason through too.

I could break reducer rules and call a callback/make a side effect, which would be an anti-pattern, but would be easier-to-reason-about code than useEffect (and way cheaper for my client).

(Other than FP ideology, I wonder what the other reasons for avoiding effects in reducers are. Will it necessarily result in a a reasonable bug risk? More research needed there on my part)