I currently get an error when using the prependEdge directive for a connection that has been aliased. Works fine for any connections not aliased.

The error message: The connection with id 'client:VXNlcjox:__ProfileCurrentGoals_currentGoals_connection' doesn't exist.

The connection with goals renamed to alias currentGoals

  fragment ProfileCurrentGoals_user on User
  @argumentDefinitions(
    count: { type: "Int", defaultValue: 10 }
    cursor: { type: "String" }
  )
  @refetchable(queryName: "ProfileCurrentGoalsQuery") {
    id
    currentGoals: goals(first: $count, after: $cursor, isCompleted: false)
      @connection(key: "ProfileCurrentGoals_currentGoals") {
      edges {
        cursor
        node {
          id
          ...GoalNode_goal
        }
      }
    }
  }

The mutation:

  mutation CreateGoalMutation($connections: [ID!]!, $input: CreateGoalInput!) {
    createGoal(input: $input) {
      successful
      result {
        goalEdge @prependEdge(connections: $connections) {
          cursor
          node {
            ...GoalNode_goal
          }
        }
      }
    }
  }

In my case it was caused by a duplicate of schema.graphql stored in another folder.

Yep. Same here. For me, I had an older file named schema3.sql in the same folder. The unhelpful error message would have driven me insane. I was saved by a Google search that brought me here.

:x: Deploy Preview for zh-hans-reactjs failed.

:hammer: Explore the source changes: caaae6806292092c852a681a68da1e8272ca3ad3

:mag: Inspect the deploy log: https://app.netlify.com/sites/zh-hans-reactjs/deploys/60ceb6b2baee27000776a3f5

我的理解是这样的。不知道对不对。原文是 also ，表达意思是 同样也会 。就是说，除了会在"组件卸载"时之行清除操作，“同样’也‘会”在更新的时候执行

<!--

Thank you for the PR! Contributors like you keep React awesome!

Please see the Contribution Guide for guidelines:

https://github.com/reactjs/reactjs.org/blob/master/CONTRIBUTING.md

If your PR references an existing issue, please add the issue number below

-->

This PR was automatically generated.

Merge changes from reactjs.org at f3baa6d0

The following files have conflicts and may need new translations:

• [x] content/docs/nav.yml
• [x] content/docs/concurrent-mode-suspense.md
• [x] content/docs/concurrent-mode-reference.md
• [x] content/docs/concurrent-mode-patterns.md
• [x] content/docs/concurrent-mode-intro.md
• [x] content/docs/concurrent-mode-adoption.md
• [x] content/blog/2021-06-08-the-plan-for-react-18.md

Please fix the conflicts by pushing new commits to this pull request, either by editing the files directly on GitHub or by checking out this branch.

DO NOT SQUASH MERGE THIS PULL REQUEST!

Doing so will "erase" the commits from master and cause them to show up as conflicts the next time we merge.

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

Hi @felipe-gdr!

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!

Matrix could also be an interesting option for project chat; it's an accessible option that's also open-source and not dependent on the generosity and ongoing support of any one given chat company, it being an open network.

