You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks to everyone in our community who participated in both the Control Flow and the Deferred Loading RFC. We're closing out these RFCs, so let's summarize the results of both separately:
Control Flow
tl;dr: we're closing the Control Flow RFC and starting an evaluation of a community-proposed alternative syntax.
On Angular, we've been very happy with our RFC process and the amazing engagement from our community. Our latest Control Flow RFC is no exception. It's surpassed ~600 comments, our highest ever for a single RFC. We put a lot of effort into our design for control flow in templates, and we are extremely grateful for the enthusiasm and excitement from all of you around this proposed change.
When we publish RFCs, we carefully consider everyone's input and iterate on the proposal in response to new information or ideas. In the Control Flow RFC we asked a specific question: "should we consider other syntax besides curly braces for the block tags, or besides # , / and :?" Among the many suggestions we received, one community-generated idea has emerged which is both technically feasible and also meets our goals for the aesthetics and developer experience we wanted for this feature. In our initial evaluation, we felt it has both advantages and drawbacks compared to the RFC's proposed syntax, with neither option standing out as obviously superior.
We refer to the community-proposed syntax as "@ syntax", and to the RFC's flavor as "block syntax". Here are potential renditions of if, for, and switch in @ syntax:
<header-cmp />
@if showBody {
<body-cmp />
} @else if showSummary {
<summary-cmp />
} @else {
Nothing to see here...
}
<footer-cmp />
For completeness, here's a sketch of what the new deferred loading API in @ syntax might look like:
@defer on viewport {
@main {
<!-- this block will be deferred until the placeholder is visible -->
<heavy-cmp />
}
@placeholder {
<img src="ph.png">
}
@loading {
<loading-spinner />
}
}
Early Comparison
As part of considering this alternative syntax, we're exploring the tradeoffs it makes compared to our block syntax design. This work is still ongoing, but here's a partial comparison to give you an idea of our thinking:
Advantages of @ syntax
Less line noise
Only one special character
More closely related to JS syntax
Doesn't overload { between control flow, text bindings, and ICUs
Familiar to .NET developers who use Razor templating
Similarity with Sass control flow & statement syntax
Provides a complete escape into a space for statements in templates
Could be useful for non-block statements (let? import? using?)
Hypothesis: easier for editors to understand for code folding, brace matching
Advantages of block syntax
#defer is lighter weight
No need to name the "main" content block
Familiar to developers who've used Svelte, Handlebar syntax
Doesn't overlap with @ for language decorators
Doesn't require a migration/breaking change to escape @ and } in template text nodes
Hypothesis: Similarity to HTML tags makes it easier to identify & read for existing web developers
Looks less like plain text
Fits in more with other frontend framework syntax
Next Steps
Over the next few months, we'll continue our study of the tradeoffs involved here, and engage with UX researchers to collect quantitative data on both APIs. We also plan on including a question on this choice in our upcoming developer survey. Ideally, these approaches will lead us to a consensus on the right direction for Angular, which we will then share with the community.
Deferred Loading
tl;dr: we're closing the defer RFC with an intention to move forward with the proposed design.
On Angular, we've been very happy with our RFC process and the amazing engagement from our community. The defer RFC had a very positive overall reception with plenty of engagement. We're pleased with the excitement and positivity from all of you around this proposed change.
RFC Questions
1B: Do you see the need to be able to observe when the state of a defer block changes via a signal or event?
The answer is consistently yes, and this is something we'll explore.
2B: Are there use cases where different deferred blocks in an application should use different timeouts?
The answer is consistently yes. The overall suggestion is to have a global config with the ability for local overrides.
3B: Is this list of predefined triggers sufficient to handle the majority of cases that users may have? Can you think of other common trigger types that we didn't account for in this design?
The answer is consistently yes, these are enough.
The one exception is several suggestions for a media trigger option to have things trigger based on media queries. This is a use case we'll be exploring to see if it makes sense to add to the design.
4B: Can you think of use cases where you would need to change the default trigger behavior globally for all {#defer} blocks in your application?
The answer is mixed. Some yes, some only see use cases for this in local dev and testing. No strong signal either way. With this in mind, we're not planning on changing the design for this currently, but we'll keep this use case in mind.
Additional Feedback
LCP impact
There was some concern shared about negative impact to LCP when using defer blocks, which is a legitimate concern if defer is used in some patterns. We'll want to address this in docs with strong recommendations on use cases and patterns that won't affect LCP.
Render Priority
Several comments pointed to a need / desire to have render priority or loading order as an option for the developer to use to optimize how their app performs. This is an area that needs further exploration.
Defer on data
There is a strong interest and multiple comments regarding the desire to have a clear feature for deferring on data retrieval. This is an area for future improvement.
Trigger parameters
We received some suggestions about being able to pass parameters into triggers, specifically the viewport trigger for configuration of the IntersectionObserver. This is another area for future improvement.
Testing
There was a question about testing utilities and how we'll enable testing deferred blocks. There will be a testing API and we're still designing exactly how that will look.
Public API, Strategies, and Caching
Additional feedback that we've captured and will take into consideration for future iterations.
Some want the triggers to be public api so they can be used elsewhere and have people build on top of them
Some would like to see reusable strategies, similar to router strategies, for prefetching and triggering
Suggestion to use Service Worker for caching
Next Steps
Based on this, the feedback is overwhelmingly positive. We should proceed forward with the design as intended, adjusting syntax based on the control flow results. Of the feedback, two items rise to the top: Documentation on LCP impact and some sort of ergonomic testing utility. We'll invest time into exploring these items as part of the initial scope, but otherwise, we can defer the rest but definitely take note of them for future improvements.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Thanks to everyone in our community who participated in both the Control Flow and the Deferred Loading RFC. We're closing out these RFCs, so let's summarize the results of both separately:
Control Flow
tl;dr: we're closing the Control Flow RFC and starting an evaluation of a community-proposed alternative syntax.
On Angular, we've been very happy with our RFC process and the amazing engagement from our community. Our latest Control Flow RFC is no exception. It's surpassed ~600 comments, our highest ever for a single RFC. We put a lot of effort into our design for control flow in templates, and we are extremely grateful for the enthusiasm and excitement from all of you around this proposed change.
When we publish RFCs, we carefully consider everyone's input and iterate on the proposal in response to new information or ideas. In the Control Flow RFC we asked a specific question: "should we consider other syntax besides curly braces for the block tags, or besides
#,/and:?" Among the many suggestions we received, one community-generated idea has emerged which is both technically feasible and also meets our goals for the aesthetics and developer experience we wanted for this feature. In our initial evaluation, we felt it has both advantages and drawbacks compared to the RFC's proposed syntax, with neither option standing out as obviously superior.We refer to the community-proposed syntax as "
@syntax", and to the RFC's flavor as "block syntax". Here are potential renditions ofif,for, andswitchin@syntax:For completeness, here's a sketch of what the new deferred loading API in
@syntax might look like:Early Comparison
As part of considering this alternative syntax, we're exploring the tradeoffs it makes compared to our block syntax design. This work is still ongoing, but here's a partial comparison to give you an idea of our thinking:
Advantages of
@syntax{between control flow, text bindings, and ICUslet?import?using?)Advantages of block syntax
#deferis lighter weight@for language decorators@and}in template text nodesNext Steps
Over the next few months, we'll continue our study of the tradeoffs involved here, and engage with UX researchers to collect quantitative data on both APIs. We also plan on including a question on this choice in our upcoming developer survey. Ideally, these approaches will lead us to a consensus on the right direction for Angular, which we will then share with the community.
Deferred Loading
tl;dr: we're closing the defer RFC with an intention to move forward with the proposed design.
On Angular, we've been very happy with our RFC process and the amazing engagement from our community. The defer RFC had a very positive overall reception with plenty of engagement. We're pleased with the excitement and positivity from all of you around this proposed change.
RFC Questions
1B: Do you see the need to be able to observe when the state of a defer block changes via a signal or event?
2B: Are there use cases where different deferred blocks in an application should use different timeouts?
3B: Is this list of predefined triggers sufficient to handle the majority of cases that users may have? Can you think of other common trigger types that we didn't account for in this design?
mediatrigger option to have things trigger based on media queries. This is a use case we'll be exploring to see if it makes sense to add to the design.4B: Can you think of use cases where you would need to change the default trigger behavior globally for all {#defer} blocks in your application?
Additional Feedback
LCP impact
There was some concern shared about negative impact to LCP when using defer blocks, which is a legitimate concern if defer is used in some patterns. We'll want to address this in docs with strong recommendations on use cases and patterns that won't affect LCP.
Render Priority
Several comments pointed to a need / desire to have render priority or loading order as an option for the developer to use to optimize how their app performs. This is an area that needs further exploration.
Defer on data
There is a strong interest and multiple comments regarding the desire to have a clear feature for deferring on data retrieval. This is an area for future improvement.
Trigger parameters
We received some suggestions about being able to pass parameters into triggers, specifically the viewport trigger for configuration of the IntersectionObserver. This is another area for future improvement.
Testing
There was a question about testing utilities and how we'll enable testing deferred blocks. There will be a testing API and we're still designing exactly how that will look.
Public API, Strategies, and Caching
Additional feedback that we've captured and will take into consideration for future iterations.
Next Steps
Based on this, the feedback is overwhelmingly positive. We should proceed forward with the design as intended, adjusting syntax based on the control flow results. Of the feedback, two items rise to the top: Documentation on LCP impact and some sort of ergonomic testing utility. We'll invest time into exploring these items as part of the initial scope, but otherwise, we can defer the rest but definitely take note of them for future improvements.
Beta Was this translation helpful? Give feedback.
All reactions