earlier p sigly was used to define a paragraph element which was not clear what we want to refer changed it to paragrapg element for better understanding
Fixes#34922
PR Close#34927
Previously, the template type-checker would always construct a generic
template context type with correct bounds, even when strictTemplates was
disabled. This meant that type-checking of expressions involving that type
was stricter than View Engine.
This commit introduces a 'strictContextGenerics' flag which behaves
similarly to other 'strictTemplates' flags, and switches the inference of
generic type parameters on the component context based on the value of this
flag.
PR Close#34649
Previously, the examples in the `comparing-observables` guide were hard-coded.
This made it impossible to test them and verify they are correct.
This commit fixes this by converting them into a proper mini-app. In a
subsequent commit, tests will be added to verify that the source code
works as expected (and guard against regressions).
Fixes#31024
PR Close#34327
Previously, the examples in the `cli-builder` guide were hard-coded.
This made it impossible to test them and verify they are correct.
This commit fixes this by converting them into a proper mini-app. In a
subsequent commit, tests will be added to verify that the source code
works as expected (and guard against regressions).
Fixes#34314
PR Close#34362
Previously, some of the examples in the `lazy-loading-ngmodules` guide
were hard-coded.
This commit ensures all examples in the guide are extracted from
docregions in the corresponding example project.
PR Close#34599
The main change here was to remove the updating instructions for
version 9 and instead point to update.angular.io. This ensures
we only have one "source of truth" for update instructions.
This commit also includes updates to error message text to
keep them up-to-date with live error messages (and thus keep
them searchable).
PR Close#34498
Previously, it was required that both `fullTemplateTypeCheck` and
`strictTemplates` had to be enabled for strict mode to be enabled. This
is strange, as `strictTemplates` implies `fullTemplateTypeCheck`. This
commit makes setting the `fullTemplateTypeCheck` flag optional so that
strict mode can be enabled by just setting `strictTemplates`.
PR Close#34195
The missing-injectable migration has been updated to handle a breaking change that is
unrelated to missing ´@Injectable` decorators. Though, the breaking change will be handled
as part of this migration since we did not want to create another migration (with all the boilerplate etc.)
The guide has been already updated to reflect the new pattern the migration handles, but we
should also rename the title of the guide to something that also mentions the other pattern.
Not renaming the guide URL since it is referenced in past releases and it's safer to keep the old
URL. The important thing is to change the actual rendered title.
PR Close#34125
Since we created the migration guide for the `missing-injectable` schematic, the schematic
changed in various ways. e.g. the migration no longer migrates classes passed to `useExisting`
Additionally the migration has been expanded to handle another Ivy breaking change where
providers like `{provide: X}` will be intepreted as `{provide: X, useClass: X}`. This pattern should
be documented in the migration guide.
PR Close#33960
These apis have been deprecated in v8, so they should stick around till v10,
but since they are defunct we are removing them early so that they don't take up payload size.
PR Close#33949
link to the correct section of the HttpClientGuide:
if someone searches for CSRF (and not XSRF), she will not find the right section in the HttpClient guide
added CSRF as name of XSRF attack:
in order to make it easier to find the XSRF protection, I've added a reference to the other name "CSRF". The security guide has the same reference to XSRF/CSRF.
When I searched for this feature, I had quite some problems to find it because of this missing reference
PR Close#32933
By adding the `bash` language to the code snippet it will no
longer be auto-linked, which was causing a false positive link
to be rendered.
Fixes#33859
PR Close#33877
Reference #33259
Removes figures elements as AIO is not typically using captions or image groups where figures would be necessary or appropriate
PR Close#33748
This commit removes one of the expected Ivy changes because we have
decided to change the behavior to be more backwards-compatible.
It also adds a bug fix that is technically breaking to the list of
expected changes.
PR Close#33675
Often the types of an `@Input`'s field don't fully reflect the types of
assignable values. This can happen when an input has a getter/setter pair
where the getter always returns a narrow type, and the setter coerces a
wider value down to the narrow type.
For example, you could imagine an input of the form:
```typescript
@Input() get value(): string {
return this._value;
}
set value(v: {toString(): string}) {
this._value = v.toString();
}
```
Here, the getter always returns a `string`, but the setter accepts any value
that can be `toString()`'d, and coerces it to a string.
Unfortunately TypeScript does not actually support this syntax, and so
Angular users are forced to type their setters as narrowly as the getters,
even though at runtime the coercion works just fine.
To support these kinds of patterns (e.g. as used by Material), this commit
adds a compiler feature called "input coercion". When a binding is made to
the 'value' input of a directive like MatInput, the compiler will look for a
static field with the name ngAcceptInputType_value. If such a field is found
the type-checking expression for the input will use the static field's type
instead of the type for the @Input field,allowing for the expression of a
type conversion between the binding expression and the value being written
to the input's field.
To solve the case above, for example, MatInput might write:
```typescript
class MatInput {
// rest of the directive...
static ngAcceptInputType_value: {toString(): string};
}
```
FW-1475 #resolve
PR Close#33243
PR#28396 originally addressed an update via issue #23983 to make images more visible with a white background (implementation of gray "lightbox").
This PR implements those styles defined in PR#28396.
PR Close#33259