refactor(compiler): some template parser refactorings #38581
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
petebacondarwin
added
area: compiler
petebacondarwin
added
the
target: major
petebacondarwin
changed the title
petebacondarwin
force-pushed
the
linker-template-line-ending-normalization
branch
from
4bb52a4
to
a5bfea1
Compare
petebacondarwin
force-pushed
the
linker-template-line-ending-normalization
branch
from
a5bfea1
to
54ccb49
Compare
petebacondarwin
force-pushed
the
linker-template-line-ending-normalization
branch
2 times, most recently
from
2ca14a1
to
8988283
Compare
JoostK
approved these changes
Aug 26, 2020
JoostK
added
the
action: cleanup
petebacondarwin
added
action: review
petebacondarwin
force-pushed
the
linker-template-line-ending-normalization
branch
2 times, most recently
from
43c0723
to
3b36af6
Compare
alxhub
approved these changes
Aug 28, 2020
Previously the lexer was responsible for deciding whether an "inline" template should also have its line-endings normalized. Now this decision is made higher up in the call stack to allow more flexibility in the parser/lexer.
Previously, the `startSourceSpan` property could be null but in reality it is always well defined - except for a legacy case in the old i18n extraction/merging code, where the typings for source-spans are already being undermined. Making this property non-null, simplifies code elsewhere in the project.
Previously, the `sourceSpan` and `startSourceSpan` were the same object, which meant that you had the following situation: ``` element = <div>some content</div> sourceSpan = <div> startSourceSpan = <div> endSourceSpan = </div> ``` This made `sourceSpan` redundant and meant that if you wanted a span for the whole element including its content and closing tag, it had to be computed. Now `sourceSpan` is separated from `startSourceSpan` resulting in: ``` element = <div>some content</div> sourceSpan = <div>some content</div> startSourceSpan = <div> endSourceSpan = </div> ```
petebacondarwin
force-pushed
the
linker-template-line-ending-normalization
branch
from
3b36af6
to
8977558
Compare
petebacondarwin
added
action: merge
atscott
pushed a commit
that referenced
this pull request
Sep 2, 2020
Previously, the `startSourceSpan` property could be null but in reality it is always well defined - except for a legacy case in the old i18n extraction/merging code, where the typings for source-spans are already being undermined. Making this property non-null, simplifies code elsewhere in the project. PR Close #38581
atscott
pushed a commit
that referenced
this pull request
Sep 2, 2020
…38581) Previously, the `sourceSpan` and `startSourceSpan` were the same object, which meant that you had the following situation: ``` element = <div>some content</div> sourceSpan = <div> startSourceSpan = <div> endSourceSpan = </div> ``` This made `sourceSpan` redundant and meant that if you wanted a span for the whole element including its content and closing tag, it had to be computed. Now `sourceSpan` is separated from `startSourceSpan` resulting in: ``` element = <div>some content</div> sourceSpan = <div>some content</div> startSourceSpan = <div> endSourceSpan = </div> ``` PR Close #38581
petebacondarwin
deleted the
linker-template-line-ending-normalization
branch
profanis
pushed a commit
to profanis/angular
that referenced
this pull request
Sep 5, 2020
…8581) Previously the lexer was responsible for deciding whether an "inline" template should also have its line-endings normalized. Now this decision is made higher up in the call stack to allow more flexibility in the parser/lexer. PR Close angular#38581
profanis
pushed a commit
to profanis/angular
that referenced
this pull request
Sep 5, 2020
Previously, the `startSourceSpan` property could be null but in reality it is always well defined - except for a legacy case in the old i18n extraction/merging code, where the typings for source-spans are already being undermined. Making this property non-null, simplifies code elsewhere in the project. PR Close angular#38581
profanis
pushed a commit
to profanis/angular
that referenced
this pull request
Sep 5, 2020
…ngular#38581) Previously, the `sourceSpan` and `startSourceSpan` were the same object, which meant that you had the following situation: ``` element = <div>some content</div> sourceSpan = <div> startSourceSpan = <div> endSourceSpan = </div> ``` This made `sourceSpan` redundant and meant that if you wanted a span for the whole element including its content and closing tag, it had to be computed. Now `sourceSpan` is separated from `startSourceSpan` resulting in: ``` element = <div>some content</div> sourceSpan = <div>some content</div> startSourceSpan = <div> endSourceSpan = </div> ``` PR Close angular#38581
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These refactorings are preparation for implementation of the new ng-linker.
See individual commits for the details.