{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":35444156,"defaultBranch":"master","name":"angular","ownerLogin":"alxhub","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2015-05-11T19:08:26.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/4175141?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1715884271.0","currentOid":""},"activityList":{"items":[{"before":"b62a589ad281aba01fe790dc340717139d7b6e63","after":"9f6e8290a5fd3b3c004920c0ec7dde9d98217974","ref":"refs/heads/cf/narrowing-fix","pushedAt":"2024-05-17T14:37:24.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"fix(compiler-cli): fix type narrowing of `@if` with aliases\n\nWhen an `@if` expression has an alias, only the type of the alias is\ncurrently narrowed. So for example, suppose `value` is `string|undefined`:\n\n```\n@if (value; as alias) {\n  {{ value.length }} <!-- error, value may be undefined -->\n  {{ alias.length }} <!-- no error, alias is narrowed -->\n}\n```\n\nThis is especially noticeable when the expression contains guards which are\npreconditions for the aliased expression:\n\n```\n@if (a && b; as alias) {...}\n```\n\nIn this case, `a` would not be narrowed within the body, even though the\n`@if` condition forces it to be truthy. This is a bug.\n\nThe reason is that aliased expressions were previously type-checked as:\n\n```\nvar alias = a && b;\nif (alias) {\n  // nothing other than alias is narrowed\n  ...\n}\n```\n\nOne option considered was to emit `const alias` instead of `var alias`.\nTypeScript _does_ trace `const` expressions and narrow their individual\ncomponents when the overall expression is guarded:\n\n```\nconst alias = a && b;\nif (alias) {\n  // a, b are also narrowed\n}\n```\n\nHowever, this narrowing has different semantics than if `a && b` appeared\ndirectly in the guard expression. For example, object properties aren't\nnarrowed with this approach, so component properties (which are referenced\nas e.g. `this.a`) would not be narrowed.\n\nInstead, we amend the guard expression to include both the expression _and_ the\nalias variable, enforcing that both are narrowed.\n\n```\nvar alias = a && b;\nif ((a && b) && alias) {\n  // a, b, and alias all narrowed correctly.\n}\n```\n\nThis form ensures all conditions within the guard expression get narrowed\nwhile also narrowing the alias variable type.\n\nFixes #52855","shortMessageHtmlLink":"fix(compiler-cli): fix type narrowing of <code>@if</code> with aliases"}},{"before":"f00e0408adcf281d8c324968324ff8f604fb0ffb","after":"b62a589ad281aba01fe790dc340717139d7b6e63","ref":"refs/heads/cf/narrowing-fix","pushedAt":"2024-05-16T23:53:56.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"fix(compiler-cli): fix type narrowing of `@if` with aliases\n\nWhen an `@if` expression has an alias, only the type of the alias is\ncurrently narrowed. So for example, suppose `value` is `string|undefined`:\n\n```\n@if (value; as alias) {\n  {{ value.length }} <!-- error, value may be undefined -->\n  {{ alias.length }} <!-- no error, alias is narrowed -->\n}\n```\n\nThis is especially noticeable when the expression contains guards which are\npreconditions for the aliased expression:\n\n```\n@if (a && b; as alias) {...}\n```\n\nIn this case, `a` would not be narrowed within the body, even though the\n`@if` condition forces it to be truthy. This is a bug.\n\nThe reason is that aliased expressions were previously type-checked as:\n\n```\nvar alias = a && b;\nif (alias) {\n  // nothing other than alias is narrowed\n  ...\n}\n```\n\nOne option considered was to emit `const alias` instead of `var alias`.\nTypeScript _does_ trace `const` expressions and narrow their individual\ncomponents when the overall expression is guarded:\n\n```\nconst alias = a && b;\nif (alias) {\n  // a, b are also narrowed\n}\n```\n\nHowever, this narrowing has different semantics than if `a && b` appeared\ndirectly in the guard expression. For example, object properties aren't\nnarrowed with this approach, so component properties (which are referenced\nas e.g. `this.a`) would not be narrowed.\n\nInstead, a different technique is used: an alias variable is declared inside\nthe `if` guard, capturing the inferred type.\n\n```\nif (a && b) {\n  var alias = a && b;\n  // a, b, and alias all narrowed correctly.\n}\n```\n\nThis form ensures all conditions within the guard expression get narrowed\nwhile also narrowing the alias variable type, and works for property\nnarrowing as well. It also allows renaming to rename the alias variable,\nsince all references to that variable are generated with correct source\nmapping.\n\nFixes #52855","shortMessageHtmlLink":"fix(compiler-cli): fix type narrowing of <code>@if</code> with aliases"}},{"before":"4d6398e61a9d76d8783caab30f782e1ea5c6e600","after":"f00e0408adcf281d8c324968324ff8f604fb0ffb","ref":"refs/heads/cf/narrowing-fix","pushedAt":"2024-05-16T18:34:51.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"fix(compiler-cli): fix type narrowing of `@if` with aliases\n\nWhen an `@if` expression has an alias, only the type of the alias is\ncurrently narrowed. So for example, suppose `value` is `string|undefined`:\n\n```\n@if (value; as alias) {\n  {{ value.length }} <!-- error, value may be undefined -->\n  {{ alias.length }} <!-- no error, alias is narrowed -->\n}\n```\n\nThis is especially noticeable when the expression contains guards which are\npreconditions for the aliased expression:\n\n```\n@if (a && b; as alias) {...}\n```\n\nIn this case, `a` would not be narrowed within the body, even though the\n`@if` condition forces it to be truthy. This is a bug.\n\nThe reason is that aliased expressions were previously type-checked as:\n\n```\nvar alias = a && b;\nif (alias) {\n  // nothing other than alias is narrowed\n  ...\n}\n```\n\nOne option considered was to emit `const alias` instead of `var alias`.\nTypeScript _does_ trace `const` expressions and narrow their individual\ncomponents when the overall expression is guarded:\n\n```\nconst alias = a && b;\nif (alias) {\n  // a, b are also narrowed\n}\n```\n\nHowever, this narrowing has different semantics than if `a && b` appeared\ndirectly in the guard expression. For example, object properties aren't\nnarrowed with this approach, so component properties (which are referenced\nas e.g. `this.a`) would not be narrowed.\n\nInstead, a different technique is used: an alias variable is declared inside\nthe `if` guard, capturing the inferred type.\n\n```\nif (a && b) {\n  var alias = a && b;\n  // a, b, and alias all narrowed correctly.\n}\n```\n\nThis form ensures all conditions within the guard expression get narrowed\nwhile also narrowing the alias variable type, and works for property\nnarrowing as well. It also allows renaming to rename the alias variable,\nsince all references to that variable are generated with correct source\nmapping.\n\nFixes #52855","shortMessageHtmlLink":"fix(compiler-cli): fix type narrowing of <code>@if</code> with aliases"}},{"before":null,"after":"4d6398e61a9d76d8783caab30f782e1ea5c6e600","ref":"refs/heads/cf/narrowing-fix","pushedAt":"2024-05-16T18:31:11.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"fix(compiler-cli): fix type narrowing of `@if` with aliases\n\nWhen an `@if` expression has an alias, only the type of the alias is\ncurrently narrowed. So for example, suppose `value` is `string|undefined`:\n\n```\n@if (value; as alias) {\n  {{ value.length }} <!-- error, value may be undefined -->\n  {{ alias.length }} <!-- no error, alias is narrowed -->\n}\n```\n\nThis is especially noticeable when the expression contains guards which are\npreconditions for the aliased expression:\n\n```\n@if (a && b; as alias) {...}\n```\n\nIn this case, `a` would not be narrowed within the body, even though the\n`@if` condition forces it to be truthy. This is a bug.\n\nThe reason is that aliased expressions were previously type-checked as:\n\n```\nvar alias = a && b;\nif (alias) {\n  // nothing other than alias is narrowed\n  ...\n}\n```\n\nOne option considered was to emit `const alias` instead of `var alias`.\nTypeScript _does_ trace `const` expressions and narrow their individual\ncomponents when the overall expression is guarded:\n\n```\nconst alias = a && b;\nif (alias) {\n  // a, b are also narrowed\n}\n```\n\nHowever, this narrowing has different semantics than if `a && b` appeared\ndirectly in the guard expression. For example, object properties aren't\nnarrowed with this approach, so component properties (which are referenced\nas e.g. `this.a`) would not be narrowed.\n\nInstead, a different technique is used: an alias variable is declared inside\nthe `if` guard, capturing the inferred type.\n\n```\nif (a && b) {\n  var alias = a && b;\n  // a, b, and alias all narrowed correctly.\n}\n```\n\nThis form ensures all conditions within the guard expression get narrowed\nwhile also narrowing the alias variable type, and works for property\nnarrowing as well. It also allows renaming to rename the alias variable,\nsince all references to that variable are generated with correct source\nmapping.\n\nFixes #52855","shortMessageHtmlLink":"fix(compiler-cli): fix type narrowing of <code>@if</code> with aliases"}},{"before":"6159c0be0eba0ac21ffb3a6dc99fcaca01aeb8a9","after":"e0ce343d14fe934cecdee7de8e608478552654ef","ref":"refs/heads/deprecate-interpolations","pushedAt":"2024-05-14T18:08:35.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"atscott","name":"Andrew Scott","path":"/atscott","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/479713?s=80&v=4"},"commit":{"message":"refactor(core): deprecate `@Component.interpolation`\n\nAngular has long had the ability to use different interpolation delimiters\n(by default `{{` and `}}`). This concept was copied over from AngularJS,\nwhere AngularJS syntax is included in HTML sent over the network to the\nbrowser. Occasionally developers would use SSR frameworks which _also_ have\ninterpolation syntaxes of their own, so there was a need to change the\ndelimiters used by AngularJS to avoid conflicts.\n\nSince Angular templates are always processed by our compiler and the\ninterpolation characters are never processed by other systems first, this\noption is vestigial in Angular and only increases the complexity of our\nparser.\n\nDEPRECATED: `@Component.interpolation` is deprecated. Use Angular's\ndelimiters instead.","shortMessageHtmlLink":"refactor(core): deprecate <code>@Component.interpolation</code>"}},{"before":"6ec47530fcdb48212edb363578b61e4485731083","after":"6159c0be0eba0ac21ffb3a6dc99fcaca01aeb8a9","ref":"refs/heads/deprecate-interpolations","pushedAt":"2024-05-14T14:44:40.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"refactor(core): deprecate `@Component.interpolation`\n\nAngular has long had the ability to use different interpolation delimiters\n(by default `{{` and `}}`). This concept was copied over from AngularJS,\nwhere AngularJS syntax is included in HTML sent over the network to the\nbrowser. Occasionally developers would use SSR frameworks which _also_ have\ninterpolation syntaxes of their own, so there was a need to change the\ndelimiters used by AngularJS to avoid conflicts.\n\nSince Angular templates are always processed by our compiler and the\ninterpolation characters are never processed by other systems first, this\noption is vestigial in Angular and only increases the complexity of our\nparser.\n\nDEPRECATED: `@Component.interpolation` is deprecated. Use Angular's\ndelimiters instead.","shortMessageHtmlLink":"refactor(core): deprecate <code>@Component.interpolation</code>"}},{"before":"2223ac0410e0cc820e5fdca2e19f7ed13ac4415e","after":"6ec47530fcdb48212edb363578b61e4485731083","ref":"refs/heads/deprecate-interpolations","pushedAt":"2024-05-13T16:58:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"refactor(core): deprecate `@Component.interpolation`\n\nAngular has long had the ability to use different interpolation delimiters\n(by default `{{` and `}}`). This concept was copied over from AngularJS,\nwhere AngularJS syntax is included in HTML sent over the network to the\nbrowser. Occasionally developers would use SSR frameworks which _also_ have\ninterpolation syntaxes of their own, so there was a need to change the\ndelimiters used by AngularJS to avoid conflicts.\n\nSince Angular templates are always processed by our compiler and the\ninterpolation characters are never processed by other systems first, this\noption is vestigial in Angular and only increases the complexity of our\nparser.\n\nDEPRECATION:\n\n`@Component.interpolation` is deprecated. Use Angular's\ndelimiters instead.","shortMessageHtmlLink":"refactor(core): deprecate <code>@Component.interpolation</code>"}},{"before":"56e8032e70070999078fa917f364d888284b1f44","after":"2223ac0410e0cc820e5fdca2e19f7ed13ac4415e","ref":"refs/heads/deprecate-interpolations","pushedAt":"2024-05-13T16:51:58.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"refactor(core): deprecate `@Component.interpolation`\n\nAngular has long had the ability to use different interpolation delimiters\n(by default `{{` and `}}`). This concept was copied over from AngularJS,\nwhere AngularJS syntax is included in HTML sent over the network to the\nbrowser. Occasionally developers would use SSR frameworks which _also_ have\ninterpolation syntaxes of their own, so there was a need to change the\ndelimiters used by AngularJS to avoid conflicts.\n\nSince Angular templates are always processed by our compiler and the\ninterpolation characters are never processed by other systems first, this\noption is vestigial in Angular and only increases the complexity of our\nparser.\n\nDEPRECATION:\n\n`@Component.interpolation` is deprecated. Use Angular's\ndelimiters instead.","shortMessageHtmlLink":"refactor(core): deprecate <code>@Component.interpolation</code>"}},{"before":null,"after":"56e8032e70070999078fa917f364d888284b1f44","ref":"refs/heads/deprecate-interpolations","pushedAt":"2024-05-13T16:29:17.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"refactor(core): deprecate `@Component.interpolation`\n\nAngular has long had the ability to use different interpolation delimiters\n(by default `{{` and `}}`). This concept was copied over from AngularJS,\nwhere AngularJS syntax is included in HTML sent over the network to the\nbrowser. Occasionally developers would use SSR frameworks which _also_ have\ninterpolation syntaxes of their own, so there was a need to change the\ndelimiters used by AngularJS to avoid conflicts.\n\nSince Angular templates are always processed by our compiler and the\ninterpolation characters are never processed by other systems first, this\noption is vestigial in Angular and only increases the complexity of our\nparser.\n\nDEPRECATION: `@Component.interpolation` is deprecated. Use Angular's\ndelimiters instead.","shortMessageHtmlLink":"refactor(core): deprecate <code>@Component.interpolation</code>"}},{"before":null,"after":"25b164b40797c9ad15b4eadd6d383a3acab25a57","ref":"refs/heads/revert-9f7b9ed","pushedAt":"2024-04-17T00:04:56.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"Revert \"refactor(core): warn about duplicated keys when using built-in @for (#55243)\"\n\nThis reverts commit 9f7b9ed87a671d4df5d9e519d57a78d718f44524. Reason: g3\nusers reported a bug in the logic that produces false warnings in some\ncases.","shortMessageHtmlLink":"Revert \"refactor(core): warn about duplicated keys when using built-in <a class=\"user-mention notranslate\" data-hovercard-type=\"user\" data-hovercard-url=\"/users/for/hovercard\" data-octo-click=\"hovercard-link-click\" data-octo-dimensions=\"link_type:self\" href=\"https://github.com/for\">…</a>"}},{"before":null,"after":"f3cf066f33e0583ef7c59e888b6cb04a5961de70","ref":"refs/heads/gh/52855","pushedAt":"2024-04-01T20:24:10.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"fix(compiler-cli): fix type narrowing of `@if` with aliases\n\nWhen an `@if` expression has an alias, only the type of the alias is\ncurrently narrowed. So for example, suppose `value` is `string|undefined`:\n\n```\n@if (value; as alias) {\n  {{ value.length }} <!-- error, value may be undefined -->\n  {{ alias.length }} <!-- no error, alias is narrowed -->\n}\n```\n\nThis is especially noticeable when the expression contains guards which are\npreconditions for the aliased expression:\n\n```\n@if (a && b; as alias) {...}\n```\n\nIn this case, `a` would not be narrowed within the body, even though the\n`@if` condition forces it to be truthy. This is a bug.\n\nThe reason is that aliased expressions were previously type-checked as:\n\n```\nvar alias = a && b;\nif (alias) {\n  // nothing other than alias is narrowed\n  ...\n}\n```\n\nOne option considered was to emit `const alias` instead of `var alias`.\nTypeScript _does_ trace `const` expressions and narrow their individual\ncomponents when the overall expression is guarded:\n\n```\nconst alias = a && b;\nif (alias) {\n  // a, b are also narrowed\n}\n```\n\nHowever, this narrowing has different semantics than if `a && b` appeared\ndirectly in the guard expression. For example, object properties aren't\nnarrowed with this approach, so component properties (which are referenced\nas e.g. `this.a`) would not be narrowed.\n\nInstead, a different technique is used. The alias variable is declared with\nno type, and gets its type inferred by the guard expression:\n\n```\nlet alias;\nif (alias = (a && b)) {\n  // a, b, and alias all narrowed correctly.\n}\n```\n\nThis form ensures all conditions within the guard expression get narrowed\nwhile also narrowing the alias variable type, and works for property\nnarrowing as well.\n\nFixes #52855","shortMessageHtmlLink":"fix(compiler-cli): fix type narrowing of <code>@if</code> with aliases"}},{"before":null,"after":"57c836ff63225abf3e695bac92c17ba740599004","ref":"refs/heads/pullapprove-refactor","pushedAt":"2024-03-27T22:49:39.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"build: simply pullapprove config significantly\n\nThis commit attempts to merge a number of the granular approval groups we've\nbeen using in pullapprove into more general groups. The largest such new\ngroup is `fw-general` which contains most of the framework code.","shortMessageHtmlLink":"build: simply pullapprove config significantly"}},{"before":null,"after":"43aa8b26ee96433e97af0dcbf33216a871628b9a","ref":"refs/heads/revert-router-injector-pr","pushedAt":"2024-03-15T18:48:10.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"Revert \"fix(router): Routed components never inherit `RouterOutlet` `EnvironmentInjector` (#54265)\"\n\nThis reverts commit da906fdafcbb302fa280a162d1c1f04369be2efa.\n\nThis change causes some test failures in google3.","shortMessageHtmlLink":"Revert \"fix(router): Routed components never inherit <code>RouterOutlet</code> `…"}},{"before":null,"after":"cff58901176d8526bd2a78deb21e491a3c54b79f","ref":"refs/heads/ngtsc/version-detect","pushedAt":"2024-03-05T23:31:03.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"fix(compiler-cli): symbol feature detection for the compiler\n\nUse the actual symbol presence in the .d.ts to detect whether two-way\nbinding to writable signals should be template type-checked.","shortMessageHtmlLink":"fix(compiler-cli): symbol feature detection for the compiler"}},{"before":"92adae1164bf3d24de56064098ae36451b0a73f9","after":"3b967b35d5093058fea9bdd03096f3ce8129fd26","ref":"refs/heads/fw-untracking","pushedAt":"2024-02-27T22:31:33.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"fix(core): untrack various core operations\n\nOne downside of implicit dependency tracking in `effect()`s is that it's easy\nto for downstream code to end up running inside the effect context by accident.\nFor example, if an effect raises an event (e.g. by `next()`ing a `Subject`), the\nsubscribers to that `Observable` will run inside the effect's reactive context,\nand any signals read within the subscriber will end up as dependencies of the\neffect. This is why the `untracked` function is useful, to run certain\noperations without incidental signal reads ending up tracked.\n\nHowever, knowing when this is necessary is non-trivial. For example, injecting\na dependency might cause it to be instantiated, which would run the constructor\nin the effect context unless the injection operation is untracked.\n\nTherefore, Angular will automatically drop the reactive context within a number\nof framework APIs. This commit addresses these use cases:\n\n* creating and destroying views\n* creating and destroying DI injectors\n* injecting dependencies\n* emitting outputs\n\nFixes #54548\n\nThere are likely other APIs which would benefit from this approach, but this\nis a start.","shortMessageHtmlLink":"fix(core): untrack various core operations"}},{"before":"94a49363aa38cc53a32ca3a9d36bf069ffa5bc94","after":"92adae1164bf3d24de56064098ae36451b0a73f9","ref":"refs/heads/fw-untracking","pushedAt":"2024-02-27T19:45:40.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"fix(core): untrack various core operations\n\nOne downside of implicit dependency tracking in `effect()`s is that it's easy\nto for downstream code to end up running inside the effect context by accident.\nFor example, if an effect raises an event (e.g. by `next()`ing a `Subject`), the\nsubscribers to that `Observable` will run inside the effect's reactive context,\nand any signals read within the subscriber will end up as dependencies of the\neffect. This is why the `untracked` function is useful, to run certain\noperations without incidental signal reads ending up tracked.\n\nHowever, knowing when this is necessary is non-trivial. For example, injecting\na dependency might cause it to be instantiated, which would run the constructor\nin the effect context unless the injection operation is untracked.\n\nTherefore, Angular will automatically drop the reactive context within a number\nof framework APIs. This commit addresses these use cases:\n\n* creating and destroying views\n* creating and destroying DI injectors\n* injecting dependencies\n* emitting outputs\n\nFixes #54548\n\nThere are likely other APIs which would benefit from this approach, but this\nis a start.","shortMessageHtmlLink":"fix(core): untrack various core operations"}},{"before":"1b2ee7829a4e16651860c920ddc26d8a08c57e38","after":"94a49363aa38cc53a32ca3a9d36bf069ffa5bc94","ref":"refs/heads/fw-untracking","pushedAt":"2024-02-27T01:11:30.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"fix(core): untrack various core operations\n\nOne downside of implicit dependency tracking in `effect()`s is that it's easy\nto for downstream code to end up running inside the effect context by accident.\nFor example, if an effect raises an event (e.g. by `next()`ing a `Subject`), the\nsubscribers to that `Observable` will run inside the effect's reactive context,\nand any signals read within the subscriber will end up as dependencies of the\neffect. This is why the `untracked` function is useful, to run certain\noperations without incidental signal reads ending up tracked.\n\nHowever, knowing when this is necessary is non-trivial. For example, injecting\na dependency might cause it to be instantiated, which would run the constructor\nin the effect context unless the injection operation is untracked.\n\nTherefore, Angular will automatically drop the reactive context within a number\nof framework APIs. This commit addresses these use cases:\n\n* creating and destroying views\n* creating and destroying DI injectors\n* injecting dependencies\n* emitting outputs\n\nFixes #54548\n\nThere are likely other APIs which would benefit from this approach, but this\nis a start.","shortMessageHtmlLink":"fix(core): untrack various core operations"}},{"before":null,"after":"1b2ee7829a4e16651860c920ddc26d8a08c57e38","ref":"refs/heads/fw-untracking","pushedAt":"2024-02-27T01:03:28.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"fix(core): untrack various core operations\n\nOne downside of implicit dependency tracking in `effect()`s is that it's easy\nto for downstream code to end up running inside the effect context by accident.\nFor example, if an effect raises an event (e.g. by `next()`ing a `Subject`), the\nsubscribers to that `Observable` will run inside the effect's reactive context,\nand any signals read within the subscriber will end up as dependencies of the\neffect. This is why the `untracked` function is useful, to run certain\noperations without incidental signal reads ending up tracked.\n\nHowever, knowing when this is necessary is non-trivial. For example, injecting\na dependency might cause it to be instantiated, which would run the constructor\nin the effect context unless the injection operation is untracked.\n\nTherefore, Angular will automatically drop the reactive context within a number\nof framework APIs. This commit addresses these use cases:\n\n* creating and destroying views\n* creating and destroying DI injectors\n* injecting dependencies\n* emitting outputs\n\nThere are likely other APIs which would benefit from this approach, but this\nis a start.","shortMessageHtmlLink":"fix(core): untrack various core operations"}},{"before":null,"after":"fa51f8bec5d2cf614db717bb5c3bf67e5c403777","ref":"refs/heads/release-stage-17.3.0-next.0","pushedAt":"2024-02-22T02:00:49.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"release: cut the v17.3.0-next.0 release","shortMessageHtmlLink":"release: cut the v17.3.0-next.0 release"}},{"before":null,"after":"7f3cc35a163fee55a68c5ed40716ff88c84a43e9","ref":"refs/heads/changelog-cherry-pick-17.2.2","pushedAt":"2024-02-22T01:57:18.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"docs: release notes for the v17.2.2 release","shortMessageHtmlLink":"docs: release notes for the v17.2.2 release"}},{"before":null,"after":"59501f4a1fa19c6c82b901a1c4be95ed96a5ceb7","ref":"refs/heads/release-stage-17.2.2","pushedAt":"2024-02-22T01:53:54.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"release: cut the v17.2.2 release","shortMessageHtmlLink":"release: cut the v17.2.2 release"}},{"before":null,"after":"46089eb5c12a919421244a9347c81c33d38e6ba0","ref":"refs/heads/fix-feature-detection-version","pushedAt":"2024-02-14T20:21:42.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"fix(compiler-cli): fix broken version detection condition\n\nThe version detection condition for signal two-way bindings used an OR\ninstead of an AND, resulting in every `.0` patch version being considered\nas supporting two-way bindings to signals.\n\nThis commit fixes the logic and adds additional parentheses to ensure the\nmeaning of the condition is more clear. Long term, we should switch to\nsemver version parsing instead.","shortMessageHtmlLink":"fix(compiler-cli): fix broken version detection condition"}},{"before":null,"after":"3b5abb27e085920751c8c878e2263b3b5c85301a","ref":"refs/heads/pre-query-circular-deps","pushedAt":"2024-02-05T17:13:46.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"refactor(core): clean up circular dependencies","shortMessageHtmlLink":"refactor(core): clean up circular dependencies"}},{"before":null,"after":"8c63e851d31a35bdfb5590fac74fb2f276fdee45","ref":"refs/heads/release-stage-17.2.0-next.0","pushedAt":"2024-01-24T20:54:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"release: cut the v17.2.0-next.0 release","shortMessageHtmlLink":"release: cut the v17.2.0-next.0 release"}},{"before":null,"after":"83484cbc1717626ddd4baeb825cef34bfcfb58d8","ref":"refs/heads/release-stage-17.1.0-next.4","pushedAt":"2023-12-14T01:12:45.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"release: cut the v17.1.0-next.4 release","shortMessageHtmlLink":"release: cut the v17.1.0-next.4 release"}},{"before":null,"after":"ebd2bdf5e25fd9ed9e49c24041cbd6a43d07cafc","ref":"refs/heads/changelog-cherry-pick-17.0.7","pushedAt":"2023-12-14T00:38:04.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"docs: release notes for the v17.0.7 release","shortMessageHtmlLink":"docs: release notes for the v17.0.7 release"}},{"before":null,"after":"798f95566dca5cf6112a764fe820ca7e4a54c9c4","ref":"refs/heads/release-stage-17.0.7","pushedAt":"2023-12-14T00:34:03.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"release: cut the v17.0.7 release","shortMessageHtmlLink":"release: cut the v17.0.7 release"}},{"before":null,"after":"3edad939da4fed55647eb44d52765409ad0f50a2","ref":"refs/heads/revert-babel-change","pushedAt":"2023-12-07T21:19:56.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"Revert \"refactor: reduce direct babel dependencies (#53374)\"\n\nThis reverts commit 3b12c59696ada076094847481c1a87efd23a50d2.","shortMessageHtmlLink":"Revert \"refactor: reduce direct babel dependencies (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2027193800\" data-permission-text=\"Title is private\" data-url=\"https://github.com/angular/angular/issues/53374\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/angular/angular/pull/53374/hovercard\" href=\"https://github.com/angular/angular/pull/53374\">angular#53374</a>)\""}},{"before":null,"after":"1aeec7c1ffb491e062553af2729d7c0dd4ae29f6","ref":"refs/heads/revert-error-link","pushedAt":"2023-12-06T15:13:41.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"Revert \"refactor(core): output an error guide link in prod mode (#53324)\"\n\nThis reverts commit f245aba782fda0ffdb5d2e9d81310956d11b57a4.\n\nReason: breaks g3","shortMessageHtmlLink":"Revert \"refactor(core): output an error guide link in prod mode (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2022158384\" data-permission-text=\"Title is private\" data-url=\"https://github.com/angular/angular/issues/53324\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/angular/angular/pull/53324/hovercard\" href=\"https://github.com/angular/angular/pull/53324\">angu…</a>"}},{"before":null,"after":"933365b0dafb2f304cd4c49a43ec140eac708147","ref":"refs/heads/zoneless/prototype/mk-i","pushedAt":"2023-11-15T10:21:26.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"alxhub","name":"Alex Rickabaugh","path":"/alxhub","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4175141?s=80&v=4"},"commit":{"message":"wip: experimenting with zoneless change detection scheduling\n\nThis experiment is designed to explore zoneless change detection and the\nintegration with the rendering engine. We can use it to test hypotheses\nabout how applications will behave when run zoneless, and uncover pain\npoints that might need mitigation.\n\nCurrent known challenges:\n * `ApplicationRef.isStable` is obviously useless\n * SSR won't work (depends on the above)\n * `fakeAsync` testing is obviously broken & testing in general will require\n   significant fixing\n * Dynamically inserting views outside of CD was broken, and is hacked to\n   work. Note this is also broken in the OnPush model with zones.","shortMessageHtmlLink":"wip: experimenting with zoneless change detection scheduling"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAETQRN0gA","startCursor":null,"endCursor":null}},"title":"Activity · alxhub/angular"}