{"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:1719906107.0","currentOid":""},"activityList":{"items":[{"before":"0b5835a46f6e19a0a0ead0f4cd30b0db14bc72f7","after":"f38c22b244086f62ae5ed851b6ed17029ec44be5","ref":"refs/heads/main","pushedAt":"2024-07-04T16:31:23.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] Set Current Owner / Task When Calling console.error or invoking onError/onPostpone (#30206)\n\nStacked on #30197.\r\n\r\nThis is similar to #30182 and #21610 in Fizz.\r\n\r\nTrack the current owner/stack/task on the task. This tracks it for\r\nattribution when serializing child properties.\r\n\r\nThis lets us provide the right owner and createTask when we\r\nconsole.error from inside Flight itself. This also affects the way we\r\nprint those logs on the client since we need the owner and stack. Now\r\nconsole.errors that originate on the server gets the right stack on the\r\nclient:\r\n\r\n![\"Screenshot]()
\r\n\r\nUnfortunately, because we don't track the stack we never pop it so it'll\r\nkeep tracking for serializing sibling properties. We rely on \"children\"\r\ntypically being the last property in the common case anyway. However,\r\nthis can lead to wrong attribution in some cases where the invalid\r\nproperty is a next property (without a wrapping element) and there's a\r\nprevious element that doesn't. E.g. `}\r\ninvalid={nonSerializable} />` would use the div as the attribution\r\ninstead of ClientComponent.\r\n\r\nI also wrap all of our own console.error, onError and onPostpone in the\r\ncontext of the parent component. It's annoying to have to remember to do\r\nthis though.\r\n\r\nWe could always wrap the whole rendering in such as context but it would\r\nadd more overhead since this rarely actually happens. It might make\r\nsense to track the whole current task instead to lower the overhead.\r\nThat's what we do in Fizz. We'd still have to remember to restore the\r\ndebug task though. I realize now Fizz doesn't do that neither so the\r\ndebug task isn't wrapping the console.errors that Fizz itself logs.\r\nThere's something off about that Flight and Fizz implementations don't\r\nperfectly align.","shortMessageHtmlLink":"[Flight] Set Current Owner / Task When Calling console.error or invok…"}},{"before":"8e9de898d3a8a0945fcdc1a02959560bce2bbc30","after":"0b5835a46f6e19a0a0ead0f4cd30b0db14bc72f7","ref":"refs/heads/main","pushedAt":"2024-07-04T16:15:51.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] Implement captureStackTrace and owner stacks on the Server (#30197)\n\nWire up owner stacks in Flight to the shared internals. This exposes it\r\nto `captureOwnerStack()`.\r\n\r\nIn this case we install it permanently as we only allow one RSC renderer\r\nwhich then supports async contexts. Same thing we do for owner.\r\n\r\nThis also ends up adding it to errors logged by React through\r\n`consoleWithStackDev`. The plan is to eventually remove that but this is\r\ninline with what we do in Fizz and Fiber already.\r\n\r\nHowever, at the same time we've instrumented the console so we need to\r\nstrip them back out before sending to the client. This lets the client\r\ncontrol whether to add the stack back in or allowing\r\n`console.createTask` to control it.\r\n\r\nThis is another reason we shouldn't append them from React but for now\r\nwe hack it by removing them after the fact.","shortMessageHtmlLink":"[Flight] Implement captureStackTrace and owner stacks on the Server (#…"}},{"before":"3da26163a35969b32b5d7876a3f0c95bea61bc2b","after":"8e9de898d3a8a0945fcdc1a02959560bce2bbc30","ref":"refs/heads/main","pushedAt":"2024-07-04T16:15:35.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] Add option to replay console logs or not (#30207)\n\nDefaults to true in browser builds, otherwise defaults to false. The\r\nassumption is that the server logs will already contain a log from the\r\noriginal Flight server.\r\n\r\nWe currently always replay console logs but this leads to duplicates on\r\nthe server by default when you use SSR, because the Flight Client on the\r\nserver replays the logs. This can be nice since those logs gets badged.\r\nIt can also be nice if they're running in separate servers but when\r\nthey're logging to the same stream it's annoying. Which is really the\r\ntypical set up so we should just make that the default but leave it\r\nconfigurable.","shortMessageHtmlLink":"[Flight] Add option to replay console logs or not (#30207)"}},{"before":"15ca8b6bad9c2e51f1a3b6e943c9af494b62a1a6","after":"3da26163a35969b32b5d7876a3f0c95bea61bc2b","ref":"refs/heads/main","pushedAt":"2024-07-04T14:34:48.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"hoxyq","name":"Ruslan Lesiutin","path":"/hoxyq","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/28902667?s=80&v=4"},"commit":{"message":"fix: path handling in react devtools (#29199)\n\n\r\n\r\n## Summary\r\n\r\nFix how devtools handles URLs. It\r\n\r\n- cannot handle relative source map URLs `//# sourceMappingURL=x.map`\r\n- cannot recognize Windows style URLs\r\n\r\n## How did you test this change?\r\n\r\nworks on my side","shortMessageHtmlLink":"fix: path handling in react devtools (#29199)"}},{"before":"6e169fc65da097629588132f8fec82d8a836afdd","after":"15ca8b6bad9c2e51f1a3b6e943c9af494b62a1a6","ref":"refs/heads/main","pushedAt":"2024-07-03T20:57:05.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":"Don't strip out component stack in assertConsole helpers (#30204)\n\nUse the same normalizeCodeLocInfo that we use everywhere else.\r\n\r\nWe should actually test the component stack itself. Not just that it\r\nexists. This was causing false passes.\r\n\r\nHowever, the logic was also wrong before because it wouldn't always\r\nstrip out the last line so wouldn't accurately normalize it. Leading to\r\nfalse failures as well.","shortMessageHtmlLink":"Don't strip out component stack in assertConsole helpers (#30204)"}},{"before":"9c6806964f453cb5e8a530881dcc9f33480e7388","after":"6e169fc65da097629588132f8fec82d8a836afdd","ref":"refs/heads/main","pushedAt":"2024-07-03T17:25:04.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] Allow String Chunks to Passthrough in Node streams and renderToMarkup (#30131)\n\nIt can be efficient to accept raw string chunks to pass through a stream\r\ninstead of encoding them into a binary copy first.\r\n\r\nPreviously our Flight parsers didn't accept receiving string chunks.\r\nThat's partly because we sometimes need to encode binary chunks anyway\r\nso string only transport isn't enough but some chunks can be strings.\r\nThis adds a partial ability for chunks to be received as strings.\r\n\r\nHowever, accepting strings comes with some downsides. E.g. if the\r\nstrings are split up we need to buffer it which compromises the perf for\r\nthe common case. If the chunk represents binary data, then we'd need to\r\nencode it back into a typed array which would require a TextEncoder\r\ndependency in the parser. If the string chunk represents a byte length\r\nencoded string we don't know how many unicode characters to read without\r\nmeasuring them in terms of binary - also requiring a TextEncoder.\r\n\r\nThis PR is mainly intended for use for pass-through within the same\r\nmemory. We can simplify the implementation by assuming that any string\r\nchunk is passed as the original chunk. This requires that the server\r\nstream config doesn't arbitrarily concatenate strings (e.g. large\r\nstrings should not be concatenated which is probably a good heuristic\r\nanyway). It also means that this is not suitable to be used with for\r\nexample receiving string chunks on the client by passing them through\r\nSSR hydration data - except if the encoding that way was only used with\r\nchunks that were already encoded as strings by Flight.\r\n\r\nWeb streams mostly just work on binary data anyway so they can't use\r\nthis.\r\n\r\nIn Node.js streams we concatenate precomputed and small strings into\r\nlarger buffers. It might make sense to do that using string ropes\r\ninstead. However, in the meantime we can at least pass large strings\r\nthat are outside our buffer view size as raw strings. There's no benefit\r\nto us eagerly encoding those.\r\n\r\nAlso, let Node accept string chunks as long as they're following our\r\nexpected constraints. This lets us test the mixed protocol using\r\npass-throughs. This can also be useful when the RSC server is in the\r\nsame environment as the SSR server as they don't have to go from strings\r\nto typed arrays back to strings.\r\n\r\nNow we can also use this in the pass-through used in renderToMarkup.\r\nThis lets us avoid the dependency on TextDecoder/TextEncoder in that\r\npackage.","shortMessageHtmlLink":"[Flight] Allow String Chunks to Passthrough in Node streams and rende…"}},{"before":"572ded3762fa7332e2d062e4373369cd7008b7b0","after":"9c6806964f453cb5e8a530881dcc9f33480e7388","ref":"refs/heads/main","pushedAt":"2024-07-03T11:10:23.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":"Add regression test for #30172 (#30198)\n\nThe issue reported in #30172 was fixed with #29823. The PR also added\r\nthe test [`should resolve deduped objects that are themselves\r\nblocked`](https://github.com/facebook/react/blob/6d2a97a7113dfac2ad45067001b7e49a98718324/packages/react-server-dom-webpack/src/__tests__/ReactFlightDOMBrowser-test.js#L348-L393),\r\nwhich tests a similar scenario. However, the existing test would have\r\nalso succeeded before applying the changes from #29823. Therefore, I\r\nbelieve it makes sense to add an additional test `should resolve deduped\r\nobjects in nested children of blocked models`, which does not succeed\r\nwithout #29823, to prevent regressions.","shortMessageHtmlLink":"Add regression test for #30172 (#30198)"}},{"before":"3db98c917701d59f62cf1fbe45cbf01b0b61c704","after":"572ded3762fa7332e2d062e4373369cd7008b7b0","ref":"refs/heads/main","pushedAt":"2024-07-03T10:46:46.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"hoxyq","name":"Ruslan Lesiutin","path":"/hoxyq","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/28902667?s=80&v=4"},"commit":{"message":"React DevTools 5.3.0 -> 5.3.1 (#30199)\n\n## Summary\r\n\r\nFull list of changes, mostly fixes:\r\n* chore[react-devtools/renderer]: dont show strict mode warning for prod\r\nrenderer builds ([hoxyq](https://github.com/hoxyq) in\r\n[#30158](https://github.com/facebook/react/pull/30158))\r\n* chore[react-devtools/ui]: fix strict mode badge styles\r\n([hoxyq](https://github.com/hoxyq) in\r\n[#30159](https://github.com/facebook/react/pull/30159))\r\n* fix[react-devtools]: restore original args when recording errors\r\n([hoxyq](https://github.com/hoxyq) in\r\n[#30091](https://github.com/facebook/react/pull/30091))\r\n* Read constructor name more carefully\r\n([LoganDark](https://github.com/LoganDark) in\r\n[#29954](https://github.com/facebook/react/pull/29954))\r\n* refactor[react-devtools/extensions]: dont debounce cleanup logic on\r\nnavigation ([hoxyq](https://github.com/hoxyq) in\r\n[#30027](https://github.com/facebook/react/pull/30027))\r\n* lint: enable reportUnusedDisableDirectives and remove unused\r\nsuppressions ([kassens](https://github.com/kassens) in\r\n[#28721](https://github.com/facebook/react/pull/28721))\r\n* fix[react-devtools/extensions]: propagate globals from env\r\n([hoxyq](https://github.com/hoxyq) in\r\n[#29963](https://github.com/facebook/react/pull/29963))\r\n* refactor[react-devtools/tests]: use registered marks instead of\r\ncleared in tests ([hoxyq](https://github.com/hoxyq) in\r\n[#29929](https://github.com/facebook/react/pull/29929))","shortMessageHtmlLink":"React DevTools 5.3.0 -> 5.3.1 (#30199)"}},{"before":"a3323b760a1ec91594fa3dbcf3a0c75e4cf295fc","after":"07d044a91e5a1ddb1511cec605c1e9e6942f1166","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-07-02T23:52:04.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":"[Fizz] Track Current debugTask and run it for onError Callbacks (#30182)\n\nStacked on #30174.\n\nThis tracks the current debugTask on the Task so that when an error is\nthrown we can use it to run the `onError` (and `onShellError` and\n`onFatalError`) callbacks within the Context of that task. Ideally it\nwould be associated with the error object but neither console.error [nor\nreportError](https://crbug.com/350426235) reports this as the async\nstack so we have to manually restore it.\n\nThat way when you inspect Fizz using node `--inspect` we show the right\nasync stack.\n\n![\"Screenshot]()
\n\nThis is equivalent to how we track the task that created the parent\nserver component or the Fiber:\n\nhttps://github.com/facebook/react/blob/6d2a97a7113dfac2ad45067001b7e49a98718324/packages/react-reconciler/src/ReactChildFiber.js#L1985\n\nThen use them when invoking the error callbacks:\n\nhttps://github.com/facebook/react/blob/6d2a97a7113dfac2ad45067001b7e49a98718324/packages/react-reconciler/src/ReactFiberThrow.js#L104-L108\n\n---------\n\nCo-authored-by: Sebastian Silbermann \n\nDiffTrain build for [3db98c917701d59f62cf1fbe45cbf01b0b61c704](https://github.com/facebook/react/commit/3db98c917701d59f62cf1fbe45cbf01b0b61c704)","shortMessageHtmlLink":"[Fizz] Track Current debugTask and run it for onError Callbacks (#30182)"}},{"before":"cfb8945f511add040e1d5427d9961337f98f7618","after":"3db98c917701d59f62cf1fbe45cbf01b0b61c704","ref":"refs/heads/main","pushedAt":"2024-07-02T23:46:18.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":"[Fizz] Track Current debugTask and run it for onError Callbacks (#30182)\n\nStacked on #30174.\r\n\r\nThis tracks the current debugTask on the Task so that when an error is\r\nthrown we can use it to run the `onError` (and `onShellError` and\r\n`onFatalError`) callbacks within the Context of that task. Ideally it\r\nwould be associated with the error object but neither console.error [nor\r\nreportError](https://crbug.com/350426235) reports this as the async\r\nstack so we have to manually restore it.\r\n\r\nThat way when you inspect Fizz using node `--inspect` we show the right\r\nasync stack.\r\n\r\n![\"Screenshot]()
\r\n\r\nThis is equivalent to how we track the task that created the parent\r\nserver component or the Fiber:\r\n\r\n\r\nhttps://github.com/facebook/react/blob/6d2a97a7113dfac2ad45067001b7e49a98718324/packages/react-reconciler/src/ReactChildFiber.js#L1985\r\n\r\nThen use them when invoking the error callbacks:\r\n\r\n\r\nhttps://github.com/facebook/react/blob/6d2a97a7113dfac2ad45067001b7e49a98718324/packages/react-reconciler/src/ReactFiberThrow.js#L104-L108\r\n\r\n---------\r\n\r\nCo-authored-by: Sebastian Silbermann ","shortMessageHtmlLink":"[Fizz] Track Current debugTask and run it for onError Callbacks (#30182)"}},{"before":"3ae0357e67864d21e1f38d5834803f30e21cb034","after":"a3323b760a1ec91594fa3dbcf3a0c75e4cf295fc","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-07-02T22:32:33.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":"[Fizz] Implement debugInfo (#30174)\n\nStacked on #30170.\n\nThis lets us track Server Component parent stacks in Fizz which also\nlets us track the correct owner stack for lazy.\n\nIn Fiber we're careful not to make any DEV only fibers but since the\nReactFizzComponentStack data structures just exist for debug meta data\nanyway we can just expand on that.\n\nDiffTrain build for [cfb8945f511add040e1d5427d9961337f98f7618](https://github.com/facebook/react/commit/cfb8945f511add040e1d5427d9961337f98f7618)","shortMessageHtmlLink":"[Fizz] Implement debugInfo (#30174)"}},{"before":"309e146193c7b84d1c7a60d1a2ab2d6c836ba515","after":"cfb8945f511add040e1d5427d9961337f98f7618","ref":"refs/heads/main","pushedAt":"2024-07-02T22:26:32.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":"[Fizz] Implement debugInfo (#30174)\n\nStacked on #30170.\r\n\r\nThis lets us track Server Component parent stacks in Fizz which also\r\nlets us track the correct owner stack for lazy.\r\n\r\nIn Fiber we're careful not to make any DEV only fibers but since the\r\nReactFizzComponentStack data structures just exist for debug meta data\r\nanyway we can just expand on that.","shortMessageHtmlLink":"[Fizz] Implement debugInfo (#30174)"}},{"before":"e60063d9e7d346e92a5af42975a2fe7dd306f86f","after":"309e146193c7b84d1c7a60d1a2ab2d6c836ba515","ref":"refs/heads/main","pushedAt":"2024-07-02T20:31:35.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":"Implement onError signature for renderToMarkup (#30170)\n\nStacked on #30132.\r\n\r\nThis way we can get parent and owner stacks from the error.\r\n\r\nThis forces us to confront multiple errors and whether or not a Flight\r\nerror that ends up being unobservable needs to really reject the render.\r\n\r\nThis implements stashing of Flight errors with a digest and only errors\r\nif they end up erroring the Fizz render too. At this point they'll have\r\nparent stacks so we can surface those.","shortMessageHtmlLink":"Implement onError signature for renderToMarkup (#30170)"}},{"before":"f6969ad5905283ac86fa0bbc162a04d547849c25","after":"3ae0357e67864d21e1f38d5834803f30e21cb034","ref":"refs/heads/builds/facebook-www","pushedAt":"2024-07-02T20:11:24.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":"[Fizz] Include a component stack in prod but only lazily generate it (#30132)\n\nWhen we added component stacks to Fizz in prod it severely slowed down\ncommon cases where you intentionally are throwing error for purposes of\nclient rendering. Our parent component stack generation is very slow\nsince call components with fake errors to generate them.\n\nTherefore we disabled them in prod but included them in prerenders.\nhttps://github.com/facebook/react/pull/27850\n\nHowever, we still kept generating data structures for them and the code\nstill exists there for the prerenders. We could stop generating the data\nstructures which are not completely free but also not crazy bad.\n\nWhat we can do instead is just lazily generate the component stacks.\nThis is in fact what plain stacks do anyway. This doesn't work as well\nin Fiber because the data structures are live but on the server they're\nimmutable so it's fine to do it later as well.\n\nThat way you can choose to not read this getter for intentionally thrown\nerrors - after inspecting the Error object - yet still get component\nstacks in prod for other errors.\n\nDiffTrain build for [e60063d9e7d346e92a5af42975a2fe7dd306f86f](https://github.com/facebook/react/commit/e60063d9e7d346e92a5af42975a2fe7dd306f86f)","shortMessageHtmlLink":"[Fizz] Include a component stack in prod but only lazily generate it (#…"}},{"before":"6d2a97a7113dfac2ad45067001b7e49a98718324","after":"e60063d9e7d346e92a5af42975a2fe7dd306f86f","ref":"refs/heads/main","pushedAt":"2024-07-02T20:05:20.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":"[Fizz] Include a component stack in prod but only lazily generate it (#30132)\n\nWhen we added component stacks to Fizz in prod it severely slowed down\r\ncommon cases where you intentionally are throwing error for purposes of\r\nclient rendering. Our parent component stack generation is very slow\r\nsince call components with fake errors to generate them.\r\n\r\nTherefore we disabled them in prod but included them in prerenders.\r\nhttps://github.com/facebook/react/pull/27850\r\n\r\nHowever, we still kept generating data structures for them and the code\r\nstill exists there for the prerenders. We could stop generating the data\r\nstructures which are not completely free but also not crazy bad.\r\n\r\nWhat we can do instead is just lazily generate the component stacks.\r\nThis is in fact what plain stacks do anyway. This doesn't work as well\r\nin Fiber because the data structures are live but on the server they're\r\nimmutable so it's fine to do it later as well.\r\n\r\nThat way you can choose to not read this getter for intentionally thrown\r\nerrors - after inspecting the Error object - yet still get component\r\nstacks in prod for other errors.","shortMessageHtmlLink":"[Fizz] Include a component stack in prod but only lazily generate it (#…"}},{"before":"13b70d6c862f0dfc12aa00dc4b3da05726a12442","after":"317ce9a1667719dfbd3dbfde705f13765a4a8291","ref":"refs/heads/gh/mvitousek/12/orig","pushedAt":"2024-07-02T16:59:58.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] Add wrapper functions to wrap change-detection storage and loading from the memo cache\n\nSummary: We may wish to perform some additional computation on values when they enter or exit the memo cache in change detection mode (e.g. make a deep copy, restore the original value). This builds support for doing so.\n\nIn addition, it drops the \"ForDebugging\" part of the flag name and makes it compatible with \"disableMemoization\": if memoization is disabled, we implement that by not restoring the old version of the value unless we're in a source-level memo block.\n\nghstack-source-id: d59253d0d994ca7856f2ba0df73315cff91f3931\nPull Request resolved: https://github.com/facebook/react/pull/30181","shortMessageHtmlLink":"[compiler] Add wrapper functions to wrap change-detection storage and…"}},{"before":"5b8cff58653c0c0ff117e3b555fb26384d00fdc1","after":"4510d2917a14d2139cc73eff326bae390ef0253f","ref":"refs/heads/gh/mvitousek/11/orig","pushedAt":"2024-07-02T16:59:58.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] Fewer assumptions about nonmutability when change detection enabled\n\nSummary: Change detection is desgined to determine whether rules of react have been violated, and to do so better we need to loosen Forgets assumptions about what kinds of values don't need to be memoized. For example, the compiler typically doesn't think of `o.x` as something that needs to be memoized, because it does not allocate. However, we want to compare `o.x` in the current render with `o.x` in a previous one, so we now insert a \"memoization\" (comparison, really) block around this value.\n\nghstack-source-id: 413d866dde590938f041e3c6c7a9e44aada3433b\nPull Request resolved: https://github.com/facebook/react/pull/30180","shortMessageHtmlLink":"[compiler] Fewer assumptions about nonmutability when change detectio…"}},{"before":"fb56ca52b634650094eb65e667bd255c7f0308eb","after":"693b8d83ca99a6b952525e9afcb3c9777a053d6a","ref":"refs/heads/gh/mvitousek/8/orig","pushedAt":"2024-07-02T16:59:58.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] useMemo calls directly induce memoization blocks\n\nSummary: To support the always-bailing-out and change-detection modes for the compiler, and to potentially support end-user codebases in some situations, we previously built a mode where user-level useMemos weren't dropped. This, however, results in codegen that is quite vastly different from the compiler's default mode, and which is likely to exercise different bugs.\n\nThis diff introduces a new mode that attempts to preserve user-level memoization in a way that is more compatible with the normal output of the compiler, dropping the literal useMemo calls and producing reactive scopes. The result of this is different from the existing ensurePreserveMemoizationGuarantees in that the reactive scope is marked as originating from a useMemo, and cannot be merged with other memoization blocks, and that some operations are memoized that are not necessarily memoized today: specifically, `obj.x` and `f()`. This is to account for the fact that current useMemo calls may call non-idempotent functions inside useMemo--this is a violation of React's rules and is unsupported, but this mode attempts to support this behavior to make the compiler's behavior as close to user-level behavior as possible.\n\nWe build the user-level reactive scopes by simply adding all memoizable instructions between `StartMemo` and `FinishMemo` to their own reactive scope, possibly overwriting an existing scope. We do so before the scopes have been populated with dependencies or outputs so those passes can operate over these new scopes as normal.\n\nghstack-source-id: 298a3583e64f9a101c4e4e8291226381311c69fd\nPull Request resolved: https://github.com/facebook/react/pull/30177","shortMessageHtmlLink":"[compiler] useMemo calls directly induce memoization blocks"}},{"before":"55fe4bced8896b7f46515a617a3952823ab35323","after":"72e62706eebbf195d460f0ad91196064ecd80916","ref":"refs/heads/gh/mvitousek/13/orig","pushedAt":"2024-07-02T16:59:58.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][ez] Rename disableMemoizationForDebugging to just disableMemoization\n\nSummary: We don't really need to make positive claims about what a particular mode is for in the name\n\nghstack-source-id: e1e161a227ea65faf1a5ed075d7459f128190679\nPull Request resolved: https://github.com/facebook/react/pull/30191","shortMessageHtmlLink":"[compiler][ez] Rename disableMemoizationForDebugging to just disableM…"}},{"before":"55604e1678e1590d0c8af8c082bb89a929cefd22","after":"9679f7f264ecf41d5f756d5c5c05de749e7853c4","ref":"refs/heads/gh/mvitousek/9/orig","pushedAt":"2024-07-02T16:59:58.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] Drop useMemos in memoization disabled mode, don't bail from source-level memo blocks\n\nSummary: When testing Forget with the always-bail-out mode, we now preserve useMemos as reactive scope rather than hook calls, and we don't short-circuit those scopes.\n\nghstack-source-id: 01725b7ba8d937a52f2c4e5a622d79f2c1126672\nPull Request resolved: https://github.com/facebook/react/pull/30178","shortMessageHtmlLink":"[compiler] Drop useMemos in memoization disabled mode, don't bail fro…"}},{"before":"e6df63c6e89e333cdac3aa53a37009c26783a1fd","after":"fd5dd5233b617783b12c9f99d787a0dd860dd3c5","ref":"refs/heads/gh/mvitousek/10/orig","pushedAt":"2024-07-02T16:59:58.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] Use dependencies from source for useMemo scopes\n\nSummary: This modified the behavior of the compiler when preserving source-level useMemos as reactive scopes to use the depencies from the source as well. This accounts for the possibility that the useMemo in the source is more general than is required by local code, but is necessary due to rules of react violations.\n\nWith this change, ideally the disableMemoization mode will behave exactly like the uncompiled code.\n\nghstack-source-id: 910828cc2b1b86ed1a3971b94f611ebf244b5ce4\nPull Request resolved: https://github.com/facebook/react/pull/30179","shortMessageHtmlLink":"[compiler] Use dependencies from source for useMemo scopes"}},{"before":"f1d0f71c0aa990931d439b46507c1f6109d81f3f","after":"adc8705646409281d3f99d247ac95d4762a0c7b4","ref":"refs/heads/gh/mvitousek/8/head","pushedAt":"2024-07-02T16:59:56.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] useMemo calls directly induce memoization blocks\"\n\n\nSummary: To support the always-bailing-out and change-detection modes for the compiler, and to potentially support end-user codebases in some situations, we previously built a mode where user-level useMemos weren't dropped. This, however, results in codegen that is quite vastly different from the compiler's default mode, and which is likely to exercise different bugs.\n\nThis diff introduces a new mode that attempts to preserve user-level memoization in a way that is more compatible with the normal output of the compiler, dropping the literal useMemo calls and producing reactive scopes. The result of this is different from the existing ensurePreserveMemoizationGuarantees in that the reactive scope is marked as originating from a useMemo, and cannot be merged with other memoization blocks, and that some operations are memoized that are not necessarily memoized today: specifically, `obj.x` and `f()`. This is to account for the fact that current useMemo calls may call non-idempotent functions inside useMemo--this is a violation of React's rules and is unsupported, but this mode attempts to support this behavior to make the compiler's behavior as close to user-level behavior as possible.\n\nWe build the user-level reactive scopes by simply adding all memoizable instructions between `StartMemo` and `FinishMemo` to their own reactive scope, possibly overwriting an existing scope. We do so before the scopes have been populated with dependencies or outputs so those passes can operate over these new scopes as normal.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] useMemo calls directly induce memoization blocks\""}},{"before":"0edfcd61f9f2c392a4be390d715f8cc7b0cf45d4","after":"e1aa6b7e3f4db768eef7d1d1c9bb5039c415b0ca","ref":"refs/heads/gh/mvitousek/11/head","pushedAt":"2024-07-02T16:59:56.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] Fewer assumptions about nonmutability when change detection enabled\"\n\n\nSummary: Change detection is desgined to determine whether rules of react have been violated, and to do so better we need to loosen Forgets assumptions about what kinds of values don't need to be memoized. For example, the compiler typically doesn't think of `o.x` as something that needs to be memoized, because it does not allocate. However, we want to compare `o.x` in the current render with `o.x` in a previous one, so we now insert a \"memoization\" (comparison, really) block around this value.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Fewer assumptions about nonmutability when chan…"}},{"before":"1ed7cb0750624831d03a0ef8fc64e33b8ce3f14f","after":"ea23260617bd6faf75d44ed455f0a8ce97dc5c77","ref":"refs/heads/gh/mvitousek/13/head","pushedAt":"2024-07-02T16:59:56.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][ez] Rename disableMemoizationForDebugging to just disableMemoization\"\n\n\nSummary: We don't really need to make positive claims about what a particular mode is for in the name\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler][ez] Rename disableMemoizationForDebugging to ju…"}},{"before":"d20c36323149986ea97a6d98ef85b1217f7fd5ca","after":"ed6e6de97499f48e935eef34db79b669a3f6363c","ref":"refs/heads/gh/mvitousek/12/head","pushedAt":"2024-07-02T16:59:56.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] Add wrapper functions to wrap change-detection storage and loading from the memo cache\"\n\n\nSummary: We may wish to perform some additional computation on values when they enter or exit the memo cache in change detection mode (e.g. make a deep copy, restore the original value). This builds support for doing so.\n\nIn addition, it drops the \"ForDebugging\" part of the flag name and makes it compatible with \"disableMemoization\": if memoization is disabled, we implement that by not restoring the old version of the value unless we're in a source-level memo block.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Add wrapper functions to wrap change-detection …"}},{"before":"5ceb503c5ab75d06983961af97c45fb97ab85528","after":"f8d54ce372501a04bd923a5203d5a852e5cd95c7","ref":"refs/heads/gh/mvitousek/9/head","pushedAt":"2024-07-02T16:59:56.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] Drop useMemos in memoization disabled mode, don't bail from source-level memo blocks\"\n\n\nSummary: When testing Forget with the always-bail-out mode, we now preserve useMemos as reactive scope rather than hook calls, and we don't short-circuit those scopes.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Drop useMemos in memoization disabled mode, don…"}},{"before":"9e179f1bc6fbbdd0f0d14100d4db47730de7ec41","after":"f9dc5a1c9691016ec4962573090f05a603d5d1d1","ref":"refs/heads/gh/mvitousek/10/head","pushedAt":"2024-07-02T16:59:56.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] Use dependencies from source for useMemo scopes\"\n\n\r\nSummary: This modified the behavior of the compiler when preserving source-level useMemos as reactive scopes to use the depencies from the source as well. This accounts for the possibility that the useMemo in the source is more general than is required by local code, but is necessary due to rules of react violations.\r\n\r\nThe most complex bit here has to do with explicit dependencies that are globals. As currently written, there's no LoadGlobal that corresponds to a Global dependency of a useMemo, so whenever we convert a useMemo into StartMemoize/FinishMemoize instructions, if we plan to use the useMemo's dependencies we also have to synthesize a LoadGlobal instruction for any globals in the dependencies. \r\n\r\nWith this change, ideally the disableMemoization mode will behave exactly like the uncompiled code.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update on \"[compiler] Use dependencies from source for useMemo scopes\""}},{"before":"9ff96ed94465b7275647f18221171c6670a22e29","after":"50339296159466ef4f63d53688f385a02728264d","ref":"refs/heads/gh/mvitousek/10/base","pushedAt":"2024-07-02T16:59:53.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] Use dependencies from source for useMemo scopes\"\n\n\r\nSummary: This modified the behavior of the compiler when preserving source-level useMemos as reactive scopes to use the depencies from the source as well. This accounts for the possibility that the useMemo in the source is more general than is required by local code, but is necessary due to rules of react violations.\r\n\r\nThe most complex bit here has to do with explicit dependencies that are globals. As currently written, there's no LoadGlobal that corresponds to a Global dependency of a useMemo, so whenever we convert a useMemo into StartMemoize/FinishMemoize instructions, if we plan to use the useMemo's dependencies we also have to synthesize a LoadGlobal instruction for any globals in the dependencies. \r\n\r\nWith this change, ideally the disableMemoization mode will behave exactly like the uncompiled code.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update base for Update on \"[compiler] Use dependencies from source fo…"}},{"before":"37866ac62774835da252c305c719686b1c36798d","after":"7802f7a44ff341b706ce1c777f5ae2f91147a05a","ref":"refs/heads/gh/mvitousek/12/base","pushedAt":"2024-07-02T16:59:53.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] Add wrapper functions to wrap change-detection storage and loading from the memo cache\"\n\n\nSummary: We may wish to perform some additional computation on values when they enter or exit the memo cache in change detection mode (e.g. make a deep copy, restore the original value). This builds support for doing so.\n\nIn addition, it drops the \"ForDebugging\" part of the flag name and makes it compatible with \"disableMemoization\": if memoization is disabled, we implement that by not restoring the old version of the value unless we're in a source-level memo block.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update base for Update on \"[compiler] Add wrapper functions to wrap c…"}},{"before":"893bf83e51a19849024ee3e81ed416501d7540a0","after":"848adecc152e0a9887bbf4c60b77b5509fb38e52","ref":"refs/heads/gh/mvitousek/11/base","pushedAt":"2024-07-02T16:59:53.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] Fewer assumptions about nonmutability when change detection enabled\"\n\n\nSummary: Change detection is desgined to determine whether rules of react have been violated, and to do so better we need to loosen Forgets assumptions about what kinds of values don't need to be memoized. For example, the compiler typically doesn't think of `o.x` as something that needs to be memoized, because it does not allocate. However, we want to compare `o.x` in the current render with `o.x` in a previous one, so we now insert a \"memoization\" (comparison, really) block around this value.\n\n[ghstack-poisoned]","shortMessageHtmlLink":"Update base for Update on \"[compiler] Fewer assumptions about nonmuta…"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEdxvgTwA","startCursor":null,"endCursor":null}},"title":"Activity · facebook/react"}