{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":10270250,"defaultBranch":"main","name":"react","ownerLogin":"facebook","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2013-05-24T16:15:54.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/69631?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1718140115.0","currentOid":""},"activityList":{"items":[{"before":"383b2a18456215d2d3ec46f33c0c912e84efa08f","after":"fb57fc5a8a66f38d65e3bc9f83213a0003da5702","ref":"refs/heads/main","pushedAt":"2024-06-11T23:12:39.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"sebmarkbage","name":"Sebastian Markbåge","path":"/sebmarkbage","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/63648?s=80&v=4"},"commit":{"message":"[Flight] Let Errored/Blocked Direct References Turn Nearest Element Lazy (#29823)\n\nStacked on #29807.\r\n\r\nThis lets the nearest Suspense/Error Boundary handle it even if that\r\nboundary is defined by the model itself.\r\n\r\nIt also ensures that when we have an error during serialization of\r\nproperties, those can be associated with the nearest JSX element and\r\nsince we have a stack/owner for that element we can use it to point to\r\nthe source code of that line. We can't track the source of any nested\r\narbitrary objects deeper inside since objects don’t track their stacks\r\nbut close enough. Ideally we have the property path but we don’t have\r\nthat right now. We have a partial in the message itself.\r\n\r\n![\"Screenshot]()
\r\n\r\nNote: The component name (Counter) is lost in the first message because\r\nwe don't print it in the Task. We use `\"use client\"` instead because we\r\nexpect the next stack frame to have the name. We also don't include it\r\nin the actual error message because the Server doesn't know the\r\ncomponent name yet. Ideally Client References should be able to have a\r\nname. If the nearest is a Host Component then we do use the name though.\r\nHowever, it's not actually inside that Component that the error happens\r\nit's in App and that points to the right line number.\r\n\r\nAn interesting case is that if something that's actually going to be\r\nconsumed by the props to a Suspense/Error Boundary or the Client\r\nComponent that wraps them fails, then it can't be handled by the\r\nboundary. However, a counter intuitive case might be when that's on the\r\n`children` props. E.g.\r\n`{clientReferenceOrInvalidSerialization}`.\r\nThis value can be inspected by the boundary so it's not safe to pass it\r\nso if it's errored it is not caught.\r\n\r\n## Implementation\r\n\r\nThe first insight is that this is best solved on the Client rather than\r\nin the Server because that way it also covers Client References that end\r\nup erroring.\r\n\r\nThe key insight is that while we don't have a true stack when using\r\n`JSON.parse` and therefore no begin/complete we can still infer these\r\nphases for Elements because the first child of an Element is always\r\n`'$'` which is also a leaf. In depth first that's our begin phase. When\r\nthe Element itself completes, we have the complete phase. Anything in\r\nbetween is within the Element.\r\n\r\nUsing this idea I was able to refactor the blocking tracking mechanism\r\nto stash the blocked information on `initializingHandler` and then on\r\nthe way up do we let whatever is nearest handle it - whether that's an\r\nElement or the root Chunk. It's kind of like an Algebraic Effect.\r\n\r\ncc @unstubbable This is something you might want to deep dive into to\r\nfind more edge cases. I'm sure I've missed something.\r\n\r\n---------\r\n\r\nCo-authored-by: eps1lon ","shortMessageHtmlLink":"[Flight] Let Errored/Blocked Direct References Turn Nearest Element L…"}},{"before":"5ad4e799fa7127370e03a9a2ef78dd9ee23374cf","after":"25dfa8e6018d707b7d0f7856ddaf592c47e7e25e","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-06-11T22:17:22.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Use the Nearest Parent of an Errored Promise as its Owner (#29814)\n\nStacked on #29807.\n\nConceptually the error's owner/task should ideally be captured when the\nError constructor is called but neither `console.createTask` does this,\nnor do we override `Error` to capture our `owner`. So instead, we use\nthe nearest parent as the owner/task of the error. This is usually the\nsame thing when it's thrown from the same async component but not if you\nawait a promise started from a different component/task.\n\nBefore this stack the \"owner\" and \"task\" of a Lazy that errors was the\nnearest Fiber but if the thing erroring is a Server Component, we need\nto get that as the owner from the inner most part of debugInfo.\n\nTo get the Task for that Server Component, we need to expose it on the\nReactComponentInfo object. Unfortunately that makes the object not\nserializable so we need to special case this to exclude it from\nserialization. It gets restored again on the client.\n\nBefore (Shell):\n![\"Screenshot]()
\n\nAfter (App):\n![\"Screenshot]()
\n\nDiffTrain build for [383b2a18456215d2d3ec46f33c0c912e84efa08f](https://github.com/facebook/react/commit/383b2a18456215d2d3ec46f33c0c912e84efa08f)","shortMessageHtmlLink":"Use the Nearest Parent of an Errored Promise as its Owner (#29814)"}},{"before":"39d07c2acde2cf6e332c9b9ad6bf94a538d58095","after":"d7dee0d1ad24beed512cb7eabf669219480982dd","ref":"refs/heads/builds/facebook-fbsource","pushedAt":"2024-06-11T22:17:19.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Use the Nearest Parent of an Errored Promise as its Owner (#29814)\n\nStacked on #29807.\n\nConceptually the error's owner/task should ideally be captured when the\nError constructor is called but neither `console.createTask` does this,\nnor do we override `Error` to capture our `owner`. So instead, we use\nthe nearest parent as the owner/task of the error. This is usually the\nsame thing when it's thrown from the same async component but not if you\nawait a promise started from a different component/task.\n\nBefore this stack the \"owner\" and \"task\" of a Lazy that errors was the\nnearest Fiber but if the thing erroring is a Server Component, we need\nto get that as the owner from the inner most part of debugInfo.\n\nTo get the Task for that Server Component, we need to expose it on the\nReactComponentInfo object. Unfortunately that makes the object not\nserializable so we need to special case this to exclude it from\nserialization. It gets restored again on the client.\n\nBefore (Shell):\n![\"Screenshot]()
\n\nAfter (App):\n![\"Screenshot]()
\n\nDiffTrain build for commit https://github.com/facebook/react/commit/383b2a18456215d2d3ec46f33c0c912e84efa08f.","shortMessageHtmlLink":"Use the Nearest Parent of an Errored Promise as its Owner (#29814)"}},{"before":"7200de2134e85d04ce07d569e29575090f7369d5","after":"7aaa0cd95186fb32f6710fab5b735d821eb5006c","ref":"refs/heads/gh/josephsavona/28/orig","pushedAt":"2024-06-11T22:16:45.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"},"commit":{"message":"[compiler] Instruction reordering\n\nAdds a pass just after DCE to reorder safely reorderable instructions (jsx, primitives, globals) closer to where they are used, to allow other optimization passes to be more effective. Notably, the reordering allows scope merging to be more effective, since that pass relies on two scopes not having intervening instructions — in many cases we can now reorder such instructions out of the way and unlock merging, as demonstrated in the changed fixtures.\n\nThe algorithm itself is described in the docblock.\n\nnote: This is a cleaned up version of #29579 that is ready for review.\n\nghstack-source-id: fe01f94e186e62171e7cc82e10d7864c48f932be\nPull Request resolved: https://github.com/facebook/react/pull/29863","shortMessageHtmlLink":"[compiler] Instruction reordering"}},{"before":"6b5cab78b4d6399634eb7fe4a6e3c12d9bd9705c","after":"d77fe0ad23668cc8312d071b3990956f187624fb","ref":"refs/heads/gh/josephsavona/28/head","pushedAt":"2024-06-11T22:16:43.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"},"commit":{"message":"Update on \"[compiler] Instruction reordering\"\n\n\nAdds a pass just after DCE to reorder safely reorderable instructions (jsx, primitives, globals) closer to where they are used, to allow other optimization passes to be more effective. Notably, the reordering allows scope merging to be more effective, since that pass relies on two scopes not having intervening instructions — in many cases we can now reorder such instructions out of the way and unlock merging, as demonstrated in the changed fixtures.\n\nThe algorithm itself is described in the docblock.\n\nnote: This is a cleaned up version of #29579 that is ready for review.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Instruction reordering\""}},{"before":"a26e3f403e1d732ecde87db119b4ce21cee20038","after":"383b2a18456215d2d3ec46f33c0c912e84efa08f","ref":"refs/heads/main","pushedAt":"2024-06-11T22:10:24.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"sebmarkbage","name":"Sebastian Markbåge","path":"/sebmarkbage","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/63648?s=80&v=4"},"commit":{"message":"Use the Nearest Parent of an Errored Promise as its Owner (#29814)\n\nStacked on #29807.\r\n\r\nConceptually the error's owner/task should ideally be captured when the\r\nError constructor is called but neither `console.createTask` does this,\r\nnor do we override `Error` to capture our `owner`. So instead, we use\r\nthe nearest parent as the owner/task of the error. This is usually the\r\nsame thing when it's thrown from the same async component but not if you\r\nawait a promise started from a different component/task.\r\n\r\nBefore this stack the \"owner\" and \"task\" of a Lazy that errors was the\r\nnearest Fiber but if the thing erroring is a Server Component, we need\r\nto get that as the owner from the inner most part of debugInfo.\r\n\r\nTo get the Task for that Server Component, we need to expose it on the\r\nReactComponentInfo object. Unfortunately that makes the object not\r\nserializable so we need to special case this to exclude it from\r\nserialization. It gets restored again on the client.\r\n\r\nBefore (Shell):\r\n![\"Screenshot]()
\r\n\r\nAfter (App):\r\n![\"Screenshot]()
","shortMessageHtmlLink":"Use the Nearest Parent of an Errored Promise as its Owner (#29814)"}},{"before":"57550bbb7add096fb6289d789c763c72e795bd31","after":null,"ref":"refs/heads/gh/mvitousek/2/orig","pushedAt":"2024-06-11T21:08:35.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"2cd012258311f12aaed643d1a78941b1dd449b79","after":null,"ref":"refs/heads/gh/mvitousek/2/head","pushedAt":"2024-06-11T21:08:35.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"2cd012258311f12aaed643d1a78941b1dd449b79","after":null,"ref":"refs/heads/gh/mvitousek/2/base","pushedAt":"2024-06-11T21:08:35.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"3b9f33aa9be7ce1c22d1a8d22d0f88c774ba1bbf","after":null,"ref":"refs/heads/gh/mvitousek/1/orig","pushedAt":"2024-06-11T21:08:32.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"2386f0978a718d4e0c470f5446d3564faeb97db5","after":null,"ref":"refs/heads/gh/mvitousek/1/head","pushedAt":"2024-06-11T21:08:32.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"2386f0978a718d4e0c470f5446d3564faeb97db5","after":null,"ref":"refs/heads/gh/mvitousek/1/base","pushedAt":"2024-06-11T21:08:32.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"27175f261d26c762ac865c034ad192a1681b0c8e","after":null,"ref":"refs/heads/gh/mvitousek/0/orig","pushedAt":"2024-06-11T21:08:30.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"0024710e1aa96eca4ef5dac231915b64118b071b","after":null,"ref":"refs/heads/gh/mvitousek/0/head","pushedAt":"2024-06-11T21:08:30.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"0024710e1aa96eca4ef5dac231915b64118b071b","after":null,"ref":"refs/heads/gh/mvitousek/0/base","pushedAt":"2024-06-11T21:08:30.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"}},{"before":"2c959f1d775e9c216d029d198971d06a1f8c892a","after":"a26e3f403e1d732ecde87db119b4ce21cee20038","ref":"refs/heads/main","pushedAt":"2024-06-11T21:08:28.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"[compiler] Expect component props annotations to be potential objects\n\nSummary: We now expect that candidate components that have Flow or TS type annotations on their first parameters have annotations that are potentially objects--this lets us reject compiling functions that explicitly take e.g. `number` as a parameter.\n\nghstack-source-id: e2c23348265b7ef651232b962ed7be7f6fed1930\nPull Request resolved: https://github.com/facebook/react/pull/29866","shortMessageHtmlLink":"[compiler] Expect component props annotations to be potential objects"}},{"before":"badbfbc9c8ae905e4e1848bb3259528f88e732d8","after":"2cd012258311f12aaed643d1a78941b1dd449b79","ref":"refs/heads/gh/mvitousek/2/base","pushedAt":"2024-06-11T21:08:26.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"Update on \"[compiler] Expect component props annotations to be potential objects\"\n\n\nSummary: We now expect that candidate components that have Flow or TS type annotations on their first parameters have annotations that are potentially objects--this lets us reject compiling functions that explicitly take e.g. `number` as a parameter.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Expect component props annotations to be potent…"}},{"before":"c3619477bf10dd10902fe725baf48bbf02547e8a","after":"2386f0978a718d4e0c470f5446d3564faeb97db5","ref":"refs/heads/gh/mvitousek/1/base","pushedAt":"2024-06-11T21:08:25.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"Update on \"[compiler] Expect components to have hook calls or jsx directly in body\"\n\n\nSummary: We can tighten our criteria for what is a component by requiring that a component or hook contain JSX or hook calls directly within its body, excluding nested functions . Currently, if we see them within the body anywhere -- including nested functions -- we treat it as a component if the other requirements are met. This change makes this stricter.\n\nWe also now expect components (but not necessarily hooks) to have return statements, and those returns must be potential React nodes (we can reject functions that return function or object literals, for example).\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Expect components to have hook calls or jsx dir…"}},{"before":"a5237cd86f994bc813470f0746265e68b447b0b5","after":"0024710e1aa96eca4ef5dac231915b64118b071b","ref":"refs/heads/gh/mvitousek/0/base","pushedAt":"2024-06-11T21:08:24.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"Update on \"[compiler] Option to only compile component syntax\"\n\n\nSummary: Projects which have heavily adopted Flow component syntax may wish to enable the compiler only for components and hooks that use the syntax, rather than trying to guess which functions are components and hooks. This provides that option.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Option to only compile component syntax\""}},{"before":"270229f0c337dc652f07ef27d2254bb922bfaa9e","after":"2c959f1d775e9c216d029d198971d06a1f8c892a","ref":"refs/heads/main","pushedAt":"2024-06-11T21:04:13.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"sebmarkbage","name":"Sebastian Markbåge","path":"/sebmarkbage","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/63648?s=80&v=4"},"commit":{"message":"[Fiber] Track debugInfo on module state instead of stack (#29807)\n\nStacked on #29804.\r\n\r\nTransferring of debugInfo was added in #28286. It represents the parent\r\nstack between the current Fiber and into the next Fiber we're about to\r\ncreate. I.e. Server Components in between. ~I don't love passing\r\nDEV-only fields as arguments anyway since I don't trust closure to\r\nremove unused arguments that way.~ EDIT: Actually it seems like closure\r\nhandled that just fine before which is why this is no change in prod.\r\n\r\nInstead, I track it on the module scope. Notably with DON'T use\r\ntry/finally because if something throws we want to observe what it was\r\nat the time we threw. Like the pattern we use many other places.\r\n\r\nNow we can use this when we create the Throw Fiber to associate the\r\nServer Components that were part of the parent stack before this error\r\nthrew. There by giving us the correct parent stacks at the location that\r\nthrew.","shortMessageHtmlLink":"[Fiber] Track debugInfo on module state instead of stack (#29807)"}},{"before":"84446a886568d73e44554a5bc001590b02f82520","after":"7200de2134e85d04ce07d569e29575090f7369d5","ref":"refs/heads/gh/josephsavona/28/orig","pushedAt":"2024-06-11T20:49:59.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"},"commit":{"message":"[compiler] Instruction reordering\n\nAdds a pass just after DCE to reorder safely reorderable instructions (jsx, primitives, globals) closer to where they are used, to allow other optimization passes to be more effective. Notably, the reordering allows scope merging to be more effective, since that pass relies on two scopes not having intervening instructions — in many cases we can now reorder such instructions out of the way and unlock merging, as demonstrated in the changed fixtures.\n\nThe algorithm itself is described in the docblock.\n\nnote: This is a cleaned up version of #29579 that is ready for review.\n\nghstack-source-id: fe01f94e186e62171e7cc82e10d7864c48f932be\nPull Request resolved: https://github.com/facebook/react/pull/29863","shortMessageHtmlLink":"[compiler] Instruction reordering"}},{"before":"2cb5cdd928025be5c299c91ca109054b218d5d13","after":"6b5cab78b4d6399634eb7fe4a6e3c12d9bd9705c","ref":"refs/heads/gh/josephsavona/28/head","pushedAt":"2024-06-11T20:49:57.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"},"commit":{"message":"Update on \"[compiler] Instruction reordering\"\n\n\nAdds a pass just after DCE to reorder safely reorderable instructions (jsx, primitives, globals) closer to where they are used, to allow other optimization passes to be more effective. Notably, the reordering allows scope merging to be more effective, since that pass relies on two scopes not having intervening instructions — in many cases we can now reorder such instructions out of the way and unlock merging, as demonstrated in the changed fixtures.\n\nThe algorithm itself is described in the docblock.\n\nnote: This is a cleaned up version of #29579 that is ready for review.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Instruction reordering\""}},{"before":"c67c5fab90fdf438996880d871b5ef987184b202","after":"27175f261d26c762ac865c034ad192a1681b0c8e","ref":"refs/heads/gh/mvitousek/0/orig","pushedAt":"2024-06-11T20:42:39.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"[compiler] Option to only compile component syntax\n\nSummary: Projects which have heavily adopted Flow component syntax may wish to enable the compiler only for components and hooks that use the syntax, rather than trying to guess which functions are components and hooks. This provides that option.\n\nghstack-source-id: 579ac9f0fa01d8cdb6a0b8f9923906a0b37662f3\nPull Request resolved: https://github.com/facebook/react/pull/29864","shortMessageHtmlLink":"[compiler] Option to only compile component syntax"}},{"before":"e8d211060117fcee6bc1c0a9deb2794476b02445","after":"3b9f33aa9be7ce1c22d1a8d22d0f88c774ba1bbf","ref":"refs/heads/gh/mvitousek/1/orig","pushedAt":"2024-06-11T20:42:39.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"[compiler] Expect components to have hook calls or jsx directly in body\n\nSummary: We can tighten our criteria for what is a component by requiring that a component or hook contain JSX or hook calls directly within its body, excluding nested functions . Currently, if we see them within the body anywhere -- including nested functions -- we treat it as a component if the other requirements are met. This change makes this stricter.\n\nWe also now expect components (but not necessarily hooks) to have return statements, and those returns must be potential React nodes (we can reject functions that return function or object literals, for example).\n\nghstack-source-id: 4507cc3955216c564bf257c0b81bfb551ae6ae55\nPull Request resolved: https://github.com/facebook/react/pull/29865","shortMessageHtmlLink":"[compiler] Expect components to have hook calls or jsx directly in body"}},{"before":"fa9d6f79da6d251b4fb6cb6b6ea98f03f23bcd07","after":"57550bbb7add096fb6289d789c763c72e795bd31","ref":"refs/heads/gh/mvitousek/2/orig","pushedAt":"2024-06-11T20:42:39.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"[compiler] Expect component props annotations to be potential objects\n\nSummary: We now expect that candidate components that have Flow or TS type annotations on their first parameters have annotations that are potentially objects--this lets us reject compiling functions that explicitly take e.g. `number` as a parameter.\n\nghstack-source-id: e2c23348265b7ef651232b962ed7be7f6fed1930\nPull Request resolved: https://github.com/facebook/react/pull/29866","shortMessageHtmlLink":"[compiler] Expect component props annotations to be potential objects"}},{"before":"12998f4a41c03b47a6ef6a7aac040e91e42eb40c","after":"0024710e1aa96eca4ef5dac231915b64118b071b","ref":"refs/heads/gh/mvitousek/0/head","pushedAt":"2024-06-11T20:42:37.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"Update on \"[compiler] Option to only compile component syntax\"\n\n\nSummary: Projects which have heavily adopted Flow component syntax may wish to enable the compiler only for components and hooks that use the syntax, rather than trying to guess which functions are components and hooks. This provides that option.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Option to only compile component syntax\""}},{"before":"95ade6ae07787532e3ef6913e9e701cbe505796e","after":"2386f0978a718d4e0c470f5446d3564faeb97db5","ref":"refs/heads/gh/mvitousek/1/head","pushedAt":"2024-06-11T20:42:37.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"Update on \"[compiler] Expect components to have hook calls or jsx directly in body\"\n\n\nSummary: We can tighten our criteria for what is a component by requiring that a component or hook contain JSX or hook calls directly within its body, excluding nested functions . Currently, if we see them within the body anywhere -- including nested functions -- we treat it as a component if the other requirements are met. This change makes this stricter.\n\nWe also now expect components (but not necessarily hooks) to have return statements, and those returns must be potential React nodes (we can reject functions that return function or object literals, for example).\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Expect components to have hook calls or jsx dir…"}},{"before":"df726bfee1789eaa9eb08edb0fc84ebf0f97d77b","after":"2cd012258311f12aaed643d1a78941b1dd449b79","ref":"refs/heads/gh/mvitousek/2/head","pushedAt":"2024-06-11T20:42:37.000Z","pushType":"push","commitsCount":5,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"Update on \"[compiler] Expect component props annotations to be potential objects\"\n\n\nSummary: We now expect that candidate components that have Flow or TS type annotations on their first parameters have annotations that are potentially objects--this lets us reject compiling functions that explicitly take e.g. `number` as a parameter.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Expect component props annotations to be potent…"}},{"before":"0c65538be85d7e0f55e683512849486114ae56d9","after":"a5237cd86f994bc813470f0746265e68b447b0b5","ref":"refs/heads/gh/mvitousek/0/base","pushedAt":"2024-06-11T20:42:36.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"Update base for Update on \"[compiler] Option to only compile component syntax\"\n\n\nSummary: Projects which have heavily adopted Flow component syntax may wish to enable the compiler only for components and hooks that use the syntax, rather than trying to guess which functions are components and hooks. This provides that option.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update base for Update on \"[compiler] Option to only compile componen…"}},{"before":"e772267aa1cb87cee3e98928d7008182a75e5e83","after":"badbfbc9c8ae905e4e1848bb3259528f88e732d8","ref":"refs/heads/gh/mvitousek/2/base","pushedAt":"2024-06-11T20:42:36.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"Update base for Update on \"[compiler] Expect component props annotations to be potential objects\"\n\n\nSummary: We now expect that candidate components that have Flow or TS type annotations on their first parameters have annotations that are potentially objects--this lets us reject compiling functions that explicitly take e.g. `number` as a parameter.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update base for Update on \"[compiler] Expect component props annotati…"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEYrtbhQA","startCursor":null,"endCursor":null}},"title":"Activity · facebook/react"}