-
Notifications
You must be signed in to change notification settings - Fork 222
Conversation
/// <remarks> | ||
/// Child content is only executed once. Successive calls to this delegate return a cached result. | ||
/// </remarks> | ||
public Func<Task<string>> GetChildContentAsync { get; } |
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.
Maybe call this GetChildContentDelegate
- we have some precedence for naming delegates it in this fashion elsewhere in Mvc.
3bafd0d
to
7f2ec08
Compare
b23aad6
to
1cd182b
Compare
Updated to address comments (still design). |
a06a1d0
to
3eae637
Compare
7f2ec08
to
871e82c
Compare
3eae637
to
0d7b0c8
Compare
Added tests. |
871e82c
to
6b94a47
Compare
6987a59
to
bfb620b
Compare
/// </summary> | ||
/// <returns>Content rendered by children.</returns> | ||
/// <remarks> | ||
/// Child content is only executed once. Successive calls to this delegate return a cached result. |
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.
currently will execute the Func
on every call. to behave as described, need a Task<string> _childContentAsync
field and
if (_childContentAsync == null)
{
_childContentAsync = _getChildContentAsync();
}
return _childContentAsync;
nit: better names might be _getChildContentAsyncFunc
and _getChildContentAsync
since the Func
itself isn't async
and just returns a Task
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.
It was a tough call, the caching logic is done indirectly in the TagHelperExecutionContext
. The reason why it's done there is because the CodeGen needs access to it and CodeGen doesn't have access to the TagHelperContext
since TagHelperContext
is 1-1 with each TagHelper
and created inside the TagHelperRunner
.
It's a rough situation but I'm open to alternatives.
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.
then <remarks/>
make no sense here. remove.
- Removed all tests and instances of ContentBehavior in preparation for moving to a non-ContentBehavior based design. - Removed ContentBehavior specific CodeGeneration. #221
…nt modes. - Added PreContent, PostContent and ContentSet properties to TagHelperOutput. - Added GeneratePreContent, GeneratePostContent and SupressOutput methods to TagHelperOutput. - Added multile ExecuteChildContentAsync and GetChildContentAsync to the rendering phase, ultimately only exposing GetChildContentAsync to a TagHelper author. - Added more knowledge of StartWritingScope and EndWritingScope to the TagHelper runtime components. This is to enable the runtime components to utilize the RazorPage's infrastructure to render a delegate to a writer and retrieve its value to ultimately expose it to the user. #221
- Added a new internal ctor for TagHelperExecutionContext since it's used in multiple tests to allow for less friction testing. #221
- Modified the CSharpTagHelperCodeRenderer to understand a single line of TagHelper rendering (instead of doing different things based on ContentBehavior). - Modified existing CodeGen output to reflect new content changes. #221
6b94a47
to
a86b0dc
Compare
bfb620b
to
80437f6
Compare
Updated |
Closing and re-opening against dev. |
Removed ContentBehavior
Re-design TagHelperOutput and runtime dependencies to allow all content modes.
Modify tests to allow new content mode design for runtime components.
Added CodeGen for TagHelper content mode redesign.
Tag Helpers: Redesign of Tag Helpers content mode #221
_Note:_ Will add tests once design is good.
/cc @dougbu @pranavkm