This change updates the _Essentials_ topic with the following changes:
* Change the "Managing dynamic data" topic to "Reactivity with signals",
largely replacing the existing content to focus specifically on
signals.
* Replace the "to-do" examples with examples for building a
`UserProfile` component. I made this change because the todo-item
component had an accessibility problem: it was a list item component
that rendered an `li` into its own template. This meant that the
component's host element was in between the `ul` and the `li`, which
is invalid. The "right" way to do this would have been to use a
component with an attribute selector, but this isn't something that
fits into the _Essentials_ guide.
* Reorder some of the concepts in the components topic
* Combine "Rendering dynamic templates", "Conditionals and loops", and
"Handling user interaction" into one topic, "Dynamic interfaces with
templates". Having these as separate topics meant that there was more
preamble/scaffolding around these relatively straightforward ideas.
* Renamed the "Sharing logic" topic to "Modular design with dependency
injection". Aside from this, I have made no meaningful changes to the
DI topic; I may come back for another edit pass here, but this is not
necesary for v19.
* Add a link to the in-depth guide for each essentials topic.
* Add a new introduction to the _Essentials_ overview that explains what
this guide is and what it's trying to accomplish.
PR Close#58603
This is the first commit towards updating the NgModule guide to reflect
the fact that v19+ is standalone by default. This PR focuses on:
* Updating the overview to give an actual overview of the most
important/common uses of `NgModule`
* Add callouts recommending standalone APIs over `NgModule`
* Remove several stale docs that no longer make sense in v19+
This guide (directory) needs additional follow up work; I plan to
address the remaining content in follow-up changes.
PR Close#58606
In #57684 the standalone migration was changed so that it replaces any leftover modules with their `exports`, in an attempt to preserve more working code. These changes expand that logic to also cover tests since it's somewhat common internally to only import a component's module without having any references to the component.
Note that tests are a bit of a special case, because we don't have access to the template type checker, so instead we copy over all of the `exports` of that module.
PR Close#58627
Currently the `getPotentialImportsFor` only accepts a `ClassDeclaration` as the context for generating an import, but that's not necessary because it doesn't require any class-specific information. These changes expand it to any `Node` so that it can be used when generating imports in testing declarations.
PR Close#58627
Running `ng g @angular/core:signals` prompts for the question on which migration to run and offers 3 options (inputs, outputs, queries).
Running with `--defaults` skips the prompts, but only runs 2 of them.
This fixes it by including the `outputs` migration in the default ones.
PR Close#58635
This change updates the docs to show the signal-based APIs for inputs
and queries as the primary way to do things (and also the `output`
function).
Specifically, this means:
* Component guide
* Show `input` and `model` as the main approach, moving `@Input` lower on the same page
* Show signal-based queries as the main approach, moving the
decorator-based queries lower on the same page
* Show `output` as the main approach, moving `@Output` lower on the
same page
* Delete the separate topic for the `output` function
* Signals guide
* Delete the topics for input, model, and queries, as they are not in
the components guide.
* Move all rxjs-interop content to a new guide under "Extended
ecosystem"
I plan to further update the "Essentials" guide and the "Signals" guide
in follow-up PRs.
PR Close#58572
Fixes an edge case where a control flow node that has non-projectable nodes followed by an element node at the end would cause the entire control flow node to be project. For example if we have a projection target of `Main: <ng-content/> Slot: <ng-content select="[foo]"/>`, inserting a node of `@if (true) {Hello <span foo>world</span>}` would project the entire `Hello world` into the `[foo]` slot.
In the process of working on the issue, I also found that `@let` declarations at the root of the control flow node would prevent content projection as well.
PR Close#58607
In this commit, we clean up the event contract once hydration is complete, which removes event
listeners registered through the container manager. If we do not clean up the contract, the listeners
will remain on the `document.body`. When incremental hydration is enabled, we cannot clean up the event
contract immediately; instead, we schedule its cleanup when the app is destroyed. This is because the
event contract is required for deferred blocks, of which we are unaware, that need to be hydrated.
PR Close#58174
This moves all the helpers out of the instructions file, keeping the instructions limited to the actual instruction set. This adds files for defer block rendering functions and triggering functions, respectively.
PR Close#58598
Initially the unused imports check was implemented so that it reports one diagnostic per component with the individual unused imports being highlighted through the `relatedInformation`. This works fine when reporting errors to the command line, but vscode appears to only show `relatedInformation` when the user hovers over a diagnostic which is a sub-par experience.
These changes switch to reporting a diagnostic for each unused import instead.
PR Close#58589
This commit improves the temporary variable generation in signal
migrations, whenever references are "shared" inside property
declarations.
PR Close#58581
Currently whenever we would come across a code snippet like this, where
`maxCellsPerRow` is an input, the control flow analysis would fall apart
because the first occurence of the node points to a control flow node
that is offset-wise "after" the first occurence. This commit makes the
logic more robust.
PR Close#58581
The application builder documentation now contains information about the
`define` option and its usage as well as development server prebundling.
PR Close#58569
This cleans up the memory usage of the defer block registry and jsactionmap when a view is destroyed that contains a defer block that is not yet hydrated.
PR Close#58553
Previously we always ran Tsurge migrations with an Angular program, even
if it's a plain `ts_library` target. This has changed now, so we also
need to properly handle the case where a `ts_library` is analyzed, but
no Angular program is available.
PR Close#58541
Tsurge can run against the full Google3 depot, and will often also deal
with plain `ts_library` targets. Those shouldn't be constructed with the
Angular compiler as this could cause out of memory breakages etc. The
targets are simply not "proven" to be compatible with the Angular
compiler; so we shouldn't use them when not necessary.
PR Close#58541
