-
Notifications
You must be signed in to change notification settings - Fork 25k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial implementation of Standalone Components #44812
Conversation
d673adf
to
171c988
Compare
5d67801
to
d6ce33c
Compare
import {ComponentScopeReader} from '../../../scope'; | ||
import {ComponentScopeReader, DtsModuleScopeResolver, ExportScope, LocalModuleScopeRegistry} from '../../../scope'; | ||
|
||
import {ComponentAnalysisData} from './metadata'; | ||
|
||
|
||
export interface ScopeTemplateResult { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it makes sense to have two separate interfaces at this point? ngModule
is always null
for standalone components and diagnostics
are always empty for components declared in modules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would make things more complicated, honesty.
Having multiple interfaces is only useful if there's a benefit to be gained by distinguishing between them. For consumers of ScopeTemplateResult
, there is no significant benefit to be gained from understanding, for example, that diagnostics
are only present if ngModule
is not. Adding the checks required to narrow the type appropriately to collect the diagnostics
when present would be a net negative in terms of complexity.
throw createValueHasWrongTypeError( | ||
ref.getOriginForDiagnostics(expr), ref, | ||
`'imports' must be an array of components, directives, pipes, or NgModules`); | ||
} | ||
} else { | ||
throw createValueHasWrongTypeError( | ||
expr, imports, | ||
`'imports' must be an array of components, directives, pipes, or NgModules`); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These errors will mean that the language service won't give any template information for components with broken imports. Are we alright with that or should we maybe attempt to fail more gracefully and still process as much as possible? I think this is probably fine, just wanted to bring it up -- there are a number of other errors in the meta that do this as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that we should probably move away from throwing FatalDiagnosticError
. I've refactored this function to return diagnostics instead, which should allow some information to be extracted in the LS regardless of errors in imports
.
/** | ||
* Raised when a type in the `imports` of a component is a directive or pipe, but is not | ||
* standalone. | ||
*/ | ||
COMPONENT_IMPORT_NOT_STANDALONE = 2011, | ||
|
||
/** | ||
* Raised when a type in the `imports` of a component is not a directive, pipe, or NgModule. | ||
*/ | ||
COMPONENT_UNKNOWN_IMPORT = 2011, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these two shouldn't have the same code, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed!
@trumbitta check out the initial RFC #43784 I hope that helps 🙂 |
bba2b04
to
fe776a7
Compare
…ages Previously each `DecoratorHandler` in the compiler was stored in a single file in the 'annotations' package. The `ComponentDecoratorHandler` in particular was several thousand lines long. Prior to implementing the new standalone functionality for components, this commit refactors 'annotations' to split these large files into their own build targets with multiple separate files. This should make the implementation of standalone significantly cleaner.
In preparation for standalone components, this commit moves the logic which determines the potential set of components/directives/pipes in a template into a separate function. This is a simple but crucial refactoring that breaks the assumption that all template scopes come from NgModules.
This commit implements the first phase of standalone components in the Angular compiler. This mainly includes the scoping rules for standalone components (`@Component({imports})`). Significant functionality from the design is _not_ implemented by this PR, including: * imports of standalone components into NgModules. * the provider aspect of standalone components Future commits will address these issues, as we proceed with the design of this feature.
fe776a7
to
9b3d0e9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reviewed-for: public-api
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving for the new error codes in the .md
file.
reviewed-for: public-api
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reviewed-for: public-api
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks Alex! 👍
Reviewed-for: public-api
This PR was merged into the repository by commit 0072eb4. |
#44812) In preparation for standalone components, this commit moves the logic which determines the potential set of components/directives/pipes in a template into a separate function. This is a simple but crucial refactoring that breaks the assumption that all template scopes come from NgModules. PR Close #44812
…44812) This commit implements the first phase of standalone components in the Angular compiler. This mainly includes the scoping rules for standalone components (`@Component({imports})`). Significant functionality from the design is _not_ implemented by this PR, including: * imports of standalone components into NgModules. * the provider aspect of standalone components Future commits will address these issues, as we proceed with the design of this feature. PR Close #44812
const {param, index, reason} = error; | ||
let chainMessage: string|undefined = undefined; | ||
let hints: ts.DiagnosticRelatedInformation[]|undefined = undefined; | ||
switch (reason.kind) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
switch case
is bad practics. Maybe using 'strategy' approach, for exapmle:
const kindHandlers = new Map().set(ValueUnavailableKind.UNSUPPORTED, () => {
chainMessage ='Consider using the @Inject decorator to specify an injection token.';
hints = [makeRelatedInformation( reason.typeNode, 'This type is not supported as injection token.' ), ]; }).set(...).set(...);
const handler = kindHandlers.get(reason.kind);
handler && handler.call(this, option);
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
…ages (angular#44812) Previously each `DecoratorHandler` in the compiler was stored in a single file in the 'annotations' package. The `ComponentDecoratorHandler` in particular was several thousand lines long. Prior to implementing the new standalone functionality for components, this commit refactors 'annotations' to split these large files into their own build targets with multiple separate files. This should make the implementation of standalone significantly cleaner. PR Close angular#44812
angular#44812) In preparation for standalone components, this commit moves the logic which determines the potential set of components/directives/pipes in a template into a separate function. This is a simple but crucial refactoring that breaks the assumption that all template scopes come from NgModules. PR Close angular#44812
…ngular#44812) This commit implements the first phase of standalone components in the Angular compiler. This mainly includes the scoping rules for standalone components (`@Component({imports})`). Significant functionality from the design is _not_ implemented by this PR, including: * imports of standalone components into NgModules. * the provider aspect of standalone components Future commits will address these issues, as we proceed with the design of this feature. PR Close angular#44812
No description provided.