{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":45281256,"defaultBranch":"master","name":"react","ownerLogin":"acdlite","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2015-10-30T23:18:48.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/3624098?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1716483294.0","currentOid":""},"activityList":{"items":[{"before":"8ad45be66f92ff53b67a5dc55a228ec99472de4e","after":"e8b016ccc6da25787f3821c463644301412d0f97","ref":"refs/heads/throw-if-react-version-mismatch","pushedAt":"2024-05-24T16:08:45.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Detect react-native-renderer mismatch, too","shortMessageHtmlLink":"Detect react-native-renderer mismatch, too"}},{"before":"d7c40cac5427c66d72635763b65f205333350d78","after":"8ad45be66f92ff53b67a5dc55a228ec99472de4e","ref":"refs/heads/throw-if-react-version-mismatch","pushedAt":"2024-05-23T23:48:46.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Throw if React and React DOM versions don't match\n\nThrow an error during module initialization if the version of the\n\"react-dom\" package does not match the version of \"react\".\n\nWe used to be more relaxed about this, because the \"react\" package\nchanged so infrequently. However, we now have many more features that\nrely on an internal protocol between the two packages, including Hooks,\nFloat, and the compiler runtime. So it's important that both packages\nare versioned in lockstep.\n\nBefore this change, a version mismatch would often result in a cryptic\ninternal error with no indication of the root cause.\n\nInstead, we will now compare the versions during module initialization\nand immediately throw an error to catch mistakes as early as possible\nand provide a clear error message.","shortMessageHtmlLink":"Throw if React and React DOM versions don't match"}},{"before":"afb7de33119276cf2c2877375d1d7df44d319f41","after":"d7c40cac5427c66d72635763b65f205333350d78","ref":"refs/heads/throw-if-react-version-mismatch","pushedAt":"2024-05-23T21:25:20.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Throw if React and React DOM versions don't match\n\nThrow an error during module initialization if the version of the\n\"react-dom\" package does not match the version of \"react\".\n\nWe used to be more relaxed about this, because the \"react\" package\nchanged so infrequently. However, we now have many more features that\nrely on an internal protocol between the two packages, including Hooks,\nFloat, and the compiler runtime. So it's important that both packages\nare versioned in lockstep.\n\nBefore this change, a version mismatch would often result in a cryptic\ninternal error with no indication of the root cause.\n\nInstead, we will now compare the versions during module initialization\nand immediately throw an error to catch mistakes as early as possible\nand provide a clear error message.","shortMessageHtmlLink":"Throw if React and React DOM versions don't match"}},{"before":null,"after":"afb7de33119276cf2c2877375d1d7df44d319f41","ref":"refs/heads/throw-if-react-version-mismatch","pushedAt":"2024-05-23T16:54:54.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Throw if React and React DOM versions don't match\n\nThrow an error during module initialization if the version of the\n\"react-dom\" package does not match the version of \"react\".\n\nWe used to be more relaxed about this, because the \"react\" package\nchanged so infrequently. However, we now have many more features that\nrely on an internal protocol between the two packages, including Hooks,\nFloat, and the compiler runtime. So it's important that both packages\nare versioned in lockstep.\n\nBefore this change, a version mismatch would often result in a cryptic\ninternal error with no indication of the root cause.\n\nInstead, we will now compare the versions during module initialization\nand immediately throw an error to catch mistakes as early as possible\nand provide a clear error message.","shortMessageHtmlLink":"Throw if React and React DOM versions don't match"}},{"before":"56f70178910cc9bfc03dd82b3ae19771789a1cc7","after":"12a387d95e81a9507ade8fb796ded27615188c2f","ref":"refs/heads/fix-async-batching-starttransition","pushedAt":"2024-05-23T03:36:33.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Fix async batching in React.startTransition\n\nDiscovered a flaw in the current implementation of the isomorphic\nstartTransition implementation (React.startTransition), related to async\nactions. It only creates an async scope if something calls setState\nwithin the synchronous part of the action (i.e. before the first\n`await`). I had thought this was fine because if there's no update\nduring this part, then there's nothing that needs to be entangled. I\ndidn't think this through, though — if there are multiple async updates\ninterleaved throughout the rest of the action, we need the async scope\nto have already been created so that _those_ are batched together.\n\nAn even easier way to observe this is to schedule an optimistic update\nafter an `await` — the optimistic update should not be reverted until\nthe async action is complete.\n\nTo implement, during the reconciler's module initialization, we compose\nits startTransition implementation with any previous reconciler's\nstartTransition that was already initialized. Then, the isomorphic\nstartTransition is the composition of every\nreconciler's startTransition.\n\nfunction startTransition() {\n  startTransitionDOM(() => {\n    startTransitionART(() => {\n      startTransitionThreeFiber(() => {\n        // and so on...\n      });\n    });\n  });\n});\n\nThis is basically how flushSync is implemented, too.","shortMessageHtmlLink":"Fix async batching in React.startTransition"}},{"before":"69d94fcb37dd5eba70235d24da6d2af2176aff3f","after":"56f70178910cc9bfc03dd82b3ae19771789a1cc7","ref":"refs/heads/fix-async-batching-starttransition","pushedAt":"2024-05-23T03:04:51.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Fix async batching in React.startTransition\n\nDiscovered a flaw in the current implementation of the isomorphic\nstartTransition implementation (React.startTransition), related to async\nactions. It only creates an async scope if something calls setState\nwithin the synchronous part of the action (i.e. before the first\n`await`). I had thought this was fine because if there's no update\nduring this part, then there's nothing that needs to be entangled. I\ndidn't think this through, though — if there are multiple async updates\ninterleaved throughout the rest of the action, we need the async scope\nto have already been created so that _those_ are batched together.\n\nAn even more easier way to observe this is to schedule an optimistic\nupdate after an `await` — the optimistic update should not be reverted\nuntil the async action is complete.\n\nTo implement, during the reconciler's module initialization, we compose\nits startTransition implementation with any previous reconciler's\nstartTransition that was already initialized. Then, the isomorphic\nstartTransition is the composition of every\nreconciler's startTransition.\n\nfunction startTransition() {\n  startTransitionDOM(() => {\n    startTransitionART(() => {\n      startTransitionThreeFiber(() => {\n        // and so on...\n      });\n    });\n  });\n});\n\nThis is basically how flushSync is implemented, too.","shortMessageHtmlLink":"Fix async batching in React.startTransition"}},{"before":null,"after":"69d94fcb37dd5eba70235d24da6d2af2176aff3f","ref":"refs/heads/fix-async-batching-starttransition","pushedAt":"2024-05-23T02:37:42.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Fix async batching in React.startTransition\n\nDiscovered a flaw in the current implementation of the isomorphic\nstartTransition implementation (React.startTransition), related to async\nactions. It only creates an async scope if something calls setState\nwithin the synchronous part of the action (i.e. before the first\n`await`). I had thought this was fine because if there's no update\nduring this part, then there's nothing that needs to be entangled. I\ndidn't think this through, though — if there are multiple async updates\ninterleaved throughout the rest of the action, we need the async scope\nto have already been created so that _those_ are batched together.\n\nAn even more easier way to observe this is to schedule an optimistic\nupdate after an `await` — the optimistic update should not be reverted\nuntil the async action is complete.\n\nTo implement, during the reconciler's module initialization, we compose\nits startTransition implementation with any previous reconciler's\nstartTransition that was already initialized. Then, the isomorphic\nstartTransition is the composition of every\nreconciler's startTransition.\n\nfunction startTransition() {\n  startTransitionDOM(() => {\n    startTransitionART(() => {\n      startTransitionThreeFiber(() => {\n        // and so on...\n      });\n    });\n  });\n});\n\nThis is basically how flushSync is implemented, too.","shortMessageHtmlLink":"Fix async batching in React.startTransition"}},{"before":null,"after":"6a4ea52ddaac555b9439868d7eb7801bb6baba2d","ref":"refs/heads/19-bump-beta-to-rc","pushedAt":"2024-05-15T14:51:14.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Bump 19 beta to rc\n\nThis updates the Canary label from \"beta\" to \"rc\".\n\nWe will publish an actual RC (e.g. 19.0.0-rc.0)\ntoo; this only changes the label in the\ncanary releases.","shortMessageHtmlLink":"Bump 19 beta to rc"}},{"before":"68ddf36d58abea5b04152694f195f56a15e52810","after":"a23e517ffc4cae96d54cdfaf17ecad8cb2e056d9","ref":"refs/heads/useformstatus-pe","pushedAt":"2024-05-09T17:15:28.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"useFormStatus in progressively-enhanced forms\n\nBefore this change, `useFormStatus` is only activated if a form is\nsubmitted by an action function (either <form action={actionFn}> or\n<button formAction={actionFn}>).\n\nAfter this change, `useFormStatus` will also be activated if you call\n`startTransition(actionFn)` inside a submit event handler that is\n`preventDefault`-ed.\n\nThis is the last missing piece for implementing a custom `action` prop\nthat is progressively enhanced using `onSubmit` while maintaining the\nsame behavior as built-in form actions.\n\nHere's the basic recipe for implementing a progressively-enhanced\nform action:\n\n```js\nimport {requestFormReset} from 'react-dom';\n\n// To implement progressive enhancement, pass both a form action *and* a\n// submit event handler. The action is used for submissions that happen\n// before hydration, and the submit handler is used for submissions that\n// happen after.\n<form\n  action={action}\n  onSubmit={(event) => {\n    // After hydration, we upgrade the form with additional client-\n    // only behavior.\n    event.preventDefault();\n\n    // Manually dispatch the action.\n    startTransition(async () => {\n      // (Optional) Reset any uncontrolled inputs once the action is\n      // complete, like built-in form actions do.\n      requestFormReset(event.target);\n\n      // ...Do extra action-y stuff in here, like setting a custom\n      // optimistic state...\n\n      // Call the user-provided action\n      const formData = new FormData(event.target);\n      await action(formData);\n    });\n  }}\n/>\n```","shortMessageHtmlLink":"useFormStatus in progressively-enhanced forms"}},{"before":"439e58ff51b66b34957cf516e16cdac926a93c49","after":"68ddf36d58abea5b04152694f195f56a15e52810","ref":"refs/heads/useformstatus-pe","pushedAt":"2024-05-09T17:14:53.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"useFormStatus in progressively-enhanced forms\n\nBefore this change, `useFormStatus` is only activated if a form is\nsubmitted by an action function (either <form action={actionFn}> or\n<button formAction={actionFn}>).\n\nAfter this change, `useFormStatus` will also be activated if you call\n`startTransition(actionFn)` inside a submit event handler that is\n`preventDefault`-ed.\n\nThis is the last missing piece for implementing a custom `action` prop\nthat is progressively enhanced using `onSubmit` while maintaining the\nsame behavior as built-in form actions.\n\nHere's the basic recipe for implementing a progressively-enhanced\nform action:\n\n```js\nimport {requestFormReset} from 'react-dom';\n\n// To implement progressive enhancement, pass both a form action *and* a\n// submit event handler. The action is used for submissions that happen\n// before hydration, and the submit handler is used for submissions that\n// happen after.\n<form\n  action={action}\n  onSubmit={(event) => {\n    // After hydration, we upgrade the form with additional client-\n    // only behavior.\n    event.preventDefault();\n\n    // Manually dispatch the action.\n    startTransition(async () => {\n      // (Optional) Reset any uncontrolled inputs once the action is\n      // complete, like built-in form actions do.\n      requestFormReset();\n\n      // ...Do extra action-y stuff in here, like setting a custom\n      // optimistic state...\n\n      // Call the user-provided action\n      const formData = new FormData(event.target);\n      await action(formData);\n    });\n  }}\n/>\n```","shortMessageHtmlLink":"useFormStatus in progressively-enhanced forms"}},{"before":"64ddbfc4c00d661157da9f50094c4f850e715301","after":"439e58ff51b66b34957cf516e16cdac926a93c49","ref":"refs/heads/useformstatus-pe","pushedAt":"2024-05-09T16:49:29.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"useFormStatus in progressively-enhanced forms\n\nBefore this change, `useFormStatus` is only activated if a form is\nsubmitted by an action function (either <form action={actionFn}> or\n<button formAction={actionFn}>).\n\nAfter this change, `useFormStatus` will also be activated if you call\n`startTransition(actionFn)` inside a submit event handler that is\n`preventDefault`-ed.\n\nThis is the last missing piece for implementing a custom `action` prop\nthat is progressively enhanced using `onSubmit` while maintaining the\nsame behavior as built-in form actions.\n\nHere's the basic recipe for implementing a progressively-enhanced\nform action:\n\n```js\nimport {requestFormReset} from 'react-dom';\n\n// To implement progressive enhancement, pass both a form action *and* a\n// submit event handler. The action is used for submissions that happen\n// before hydration, and the submit handler is used for submissions that\n// happen after.\n<form\n  action={action}\n  onSubmit={(event) => {\n    // After hydration, we upgrade the form with additional client-\n    // only behavior.\n    event.preventDefault();\n\n    // Manually dispatch the action.\n    startTransition(async () => {\n      // (Optional) Reset any uncontrolled inputs once the action is\n      // complete, like built-in form actions do.\n      requestFormReset();\n\n      // ...Do extra action-y stuff in here, like setting a custom\n      // optimistic state...\n\n      // Call the user-provided action\n      const formData = new FormData(event.target);\n      await action(formData);\n    });\n  }}\n/>\n```","shortMessageHtmlLink":"useFormStatus in progressively-enhanced forms"}},{"before":"e647a77243d0863887f7df6bd9b50c4d434a97e3","after":"64ddbfc4c00d661157da9f50094c4f850e715301","ref":"refs/heads/useformstatus-pe","pushedAt":"2024-05-08T02:42:05.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"useFormStatus in progressively-enhanced forms\n\nBefore this change, `useFormStatus` is only activated if a form is\nsubmitted by an action function (either <form action={actionFn}> or\n<button formAction={actionFn}>).\n\nAfter this change, `useFormStatus` will also be activated if you call\n`startTransition(actionFn)` inside a submit event handler that is\n`preventDefault`-ed.\n\nThis is the last missing piece for implementing a custom `action` prop\nthat is progressively enhanced using `onSubmit` while maintaining the\nsame behavior as built-in form actions.\n\nHere's the basic recipe for implementing a progressively-enhanced\nform action:\n\n```js\nimport {requestFormReset} from 'react-dom';\n\n// To implement progressive enhancement, pass both a form action *and* a\n// submit event handler. The action is used for submissions that happen\n// before hydration, and the submit handler is used for submissions that\n// happen after.\n<form\n  action={action}\n  onSubmit={(event) => {\n    // After hydration, we upgrade the form with additional client-\n    // only behavior.\n    event.preventDefault();\n\n    // Manually dispatch the action.\n    startTransition(async () => {\n      // (Optional) Reset any uncontrolled inputs once the action is\n      // complete, like built-in form actions do.\n      requestFormReset();\n\n      // ...Do extra action-y stuff in here, like setting a custom\n      // optimistic state...\n\n      // Call the user-provided action\n      const formData = new FormData(event.target);\n      await action(formData);\n    });\n  }}\n/>\n```","shortMessageHtmlLink":"useFormStatus in progressively-enhanced forms"}},{"before":"db110d89c3c5b5fb3a13451282e0ef08d8a0f720","after":"e647a77243d0863887f7df6bd9b50c4d434a97e3","ref":"refs/heads/useformstatus-pe","pushedAt":"2024-05-08T02:28:38.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"useFormStatus in progressively-enhanced forms\n\nBefore this change, `useFormStatus` is only activated if a form is\nsubmitted by an action function (either <form action={actionFn}> or\n<button formAction={actionFn}>).\n\nAfter this change, `useFormStatus` will also be activated if you call\n`startTransition(actionFn)` inside a submit event handler that is\n`preventDefault`-ed.\n\nThis is the last missing piece for implementing a custom `action` prop\nthat is progressively enhanced using `onSubmit` while maintaining the\nsame behavior as built-in form actions.\n\nHere's the basic recipe for implementing a progressively-enhanced\nform action:\n\n```js\nimport {requestFormReset} from 'react-dom';\n\n// To implement progressive enhancement, pass both a form action *and* a\n// submit event handler. The action is used for submissions that happen\n// before hydration, and the submit handler is used for submissions that\n// happen after.\n<form\n  action={action}\n  onSubmit={(event) => {\n    // After hydration, we upgrade the form with additional client-\n    // only behavior.\n    event.preventDefault();\n\n    // Manually dispatch the action.\n    startTransition(async () => {\n      // (Optional) Reset any uncontrolled inputs once the action is\n      // complete, like built-in form actions do.\n      requestFormReset();\n\n      // ...Do extra action-y stuff in here, like setting a custom\n      // optimistic state...\n\n      // Call the user-provided action\n      const formData = new FormData(event.target);\n      await action(formData);\n    });\n  }}\n/>\n```","shortMessageHtmlLink":"useFormStatus in progressively-enhanced forms"}},{"before":null,"after":"db110d89c3c5b5fb3a13451282e0ef08d8a0f720","ref":"refs/heads/useformstatus-pe","pushedAt":"2024-05-08T02:28:23.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"useFormStatus in progressively-enhanced forms\n\nBefore this change, `useFormStatus` is only activated if a form is\nsubmitted by an action function (either <form action={actionFn}> or\n<button formAction={actionFn}>).\n\nAfter this change, `useFormStatus` will also be activated if you call\n`startTransition(actionFn)` inside a submit event handler that is\n`preventDefault`-ed.\n\nThis is the last missing piece for implementing a custom `action` prop\nthat is progressively enhanced using `onSubmit` while maintaining the\nsame behavior as built-in form actions.\n\nHere's the basic recipe for implementing a progressively-enhanced\nform action:\n\n```js\nimport {requestFormReset} from 'react-dom';\n\n// To implement progressive enhancement, pass both a form action *and* a\n// submit event handler. The action is used for submissions that happen\n// before hydration, and the submit handler is used for submissions that\n// happen after.\n<form\n  action={action}\n  onSubmit={(event) => {\n    // After hydration, we upgrade the form with additional client-\n    // only behavior.\n    event.preventDefault();\n\n    // Manually dispatch the action.\n    startTransition(async () => {\n      // (Optional) Reset any uncontrolled inputs once the action is\n      // complete, like built-in form actions do.\n      requestFormReset();\n\n      // ...Do extra action-y stuff in here, like setting a custom\n      // optimistic state...\n\n      // Call the user-provided action\n      const formData = new FormData(event.target);\n      await action(formData);\n    });\n  }}\n/>\n```","shortMessageHtmlLink":"useFormStatus in progressively-enhanced forms"}},{"before":"8a015b68cc060079878e426610e64e86fb328f8d","after":"a87edf62d7d69705ddbcec9a24f0780b3db7535f","ref":"refs/heads/prepare-19-beta","pushedAt":"2024-04-25T16:29:29.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Update canary channel label to \"beta\"\n\nDuring the beta period, canaries will be published as\n19.0.0-beta-<COMMIT_SHA>-<DATE>. They will also be tagged as `beta` when\npublished to npm.","shortMessageHtmlLink":"Update canary channel label to \"beta\""}},{"before":"8856a2ba239de332f0ec3c40b064fd8c309da08f","after":"8a015b68cc060079878e426610e64e86fb328f8d","ref":"refs/heads/prepare-19-beta","pushedAt":"2024-04-25T16:22:12.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Add deprecation warning for unmountComponentAtNode\n\nThis should have been deprecated in 18.0 alongside the other legacy\nDOM APIs like render().","shortMessageHtmlLink":"Add deprecation warning for unmountComponentAtNode"}},{"before":null,"after":"3727294140fb5eb3bba342d968ebadac37466c1a","ref":"refs/heads/revert-shared-ref-change-again","pushedAt":"2024-04-25T16:14:44.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Go back to shared refs instance object\n\nIt turns out we already made refs writable in #25696, which has been\nin canary for over a year. The approach in that PR also has the benefit\nof being slightly more perf sensitive because it still uses a shared\nobject until the fiber is mounted. So let's just go back to that.","shortMessageHtmlLink":"Go back to shared refs instance object"}},{"before":"ab7322b5a07d646754dbece170ec5e8568b6e104","after":"5f315c8f95ebbb14f92219920dda5c7f6e7b4441","ref":"refs/heads/console-error-rtr-deprecation","pushedAt":"2024-04-24T18:41:36.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"warn -> error for Test Renderer deprecation\n\nWe use `console.error` for deprecations. `console.warn` is for less\ncritical issues, like performance anti-patterns.","shortMessageHtmlLink":"warn -&gt; error for Test Renderer deprecation"}},{"before":"e942a6a712fc1bb1bbc3e4eba4e064ae8fd67be6","after":"ab7322b5a07d646754dbece170ec5e8568b6e104","ref":"refs/heads/console-error-rtr-deprecation","pushedAt":"2024-04-24T17:40:29.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"warn -> error for Test Renderer deprecation\n\nWe use `console.error` for deprecations. `console.warn` is for less\ncritical issues, like performance anti-patterns.","shortMessageHtmlLink":"warn -&gt; error for Test Renderer deprecation"}},{"before":null,"after":"8856a2ba239de332f0ec3c40b064fd8c309da08f","ref":"refs/heads/prepare-19-beta","pushedAt":"2024-04-24T17:08:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Update canary channel label to \"beta\"\n\nDuring the beta period, canaries will be published as\n19.0.0-beta-<COMMIT_SHA>-<DATE>. They will also be tagged as `beta` when\npublished to npm.","shortMessageHtmlLink":"Update canary channel label to \"beta\""}},{"before":"0deca55742ba11d151fc8d88f2b66672b73b75ca","after":"e942a6a712fc1bb1bbc3e4eba4e064ae8fd67be6","ref":"refs/heads/console-error-rtr-deprecation","pushedAt":"2024-04-24T17:06:37.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"warn -> error for Test Renderer deprecation\n\nWe use `console.error` for deprecations. `console.warn` is for less\ncritical issues, like performance anti-patterns.","shortMessageHtmlLink":"warn -&gt; error for Test Renderer deprecation"}},{"before":"4d8a3698bf23f22efffc701e3de5804bf35b1ce6","after":"0deca55742ba11d151fc8d88f2b66672b73b75ca","ref":"refs/heads/console-error-rtr-deprecation","pushedAt":"2024-04-24T16:55:16.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"warn -> error for Test Renderer deprecation\n\nWe use `console.error` for deprecations. `console.warn` is for less\ncritical issues, like performance anti-patterns.","shortMessageHtmlLink":"warn -&gt; error for Test Renderer deprecation"}},{"before":"55a0f87968cccf0306b6906343c30908a8da7152","after":"4d8a3698bf23f22efffc701e3de5804bf35b1ce6","ref":"refs/heads/console-error-rtr-deprecation","pushedAt":"2024-04-24T16:37:27.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"warn -> error for Test Renderer deprecation\n\nWe use `console.error` for deprecations. `console.warn` is for less\ncritical issues, like performance anti-patterns.","shortMessageHtmlLink":"warn -&gt; error for Test Renderer deprecation"}},{"before":"13ee48ac765f0de4154c098120e0a88e90cd5a8c","after":"55a0f87968cccf0306b6906343c30908a8da7152","ref":"refs/heads/console-error-rtr-deprecation","pushedAt":"2024-04-24T15:59:30.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"warn -> error for Test Renderer deprecation\n\nWe use `console.error` for deprecations. `console.warn` is for less\ncritical issues, like performance anti-patterns.","shortMessageHtmlLink":"warn -&gt; error for Test Renderer deprecation"}},{"before":"4c0cb8c500ce710e0b771967b17a745d939c56cc","after":"13ee48ac765f0de4154c098120e0a88e90cd5a8c","ref":"refs/heads/console-error-rtr-deprecation","pushedAt":"2024-04-24T15:57:39.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"warn -> error for Test Renderer deprecation\n\nWe use `console.error` for deprecations. `console.warn` is for less\ncritical issues, like performance anti-patterns.","shortMessageHtmlLink":"warn -&gt; error for Test Renderer deprecation"}},{"before":null,"after":"4c0cb8c500ce710e0b771967b17a745d939c56cc","ref":"refs/heads/console-error-rtr-deprecation","pushedAt":"2024-04-24T15:56:06.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"warn -> error for Test Renderer deprecation\n\nWe use `console.error` for deprecations. `console.warn` is for less\ncritical issues, like performance anti-patterns.","shortMessageHtmlLink":"warn -&gt; error for Test Renderer deprecation"}},{"before":null,"after":"5ff57ccadf77f1570ee7114471fa1c1b16fce3fe","ref":"refs/heads/remove-fetch-patch","pushedAt":"2024-04-23T17:32:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Remove automatic fetch `cache` instrumentation\n\nThis removes the automatic patching of the global `fetch` function in\nServer Components environments to dedupe requests using `React.cache`,\na behavior that some RSC framework maintainers have objected to.\n\nWe may revisit this decision in the future, but for now it's not worth\nthe controversy.\n\nFrameworks that have already shipped this behavior, like Next.js, can\nreimplement it in userspace.\n\nI considered keeping the implementation in the codebase and disabling\nit by setting `enableFetchInstrumentation` to `false` everywhere, but\nsince that also disables the tests, it doesn't seem worth it because\nwithout test coverage the behavior is likely to drift regardless. We\ncan just revert this PR later if desired.","shortMessageHtmlLink":"Remove automatic fetch <code>cache</code> instrumentation"}},{"before":"001602f90889dcf96fc1a025011e436a57c0b024","after":"e625cd8f7411aa7ec681f5b1e04b6ab26d14ddf7","ref":"refs/heads/dont-minify-symbols","pushedAt":"2024-04-19T19:59:01.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Don't minify symbols in production builds\n\nThis disables symbol renaming in production builds. The original\nvariable and function names are preserved. All other forms of\ncompression applied by Closure (dead code elimination, inlining, etc)\nare unchanged — the final program is identical to what we were\nproducing before, just in a more readable form.\n\nThe motivation is to make it easier to debug React issues that only\noccur in production — the same reason we decided to start shipping\nsourcemaps in #28827 and #28827.\n\nHowever, because most apps run their own minification step on their\nnpm dependencies, it's not necessary for us to minify the symbols\nbefore publishing — it'll be handled the app, if desired.\n\nThis is the same strategy Meta has used to ship React for years. The\nReact build itself has unminified symbols, but they get minified as part\nof Meta's regular build pipeline.\n\nEven if an app does not minify their npm dependencies, gzip covers\nmost of the cost of symbol renaming anyway.\n\nThis saves us from having to ship sourcemaps, which means even apps that\ndon't have sourcemaps configured will be able to debug the React build\nas easily as they would any other npm dependency.","shortMessageHtmlLink":"Don't minify symbols in production builds"}},{"before":"c4f36e89de05f62f09cd3b9b59045fd140e88318","after":"001602f90889dcf96fc1a025011e436a57c0b024","ref":"refs/heads/dont-minify-symbols","pushedAt":"2024-04-19T19:57:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Don't minify symbols in production builds\n\nThis disables symbol renaming in production builds. The original\nvariable and function names are preserved. All other forms of\ncompression applied by Closure (dead code elimination, inlining, etc)\nare unchanged — the final program is identical to what we were\nproducing before, just in a more readable form.\n\nThe motivation is to make it easier to debug React issues that only\noccur in production — the same reason we decided to start shipping\nsourcemaps in #28827 and #28827.\n\nHowever, because most apps run their own minification step on their\nnpm dependencies, it's not necessary for us to minify the symbols\nbefore publishing — it'll be handled the app, if desired.\n\nThis is the same strategy Meta has used to ship React for years. The\nReact build itself has unminified symbols, but they get minified as part\nof Meta's regular build pipeline.\n\nEven if an app does not minify their npm dependencies, gzip covers\nmost of the cost of symbol renaming anyway.\n\nThis saves us from having to ship sourcemaps, which means even apps that\ndon't have sourcemaps configured will be able to debug the React build\nas easily as they would any other npm dependency.","shortMessageHtmlLink":"Don't minify symbols in production builds"}},{"before":"9f026287c06b1f608747164232e286d4ff52be85","after":"c4f36e89de05f62f09cd3b9b59045fd140e88318","ref":"refs/heads/dont-minify-symbols","pushedAt":"2024-04-19T19:40:22.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"acdlite","name":"Andrew Clark","path":"/acdlite","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3624098?s=80&v=4"},"commit":{"message":"Don't minify symbols in production builds\n\nThis disables symbol renaming in production builds. The original\nvariable and function names are preserved. All other forms of\ncompression applied by Closure (dead code elimination, inlining, etc)\nare unchanged — the final program is identical to what we were\nproducing before, just in a more readable form.\n\nThe motivation is to make it easier to debug React issues that only\noccur in production — the same reason we decided to start shipping\nsourcemaps in #28827 and #28827.\n\nHowever, because most apps run their own minification step on their\nnpm dependencies, it's not necessary for us to minify the symbols\nbefore publishing — it'll be handled the app, if desired.\n\nThis is the same strategy Meta has used to ship React for years. The\nReact build itself has unminified symbols, but they get minified as part\nof Meta's regular build pipeline.\n\nEven if an app does not minify their npm dependencies, gzip covers\nmost of the cost of symbol renaming anyway.\n\nThis saves us from having to ship sourcemaps, which means even apps that\ndon't have sourcemaps configured will be able to debug the React build\nas easily as they would any other npm dependency.","shortMessageHtmlLink":"Don't minify symbols in production builds"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEUzbyLQA","startCursor":null,"endCursor":null}},"title":"Activity · acdlite/react"}