{"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:1717011078.0","currentOid":""},"activityList":{"items":[{"before":"ae612e646174bb3242f8fb7c4c416d1876d0108c","after":"a889374b0f9d87e84c8f8161dcce09c70de45044","ref":"refs/heads/builds/facebook-fbsource","pushedAt":"2024-05-30T14:31:21.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":"Revert Build Versions from Content Hash to Commit Hash (#29663)\n\nhttps://github.com/facebook/react/pull/29236 caused issues for internal\nsyncs at Meta, because we were computing version numbers using file\nhashes (to eliminate \"no-op\" internal sync commits). The problem is that\nsince version numbers may not be consistent across synced files (e.g. if\nsome files have not changed in recent commits), the newly introduced\nversion mismatch check fails.\n\nThere's some more work that needs to be done here to restore the\nbenefits of file-specific hashing, but for now this simply reverts the\ncontent hash changes from the following PRs:\n\n- https://github.com/facebook/react/pull/28633\n(95319ab5afd384f5858f7c080573b9736e6b2f9c)\n- https://github.com/facebook/react/pull/28590\n(37676aba76a9b97e1059e6dec39c3f401f44248d)\n- https://github.com/facebook/react/pull/28582\n(cb076b593cec3a92338958f58468cce19cb8f0d9)\n- https://github.com/facebook/react/pull/26734\n(5dd90c562354758942c833b0a46923176e92208e)\n- https://github.com/facebook/react/pull/26331\n(3cad3a54eda7b2d1c670c2d414f33d78a4c3f6af)\n\nDiffTrain build for commit https://github.com/facebook/react/commit/5bd403122645ef0f0924ac5466f56e670a8f5b8d.","shortMessageHtmlLink":"Revert Build Versions from Content Hash to Commit Hash (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2324714132\" data-permission-text=\"Title is private\" data-url=\"https://github.com/facebook/react/issues/29663\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/facebook/react/pull/29663/hovercard\" href=\"https://github.com/facebook/react/pull/29663\">#29663</a>)"}},{"before":"4bebe8e2068e3b5071dead2f688786030e145e80","after":"0727c8aaf4a6e44b04525e2f62038c2dabd9bebc","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-05-30T14:31:15.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":"Revert Build Versions from Content Hash to Commit Hash (#29663)\n\nhttps://github.com/facebook/react/pull/29236 caused issues for internal\nsyncs at Meta, because we were computing version numbers using file\nhashes (to eliminate \"no-op\" internal sync commits). The problem is that\nsince version numbers may not be consistent across synced files (e.g. if\nsome files have not changed in recent commits), the newly introduced\nversion mismatch check fails.\n\nThere's some more work that needs to be done here to restore the\nbenefits of file-specific hashing, but for now this simply reverts the\ncontent hash changes from the following PRs:\n\n- https://github.com/facebook/react/pull/28633\n(95319ab5afd384f5858f7c080573b9736e6b2f9c)\n- https://github.com/facebook/react/pull/28590\n(37676aba76a9b97e1059e6dec39c3f401f44248d)\n- https://github.com/facebook/react/pull/28582\n(cb076b593cec3a92338958f58468cce19cb8f0d9)\n- https://github.com/facebook/react/pull/26734\n(5dd90c562354758942c833b0a46923176e92208e)\n- https://github.com/facebook/react/pull/26331\n(3cad3a54eda7b2d1c670c2d414f33d78a4c3f6af)\n\nDiffTrain build for [5bd403122645ef0f0924ac5466f56e670a8f5b8d](https://github.com/facebook/react/commit/5bd403122645ef0f0924ac5466f56e670a8f5b8d)","shortMessageHtmlLink":"Revert Build Versions from Content Hash to Commit Hash (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2324714132\" data-permission-text=\"Title is private\" data-url=\"https://github.com/facebook/react/issues/29663\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/facebook/react/pull/29663/hovercard\" href=\"https://github.com/facebook/react/pull/29663\">#29663</a>)"}},{"before":"431d10b3b01e90c74628f6599a74030cd0c1a685","after":"4bebe8e2068e3b5071dead2f688786030e145e80","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-05-30T14:30:35.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":"Fix `key` Warning for Flattened Positional Children (#29662)\n\n## Summary\n\nhttps://github.com/facebook/react/pull/29088 introduced a regression\ntriggering this warning when rendering flattened positional children:\n\n> Each child in a list should have a unique \"key\" prop.\n\nThe specific scenario that triggers this is when rendering multiple\npositional children (which do not require unique `key` props) after\nflattening them with one of the `React.Children` utilities (e.g.\n`React.Children.toArray`).\n\nThe refactored logic in `React.Children` incorrectly drops the\n`element._store.validated` property in `__DEV__`. This diff fixes the\nbug and introduces a unit test to prevent future regressions.\n\n## How did you test this change?\n\n```\n$ yarn test ReactChildren-test.js\n```\n\nDiffTrain build for [72644ef2f2ec7a274f79f6b32320d62757521329](https://github.com/facebook/react/commit/72644ef2f2ec7a274f79f6b32320d62757521329)","shortMessageHtmlLink":"Fix <code>key</code> Warning for Flattened Positional Children (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2324664954\" data-permission-text=\"Title is private\" data-url=\"https://github.com/facebook/react/issues/29662\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/facebook/react/pull/29662/hovercard\" href=\"https://github.com/facebook/react/pull/29662\">#29662</a>)"}},{"before":"b0cfb9c9c348cca1bfea2d2001d2ba1217f93d62","after":"ae612e646174bb3242f8fb7c4c416d1876d0108c","ref":"refs/heads/builds/facebook-fbsource","pushedAt":"2024-05-30T14:30:31.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":"Fix `key` Warning for Flattened Positional Children (#29662)\n\n## Summary\n\nhttps://github.com/facebook/react/pull/29088 introduced a regression\ntriggering this warning when rendering flattened positional children:\n\n> Each child in a list should have a unique \"key\" prop.\n\nThe specific scenario that triggers this is when rendering multiple\npositional children (which do not require unique `key` props) after\nflattening them with one of the `React.Children` utilities (e.g.\n`React.Children.toArray`).\n\nThe refactored logic in `React.Children` incorrectly drops the\n`element._store.validated` property in `__DEV__`. This diff fixes the\nbug and introduces a unit test to prevent future regressions.\n\n## How did you test this change?\n\n```\n$ yarn test ReactChildren-test.js\n```\n\nDiffTrain build for commit https://github.com/facebook/react/commit/72644ef2f2ec7a274f79f6b32320d62757521329.","shortMessageHtmlLink":"Fix <code>key</code> Warning for Flattened Positional Children (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2324664954\" data-permission-text=\"Title is private\" data-url=\"https://github.com/facebook/react/issues/29662\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/facebook/react/pull/29662/hovercard\" href=\"https://github.com/facebook/react/pull/29662\">#29662</a>)"}},{"before":"72644ef2f2ec7a274f79f6b32320d62757521329","after":"5bd403122645ef0f0924ac5466f56e670a8f5b8d","ref":"refs/heads/main","pushedAt":"2024-05-30T14:26:12.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"yungsters","name":"Timothy Yung","path":"/yungsters","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/55161?s=80&v=4"},"commit":{"message":"Revert Build Versions from Content Hash to Commit Hash (#29663)\n\nhttps://github.com/facebook/react/pull/29236 caused issues for internal\r\nsyncs at Meta, because we were computing version numbers using file\r\nhashes (to eliminate \"no-op\" internal sync commits). The problem is that\r\nsince version numbers may not be consistent across synced files (e.g. if\r\nsome files have not changed in recent commits), the newly introduced\r\nversion mismatch check fails.\r\n\r\nThere's some more work that needs to be done here to restore the\r\nbenefits of file-specific hashing, but for now this simply reverts the\r\ncontent hash changes from the following PRs:\r\n\r\n- https://github.com/facebook/react/pull/28633\r\n(95319ab5afd384f5858f7c080573b9736e6b2f9c)\r\n- https://github.com/facebook/react/pull/28590\r\n(37676aba76a9b97e1059e6dec39c3f401f44248d)\r\n- https://github.com/facebook/react/pull/28582\r\n(cb076b593cec3a92338958f58468cce19cb8f0d9)\r\n- https://github.com/facebook/react/pull/26734\r\n(5dd90c562354758942c833b0a46923176e92208e)\r\n- https://github.com/facebook/react/pull/26331\r\n(3cad3a54eda7b2d1c670c2d414f33d78a4c3f6af)","shortMessageHtmlLink":"Revert Build Versions from Content Hash to Commit Hash (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2324714132\" data-permission-text=\"Title is private\" data-url=\"https://github.com/facebook/react/issues/29663\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/facebook/react/pull/29663/hovercard\" href=\"https://github.com/facebook/react/pull/29663\">#29663</a>)"}},{"before":"51dd09631ac0c7824fec55f38462846b6fe41d06","after":"72644ef2f2ec7a274f79f6b32320d62757521329","ref":"refs/heads/main","pushedAt":"2024-05-30T14:25:48.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"yungsters","name":"Timothy Yung","path":"/yungsters","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/55161?s=80&v=4"},"commit":{"message":"Fix `key` Warning for Flattened Positional Children (#29662)\n\n## Summary\r\n\r\nhttps://github.com/facebook/react/pull/29088 introduced a regression\r\ntriggering this warning when rendering flattened positional children:\r\n\r\n> Each child in a list should have a unique \"key\" prop.\r\n\r\nThe specific scenario that triggers this is when rendering multiple\r\npositional children (which do not require unique `key` props) after\r\nflattening them with one of the `React.Children` utilities (e.g.\r\n`React.Children.toArray`).\r\n\r\nThe refactored logic in `React.Children` incorrectly drops the\r\n`element._store.validated` property in `__DEV__`. This diff fixes the\r\nbug and introduces a unit test to prevent future regressions.\r\n\r\n## How did you test this change?\r\n\r\n```\r\n$ yarn test ReactChildren-test.js\r\n```","shortMessageHtmlLink":"Fix <code>key</code> Warning for Flattened Positional Children (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2324664954\" data-permission-text=\"Title is private\" data-url=\"https://github.com/facebook/react/issues/29662\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/facebook/react/pull/29662/hovercard\" href=\"https://github.com/facebook/react/pull/29662\">#29662</a>)"}},{"before":"3546ca6adbe38a5634762775c2288b33f8144ce6","after":"b0cfb9c9c348cca1bfea2d2001d2ba1217f93d62","ref":"refs/heads/builds/facebook-fbsource","pushedAt":"2024-05-30T09:31:09.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":"Add tests for ReactNativeAttributePayloadFabric.js (#29608)\n\n## Summary\n\nThis PR add tests for `ReactNativeAttributePayloadFabric.js`.\n\nIt introduces `ReactNativeAttributePayloadFabric-test.internal.js`,\nwhich is a copy-paste of `ReactNativeAttributePayload-test.internal.js`.\n\nOn top of that, there is a bunch of new test cases for the\n`ReactNativeAttributePayloadFabric.create` function.\n\n## How did you test this change?\n\n```\nyarn test packages/react-native-renderer\n```\n\nDiffTrain build for commit https://github.com/facebook/react/commit/51dd09631ac0c7824fec55f38462846b6fe41d06.","shortMessageHtmlLink":"Add tests for ReactNativeAttributePayloadFabric.js (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2321085067\" data-permission-text=\"Title is private\" data-url=\"https://github.com/facebook/react/issues/29608\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/facebook/react/pull/29608/hovercard\" href=\"https://github.com/facebook/react/pull/29608\">#29608</a>)"}},{"before":"c2b45ef0dd06a67365444cdef904701a863e5051","after":"51dd09631ac0c7824fec55f38462846b6fe41d06","ref":"refs/heads/main","pushedAt":"2024-05-30T09:24:00.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"dmytrorykun","name":"Dmytro Rykun","path":"/dmytrorykun","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/14206200?s=80&v=4"},"commit":{"message":"Add tests for ReactNativeAttributePayloadFabric.js (#29608)\n\n## Summary\r\n\r\nThis PR add tests for `ReactNativeAttributePayloadFabric.js`.\r\n\r\nIt introduces `ReactNativeAttributePayloadFabric-test.internal.js`,\r\nwhich is a copy-paste of `ReactNativeAttributePayload-test.internal.js`.\r\n\r\nOn top of that, there is a bunch of new test cases for the\r\n`ReactNativeAttributePayloadFabric.create` function.\r\n\r\n## How did you test this change?\r\n\r\n```\r\nyarn test packages/react-native-renderer\r\n```","shortMessageHtmlLink":"Add tests for ReactNativeAttributePayloadFabric.js (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2321085067\" data-permission-text=\"Title is private\" data-url=\"https://github.com/facebook/react/issues/29608\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/facebook/react/pull/29608/hovercard\" href=\"https://github.com/facebook/react/pull/29608\">#29608</a>)"}},{"before":"1b068ce2b945321a06ade5fc878935013e821542","after":"0bbf03d7b2e7faaeb093291afb49664f12689825","ref":"refs/heads/gh/mvitousek/0/orig","pushedAt":"2024-05-30T00:02:06.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] Prune dependencies that are only used by useRef or useState\n\nSummary: jmbrown215 recently had an observation that the arguments to useState/useRef are only used when a component renders for the first time, and never afterwards. We can skip more computation that we previously could, with reactive blocks that previously recomputed values when inputs changed now only ever computing them on the first render.\n\nghstack-source-id: 037ea97ea87d382c58da23e162218128ca6d2b0c\nPull Request resolved: https://github.com/facebook/react/pull/29653","shortMessageHtmlLink":"[compiler] Prune dependencies that are only used by useRef or useState"}},{"before":"a58fb9ed798ec8b7d23d539df851081c60eae544","after":"412e212119ec8742716ded3f0d71293cc78fe52c","ref":"refs/heads/gh/mvitousek/4/orig","pushedAt":"2024-05-30T00:02:06.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] Recompute values every time\n\nSummary: This PR expands the analysis from the previous in the stack in order to also capture when a value can incorrectly change within a single render, rather than just changing between two renders. In the case where dependencies have changed and so a new value is being computed, we now compute the value twice and compare the results. This would, for example, catch when we call Math.random() in render.\n\nThe generated code is a little convoluted, because we don't want to have to traverse the generated code and substitute variable names with new ones. Instead, we save the initial value to the cache as normal, then run the computation block again and compare the resulting values to the cached ones. Then, to make sure that the cached values are identical to the computed ones, we reassign the cached values into the output variables.\n\nghstack-source-id: ddf516cba5d72b4841a27d3559c2b02058b3dc7c\nPull Request resolved: https://github.com/facebook/react/pull/29657","shortMessageHtmlLink":"[compiler] Recompute values every time"}},{"before":"653e723830c0052705f1a36fe8cc5c18107672aa","after":"4b31bf2265c067aeb85df1f42a14e53a2bdedc07","ref":"refs/heads/gh/mvitousek/5/orig","pushedAt":"2024-05-30T00:02:06.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] rfc: Include location information in identifiers and reactive scopes for debugging\n\nSummary: Using the change detection code to debug codebases that violate the rules of react is a lot easier when we have a source location corresponding to the value that has changed inappropriately. I didn't see an easy way to track that information in the existing data structures at the point of codegen, so this PR adds locations to identifiers and reactive scopes (the location of a reactive scope is the range of the locations of its included identifiers).\n\nI'm interested if there's a better way to do this that I missed!\n\nghstack-source-id: 99e6cfed43cdcb1ca13653c5ed1c0c3028b7e5a3\nPull Request resolved: https://github.com/facebook/react/pull/29658","shortMessageHtmlLink":"[compiler] rfc: Include location information in identifiers and react…"}},{"before":"b1be4a328cb9b42b65ee108fa4d09862628cba35","after":"636a0ab1c0155c0e73066625b8f69444752273d2","ref":"refs/heads/gh/mvitousek/2/orig","pushedAt":"2024-05-30T00:02:06.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 always take the non-memo branch\n\nSummary: This adds a debugging mode to the compiler that simply adds a `|| true` to the guard on all memoization blocks, which results in the generated code never using memoized values and always recomputing them. This is designed as a validation tool for the compiler's correctness--every program *should* behave exactly the same with this option enabled as it would with it disabled, and so any difference in behavior should be investigated as either a compiler bug or a pipeline issue.\n\n(We add `|| true` rather than dropping the conditional block entirely because we still want to exercise the guard tests, in case the guards themselves are the source of an error, like reading a property from undefined in a guard.)\n\nghstack-source-id: b00db6e0021fd59bfabd5431e3b79abd9d9fe1cd\nPull Request resolved: https://github.com/facebook/react/pull/29655","shortMessageHtmlLink":"[compiler] Option to always take the non-memo branch"}},{"before":"e428e1325cb4d6cbd2f7c083abf17614f1583089","after":"6b93fee0d228e3a10f6227c80b640693459f7e36","ref":"refs/heads/gh/mvitousek/1/orig","pushedAt":"2024-05-30T00:02:06.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 for preserving calls to useMemo/useCallback\n\nSummary: This adds a compiler option to not drop existing manual memoization and leaving useMemo/useCallback in the generated source. Why do we need this, given that we also have options to validate or ensure that existing memoization is preserved? It's because later diffs on this stack are designed to alter the behavior of the memoization that the compiler emits, in order to detect rules of react violations and debug issues. We don't want to change the behavior of user-level memoization, however, since doing so would be altering the semantics of the user's program in an unacceptable way.\n\nghstack-source-id: 998706fd7ba62bc7df5abf7912da0df1f4ec2501\nPull Request resolved: https://github.com/facebook/react/pull/29654","shortMessageHtmlLink":"[compiler] Option for preserving calls to useMemo/useCallback"}},{"before":"3a43799060ff3eb233ffe015b775e700b094487a","after":"ccd1bcd37bf8861fe5ffddb9522ea4ffeb677f10","ref":"refs/heads/gh/mvitousek/3/orig","pushedAt":"2024-05-30T00:02:06.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] Debug tool to emit change detection code rather than memoization\n\nSummary: The essential assumption of the compiler is that if the inputs to a computation have not changed, then the output should not change either--computation that the compiler optimizes is idempotent.\n\nThis is, of course, known to be false in practice, because this property rests on requirements (the Rules of React) that are loosely enforced at best. When rolling out the compiler to a codebase that might have rules of react violations, how should developers debug any issues that arise?\n\nThis diff attempts one approach to that: when the option is set, rather than simply skipping computation when dependencies haven't changed, we will *still perform the computation*, but will then use a runtime function to compare the original value and the resultant value. The runtime function can be customized, but the idea is that it will perform a structural equality check on the values, and if the values aren't structurally equal, we can report an error, including information about what file and what variable was to blame.\n\nThis assists in debugging by narrowing down what specific computation is responsible for a difference in behavior between the uncompiled code and the program after compilation.\n\nghstack-source-id: 45c18c96c8fef781c82ea31b71684b3f8e07e0d6\nPull Request resolved: https://github.com/facebook/react/pull/29656","shortMessageHtmlLink":"[compiler] Debug tool to emit change detection code rather than memoi…"}},{"before":"8c824c0b066f24ac5b5588dfe0718e53a7e83705","after":"00ec583d96fc895297722d972f53fff8292229aa","ref":"refs/heads/gh/mvitousek/5/head","pushedAt":"2024-05-30T00:02:03.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"Update on \"[compiler] rfc: Include location information in identifiers and reactive scopes for debugging\"\n\n\nSummary: Using the change detection code to debug codebases that violate the rules of react is a lot easier when we have a source location corresponding to the value that has changed inappropriately. I didn't see an easy way to track that information in the existing data structures at the point of codegen, so this PR adds locations to identifiers and reactive scopes (the location of a reactive scope is the range of the locations of its included identifiers).\n\nI'm interested if there's a better way to do this that I missed!\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] rfc: Include location information in identifier…"}},{"before":"2a30856ab3be8104cfe0f9ac2e300397de0ef35a","after":"2264f179d36c8c1fa1ee3234cb32c4cb1ba650ea","ref":"refs/heads/gh/mvitousek/3/head","pushedAt":"2024-05-30T00:02:03.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"Update on \"[compiler] Debug tool to emit change detection code rather than memoization\"\n\n\nSummary: The essential assumption of the compiler is that if the inputs to a computation have not changed, then the output should not change either--computation that the compiler optimizes is idempotent.\n\nThis is, of course, known to be false in practice, because this property rests on requirements (the Rules of React) that are loosely enforced at best. When rolling out the compiler to a codebase that might have rules of react violations, how should developers debug any issues that arise?\n\nThis diff attempts one approach to that: when the option is set, rather than simply skipping computation when dependencies haven't changed, we will *still perform the computation*, but will then use a runtime function to compare the original value and the resultant value. The runtime function can be customized, but the idea is that it will perform a structural equality check on the values, and if the values aren't structurally equal, we can report an error, including information about what file and what variable was to blame.\n\nThis assists in debugging by narrowing down what specific computation is responsible for a difference in behavior between the uncompiled code and the program after compilation.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Debug tool to emit change detection code rather…"}},{"before":"ca18e1de111cd09cfbea0d5cb7fedff20592f3e3","after":"48d900f3807f65e85ad73caacc10deff209a9b22","ref":"refs/heads/gh/mvitousek/2/head","pushedAt":"2024-05-30T00:02:03.000Z","pushType":"push","commitsCount":2,"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 always take the non-memo branch\"\n\n\nSummary: This adds a debugging mode to the compiler that simply adds a `|| true` to the guard on all memoization blocks, which results in the generated code never using memoized values and always recomputing them. This is designed as a validation tool for the compiler's correctness--every program *should* behave exactly the same with this option enabled as it would with it disabled, and so any difference in behavior should be investigated as either a compiler bug or a pipeline issue.\n\n(We add `|| true` rather than dropping the conditional block entirely because we still want to exercise the guard tests, in case the guards themselves are the source of an error, like reading a property from undefined in a guard.)\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Option to always take the non-memo branch\""}},{"before":"fde49869b6b1c099ab2251f7a4af8d2c4b6edbe5","after":"a54d96c9a506ad88d3185753a9684c7ba978d09a","ref":"refs/heads/gh/mvitousek/1/head","pushedAt":"2024-05-30T00:02:03.000Z","pushType":"push","commitsCount":2,"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 for preserving calls to useMemo/useCallback\"\n\n\nSummary: This adds a compiler option to not drop existing manual memoization and leaving useMemo/useCallback in the generated source. Why do we need this, given that we also have options to validate or ensure that existing memoization is preserved? It's because later diffs on this stack are designed to alter the behavior of the memoization that the compiler emits, in order to detect rules of react violations and debug issues. We don't want to change the behavior of user-level memoization, however, since doing so would be altering the semantics of the user's program in an unacceptable way.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Option for preserving calls to useMemo/useCallb…"}},{"before":"484930e69400305e9c3fabfbca3abf9d5487c793","after":"b9436d8466bf621e18dc635ea3c77e71221483fc","ref":"refs/heads/gh/mvitousek/4/head","pushedAt":"2024-05-30T00:02:03.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"Update on \"[compiler] Recompute values every time\"\n\n\nSummary: This PR expands the analysis from the previous in the stack in order to also capture when a value can incorrectly change within a single render, rather than just changing between two renders. In the case where dependencies have changed and so a new value is being computed, we now compute the value twice and compare the results. This would, for example, catch when we call Math.random() in render.\n\nThe generated code is a little convoluted, because we don't want to have to traverse the generated code and substitute variable names with new ones. Instead, we save the initial value to the cache as normal, then run the computation block again and compare the resulting values to the cached ones. Then, to make sure that the cached values are identical to the computed ones, we reassign the cached values into the output variables.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Recompute values every time\""}},{"before":"9e4b4a5db9a1db387dfa79c277c9d71a9c6d71a1","after":"e296fda158d7f22b813137e2eb25b77077f8567e","ref":"refs/heads/gh/mvitousek/0/head","pushedAt":"2024-05-30T00:02:03.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"mvitousek","name":"Michael Vitousek","path":"/mvitousek","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1629813?s=80&v=4"},"commit":{"message":"Update on \"[compiler] Prune dependencies that are only used by useRef or useState\"\n\n\nSummary: jmbrown215 recently had an observation that the arguments to useState/useRef are only used when a component renders for the first time, and never afterwards. We can skip more computation that we previously could, with reactive blocks that previously recomputed values when inputs changed now only ever computing them on the first render.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Prune dependencies that are only used by useRef…"}},{"before":"ca18e1de111cd09cfbea0d5cb7fedff20592f3e3","after":"1d1693f7c68c63f5b01115404221450d850d4e13","ref":"refs/heads/gh/mvitousek/3/base","pushedAt":"2024-05-30T00:02:01.000Z","pushType":"push","commitsCount":1,"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] Debug tool to emit change detection code rather than memoization\"\n\n\nSummary: The essential assumption of the compiler is that if the inputs to a computation have not changed, then the output should not change either--computation that the compiler optimizes is idempotent.\n\nThis is, of course, known to be false in practice, because this property rests on requirements (the Rules of React) that are loosely enforced at best. When rolling out the compiler to a codebase that might have rules of react violations, how should developers debug any issues that arise?\n\nThis diff attempts one approach to that: when the option is set, rather than simply skipping computation when dependencies haven't changed, we will *still perform the computation*, but will then use a runtime function to compare the original value and the resultant value. The runtime function can be customized, but the idea is that it will perform a structural equality check on the values, and if the values aren't structurally equal, we can report an error, including information about what file and what variable was to blame.\n\nThis assists in debugging by narrowing down what specific computation is responsible for a difference in behavior between the uncompiled code and the program after compilation.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update base for Update on \"[compiler] Debug tool to emit change detec…"}},{"before":"2a30856ab3be8104cfe0f9ac2e300397de0ef35a","after":"70893bac15095aa6029cf433899e6789e6d0eb5d","ref":"refs/heads/gh/mvitousek/4/base","pushedAt":"2024-05-30T00:02:01.000Z","pushType":"push","commitsCount":1,"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] Recompute values every time\"\n\n\nSummary: This PR expands the analysis from the previous in the stack in order to also capture when a value can incorrectly change within a single render, rather than just changing between two renders. In the case where dependencies have changed and so a new value is being computed, we now compute the value twice and compare the results. This would, for example, catch when we call Math.random() in render.\n\nThe generated code is a little convoluted, because we don't want to have to traverse the generated code and substitute variable names with new ones. Instead, we save the initial value to the cache as normal, then run the computation block again and compare the resulting values to the cached ones. Then, to make sure that the cached values are identical to the computed ones, we reassign the cached values into the output variables.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update base for Update on \"[compiler] Recompute values every time\""}},{"before":"484930e69400305e9c3fabfbca3abf9d5487c793","after":"a2965638b017ec1217d696c37f526ca8c5a9c79d","ref":"refs/heads/gh/mvitousek/5/base","pushedAt":"2024-05-30T00:02:01.000Z","pushType":"push","commitsCount":1,"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] rfc: Include location information in identifiers and reactive scopes for debugging\"\n\n\nSummary: Using the change detection code to debug codebases that violate the rules of react is a lot easier when we have a source location corresponding to the value that has changed inappropriately. I didn't see an easy way to track that information in the existing data structures at the point of codegen, so this PR adds locations to identifiers and reactive scopes (the location of a reactive scope is the range of the locations of its included identifiers).\n\nI'm interested if there's a better way to do this that I missed!\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update base for Update on \"[compiler] rfc: Include location informati…"}},{"before":"9e4b4a5db9a1db387dfa79c277c9d71a9c6d71a1","after":"acbcb537830a5edcdb447b44770668b43b55c807","ref":"refs/heads/gh/mvitousek/1/base","pushedAt":"2024-05-30T00:02:01.000Z","pushType":"push","commitsCount":1,"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 for preserving calls to useMemo/useCallback\"\n\n\nSummary: This adds a compiler option to not drop existing manual memoization and leaving useMemo/useCallback in the generated source. Why do we need this, given that we also have options to validate or ensure that existing memoization is preserved? It's because later diffs on this stack are designed to alter the behavior of the memoization that the compiler emits, in order to detect rules of react violations and debug issues. We don't want to change the behavior of user-level memoization, however, since doing so would be altering the semantics of the user's program in an unacceptable way.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update base for Update on \"[compiler] Option for preserving calls to …"}},{"before":"fde49869b6b1c099ab2251f7a4af8d2c4b6edbe5","after":"f04a86aba3135e278593474e7988978523d450b2","ref":"refs/heads/gh/mvitousek/2/base","pushedAt":"2024-05-30T00:02:01.000Z","pushType":"push","commitsCount":1,"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 always take the non-memo branch\"\n\n\nSummary: This adds a debugging mode to the compiler that simply adds a `|| true` to the guard on all memoization blocks, which results in the generated code never using memoized values and always recomputing them. This is designed as a validation tool for the compiler's correctness--every program *should* behave exactly the same with this option enabled as it would with it disabled, and so any difference in behavior should be investigated as either a compiler bug or a pipeline issue.\n\n(We add `|| true` rather than dropping the conditional block entirely because we still want to exercise the guard tests, in case the guards themselves are the source of an error, like reading a property from undefined in a guard.)\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update base for Update on \"[compiler] Option to always take the non-m…"}},{"before":"c8c0495dce0b44c07ce276e2c37b0f5bea33a8df","after":"df7f36f22ced4c53f3d47537455e2d24e36bd9bb","ref":"refs/heads/gh/josephsavona/15/orig","pushedAt":"2024-05-29T23:51:38.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: super early exploration of instruction reordering\n\nSee comments in InstructionReordering.ts. This needs substantial iteration before landing in some form, just putting up to share for discussion.\n\nghstack-source-id: 153eca4485d6f19e71423547af806f7b4aca8bc7\nPull Request resolved: https://github.com/facebook/react/pull/29579","shortMessageHtmlLink":"compiler: super early exploration of instruction reordering"}},{"before":"1425c6d3166fcd6a20b3015381b2ba86309f820e","after":"97bd37418e911db69bcd789ffb798a3600af6684","ref":"refs/heads/gh/josephsavona/15/head","pushedAt":"2024-05-29T23:51:36.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"},"commit":{"message":"Update on \"compiler: super early exploration of instruction reordering\"\n\n\nSee comments in InstructionReordering.ts. This needs substantial iteration before landing in some form, just putting up to share for discussion.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"compiler: super early exploration of instruction reordering\""}},{"before":"d26994cfecdbbaa3ddc0a10afe7edab1f51ae422","after":"4d75ae1b746862711d73e1777060c24a77c5fa2b","ref":"refs/heads/gh/josephsavona/15/base","pushedAt":"2024-05-29T23:51:34.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 base for Update on \"compiler: super early exploration of instruction reordering\"\n\n\nSee comments in InstructionReordering.ts. This needs substantial iteration before landing in some form, just putting up to share for discussion.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update base for Update on \"compiler: super early exploration of instr…"}},{"before":"53723ca633e8bc4060b32af28dc37617d5335b77","after":"c8c0495dce0b44c07ce276e2c37b0f5bea33a8df","ref":"refs/heads/gh/josephsavona/15/orig","pushedAt":"2024-05-29T23:26:39.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: super early exploration of instruction reordering\n\nSee comments in InstructionReordering.ts. This needs substantial iteration before landing in some form, just putting up to share for discussion.\n\nghstack-source-id: 765c47c3d6ce37af06de307b71af5a8c2f4a8fa5\nPull Request resolved: https://github.com/facebook/react/pull/29579","shortMessageHtmlLink":"compiler: super early exploration of instruction reordering"}},{"before":"713c7626380d9d532c13ed3225a87b64a2fabcf1","after":"1425c6d3166fcd6a20b3015381b2ba86309f820e","ref":"refs/heads/gh/josephsavona/15/head","pushedAt":"2024-05-29T23:26:37.000Z","pushType":"push","commitsCount":28,"pusher":{"login":"josephsavona","name":"Joseph Savona","path":"/josephsavona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/6425824?s=80&v=4"},"commit":{"message":"Update on \"compiler: super early exploration of instruction reordering\"\n\n\nSee comments in InstructionReordering.ts. This needs substantial iteration before landing in some form, just putting up to share for discussion.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"compiler: super early exploration of instruction reordering\""}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEWB1nGgA","startCursor":null,"endCursor":null}},"title":"Activity · facebook/react"}