(It can also be bridged to Discord if desired, though I'm unsure of the implementation details of setting that up.)

<!-- Ask a question or share feedback about the React 18 release here. -->

yarn run v1.22.5
$ react-scripts start

There might be a problem with the project dependency tree.
It is likely not a bug in Create React App, but something you need to fix locally.

The react-scripts package provided by Create React App requires a dependency:

  "babel-jest": "^26.6.0"

Don't try to install it manually: your package manager does it automatically.
However, a different version of babel-jest was detected higher up in 
the tree:

  C:\Users\UNION\node_modules\babel-jest (version: 27.0.2)

Manually installing incompatible versions is known to cause hard-to-debug issues.

If you would prefer to ignore this check, add SKIP_PREFLIGHT_CHECK=true to an .env file in your project.
That will permanently disable this message but you might encounter other issues.

To fix the dependency tree, try following the steps below in the exact order:

  1. Delete package-lock.json (not package.json!) and/or yarn.lock in your project folder.
  2. Delete node_modules in your project folder.
  3. Remove "babel-jest" from dependencies and/or devDependencies in 
the package.json file in your project folder.
  4. Run npm install or yarn, depending on the package manager you use.

In most cases, this should be enough to fix the problem.
If this has not helped, there are a few other things you can try:    

  5. If you used npm, install yarn (http://yarnpkg.com/) and repeat the above steps with it instead.
     This may help because npm has known issues with package hoisting which may get resolved in future versions.

  6. Check if C:\Users\UNION\node_modules\babel-jest is outside your 
project directory.
     For example, you might have accidentally installed something in 
your home folder.

  7. Try running npm ls babel-jest in your project folder.
     This will tell you which other package (apart from the expected 
react-scripts) installed babel-jest.

If nothing else helps, add SKIP_PREFLIGHT_CHECK=true to an .env file 
in your project.
That would permanently disable this preflight check in case you want 
to proceed anyway.

P.S. We know this message is long but please read the steps above :-) We hope you find them helpful!

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command. 



- I'm not able to solve this issue, I did tried the following steps but it seems like I'm not getting this? Please give some suggestions, so that i could work on my project smoothly.

Support requests filed as GitHub issues often go unanswered. We want you to find the answer you're looking for, so we suggest the following alternatives:

Coding Questions If you have a coding question related to React and React DOM, it might be better suited for Stack Overflow. It's a great place to browse through frequent questions about using React, as well as ask for help with specific questions.

https://stackoverflow.com/questions/tagged/react

Talk to other React developers There are many online forums which are a great place for discussion about best practices and application architecture as well as the future of React.

https://reactjs.org/community/support.html

<!-- Ask a question or share feedback about the React 18 release here. -->

yarn run v1.22.5
$ react-scripts start

There might be a problem with the project dependency tree.
It is likely not a bug in Create React App, but something you need to fix locally.

The react-scripts package provided by Create React App requires a dependency:

  "babel-jest": "^26.6.0"

Don't try to install it manually: your package manager does it automatically.
However, a different version of babel-jest was detected higher up in 
the tree:

  C:\Users\UNION\node_modules\babel-jest (version: 27.0.2)

Manually installing incompatible versions is known to cause hard-to-debug issues.

If you would prefer to ignore this check, add SKIP_PREFLIGHT_CHECK=true to an .env file in your project.
That will permanently disable this message but you might encounter other issues.

To fix the dependency tree, try following the steps below in the exact order:

  1. Delete package-lock.json (not package.json!) and/or yarn.lock in your project folder.
  2. Delete node_modules in your project folder.
  3. Remove "babel-jest" from dependencies and/or devDependencies in 
the package.json file in your project folder.
  4. Run npm install or yarn, depending on the package manager you use.

In most cases, this should be enough to fix the problem.
If this has not helped, there are a few other things you can try:    

  5. If you used npm, install yarn (http://yarnpkg.com/) and repeat the above steps with it instead.
     This may help because npm has known issues with package hoisting which may get resolved in future versions.

  6. Check if C:\Users\UNION\node_modules\babel-jest is outside your 
project directory.
     For example, you might have accidentally installed something in 
your home folder.

  7. Try running npm ls babel-jest in your project folder.
     This will tell you which other package (apart from the expected 
react-scripts) installed babel-jest.

If nothing else helps, add SKIP_PREFLIGHT_CHECK=true to an .env file 
in your project.
That would permanently disable this preflight check in case you want 
to proceed anyway.

P.S. We know this message is long but please read the steps above :-) We hope you find them helpful!

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command. 



- I'm not able to solve this issue, I did tried the following steps but it seems like I'm not getting this? Please give some suggestions, so that i could work on my project smoothly.

Raised in the wrong project... will raise in react project.

Hi,

It seems that there is a memory leak issue when using the set state hook lambda syntax, and setting the state to the previous state. The set state lambda in this scenario seems to be retained and never garbage collected.

Please ignore the contrived example, it's intentionally whittled down to the exact issue. It's quite a common requirement in our application to subscribe to an rxjs observable in a useEffect hook, then update some state when events are received (but the data received might not always result in a state change). The lambda syntax is required in the set state call because current state would otherwise always be the default state due to the closure around it in the useEffect hook. Even if there was another way to do it to avoid the issue, it's still a surprising behaviour and makes it harder to fall into the 'pit of success'.

Reproduction below:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>Memory leak repro</title>
    <script src="https://unpkg.com/react@17/umd/react.development.js"></script>
    <script src="https://unpkg.com/react-dom@17/umd/react-dom.development.js"></script>

    <script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
  </head>
  <body>
    <div id="root"></div>
    <script type="text/babel">
        function App() {
          const [someState, setSomeState] = React.useState(false);
          React.useEffect(() => {
             const interval = setInterval(() => {
               const a = []; 
               for (var i = 0; i < 1000; i++) {
                 a.push({}); //produce lots of garbage objects to make the leak easier to see
               }
               // memory leak when setting state to previous state
               // set state lambda is not garbage collected and retained along with all of its captured closures
               setSomeState(state => a.length > 0 ? state : !state);

               // no memory leak when setting state to something other than previous state
               // set state lambda (and it's closures) are garbage collected as expected
               // setSomeState(state => a.length == 0 ? state : !state);
              }, 100);
             return () => clearInterval(interval);
          }, []);
          return <div>Test Memory Leak</div>;
      }


      ReactDOM.render(
        <App/>,
        document.getElementById('root')
      );

    </script>
  </body>
</html>

The best memory profiler to see this is the 'Allocation instrumentation on timeline' mode in chrome devtools.

I have confirmed this also happens using production / minified bundles so it's not a dev build issue.

Right now as a workaround I need to use 'hacks' like useRef and forceUpdate implementations which is a real shame so keen to see this fixed.

Many thanks!

Hi,

It seems that there is a memory leak issue when using the set state hook lambda syntax, and setting the state to the previous state. The set state lambda in this scenario seems to be retained and never garbage collected.

Please ignore the contrived example, it's intentionally whittled down to the exact issue. It's quite a common requirement in our application to subscribe to an rxjs observable in a useEffect hook, then update some state when events are received (but the data received might not always result in a state change). The lambda syntax is required in the set state call because current state would otherwise always be the default state due to the closure around it in the useEffect hook. Even if there was another way to do it to avoid the issue, it's still a surprising behaviour and makes it harder to fall into the 'pit of success'.

Reproduction below:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>Memory leak repro</title>
    <script src="https://unpkg.com/react@17/umd/react.development.js"></script>
    <script src="https://unpkg.com/react-dom@17/umd/react-dom.development.js"></script>

    <script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
  </head>
  <body>
    <div id="root"></div>
    <script type="text/babel">
        function App() {
          const [someState, setSomeState] = React.useState(false);
          React.useEffect(() => {
             const interval = setInterval(() => {
               const a = []; 
               for (var i = 0; i < 1000; i++) {
                 a.push({}); //produce lots of garbage objects to make the leak easier to see
               }
               // memory leak when setting state to previous state
               // set state lambda is not garbage collected and retained along with all of its captured closures
               setSomeState(state => a.length > 0 ? state : !state);

               // no memory leak when setting state to something other than previous state
               // set state lambda (and it's closures) are garbage collected as expected
               // setSomeState(state => a.length == 0 ? state : !state);
              }, 100);
             return () => clearInterval(interval);
          }, []);
          return <div>Test Memory Leak</div>;
      }


      ReactDOM.render(
        <App/>,
        document.getElementById('root')
      );

    </script>
  </body>
</html>

The best memory profiler to see this is the 'Allocation instrumentation on timeline' mode in chrome devtools.

I have confirmed this also happens using production / minified bundles so it's not a dev build issue.

Right now as a workaround I need to use 'hacks' like useRef and forceUpdate implementations which is a real shame so keen to see this fixed.

Many thanks!

What happened

yarn tsc                 9.2s  Ср 30 дек 2020 13:02:33
yarn run v1.22.5
$ /home/i/all_work/pandadoc/kolas-editor-monorepo/node_modules/.bin/tsc
../../@types/immutable/index.d.ts:2686:22 - error TS2430: Interface 'Keyed<K, V>' incorrectly extends interface 'Seq<K, V>'.
  The types returned by 'map(...).map(...).flatMap(...).toJS()' are incompatible between these types.
    Type 'Object' is not assignable to type 'unknown[] | { [key: string]: unknown; }'.
      The 'Object' type is assignable to very few other types. Did you mean to use the 'any' type instead?
        Type 'Object' is not assignable to type '{ [key: string]: unknown; }'.
          The 'Object' type is assignable to very few other types. Did you mean to use the 'any' type instead?
            Index signature is missing in type 'Object'.

2686     export interface Keyed<K, V> extends Seq<K, V>, Collection.Keyed<K, V> {
                          ~~~~~

../../@types/immutable/index.d.ts:3234:22 - error TS2430: Interface 'Keyed<K, V>' incorrectly extends interface 'Collection<K, V>'.
  The types returned by 'toJS()' are incompatible between these types.
    Type 'Object' is not assignable to type 'unknown[] | { [key: string]: unknown; }'.
      The 'Object' type is assignable to very few other types. Did you mean to use the 'any' type instead?
        Type 'Object' is not assignable to type '{ [key: string]: unknown; }'.
          The 'Object' type is assignable to very few other types. Did you mean to use the 'any' type instead?
            Index signature is missing in type 'Object'.

3234     export interface Keyed<K, V> extends Collection<K, V> {
                          ~~~~~


Found 2 errors.

error Command failed with exit code 2.

How to reproduce

Install yarn add immutable@latest

// tsconfig.json
{
  "compilerOptions": {
    "skipLibCheck": false,
  }
}

// Run type checker
yarn tsc --noEmit

Resolved in https://github.com/immutable-js/immutable-js/pull/1827.

<!--

                            STOP AND READ THIS BEFORE POSTING YOUR ISSUE


                                              ---  Have a general question?  ---

First check out the Docs: https://facebook.github.io/immutable-js/docs/ And check out the Wiki: https://github.com/facebook/immutable-js/wiki/ Search existing issues: https://github.com/facebook/immutable-js/search?type=Issues&q=question Ask on Stack Overflow!: https://stackoverflow.com/questions/tagged/immutable.js?sort=votes

• Stack Overflow gets more attention

• Answered questions are searchable

• A whole community can answer

                                                     ---  Feature request?  ---
  

This library attempts to be as stable as possible so features have to meet a high bar to be added. This library also prefers interoperability with other libraries over continuous additions. Here are some tips to get your feature added:

• Search existing issues and pull requests first.

• Send a Pull Request! Start with API design and post for review early.

                                                        ---  Found a bug?  ---
  

Search existing issues first: https://github.com/facebook/immutable-js/search?type=Issues&q=bug Please ensure you're using the latest version, and provide some information below.

-->

What happened

The TypeScript signature of methods like first, last, etc that take a notSetValue is:

first<NSV>(notSetValue?: NSV): V | NSV;

In TypeScript (at least in 4.1.2) if no argument is passed, NSV becomes unknown, not undefined as documented.

Possible fix:

first<NSV = undefined>(notSetValue?: NSV): V | NSV;

I found this PR but it never got merged: #1653. I think = undefined is less verbose as it doesn't create a new overload. If going with this overload approach, the correct declaration would be (instead of the one in the PR):

first(): V | undefined;
first<NSV>(notSetValue?: NSV): V | NSV;

I'd create a PR but didn't know how you wanted to handle #1653.

Note that other methods that accept a notSetValue argument probably suffer from the same issue.

Thank you.

This has been resolved in https://github.com/immutable-js/immutable-js/pull/1676, but hasn't been released yet.

@leebyron Thanks for taking the time to get this project back up and running! Maintaining open-source is hard and unrewarding work and we appreciate the work you've put into this project to get it to where it is today.

I've started working on cleaning up the issues and PRs and created a milestone for the regressions from 3.x to 4.x (we have fixes for almost all of them on the fork, we just need to get the work moved over here). I'm excited to get these changes merged in, but don't want to step on your toes. The Slack workspace is still active if you're interested in joining there so we can coordinate our efforts (alternatively we could start a Discord server or add a channel on Reactiflux since that seems popular among the OSS/JS dev community). Or if you're fine with me starting to merge PRs I can just start doing that. I wasn't sure if you had a set plan for how to get the work from the fork merged in, or if we should just recreate the PRs on this repo so they can be re-vetted for inclusion here.

fixed https://github.com/immutable-js/immutable-js/issues/1643

Closing since this is an exact duplicate of https://github.com/immutable-js/immutable-js/pull/1654.