- Added the ability for users to opt into CSS `TagHelper` selectors in their required attributes by surrounding the value with `[` and `]`. Added operators `^`, `$` and `=`.
- Added tests to cover code paths used when determining CSS selectors.
#684
This change implements the new API for flattening content in Razor.
Also, some optimizations to avoid allocations on paths where we need
to encode HTML attribute values.
- aspnet/Coherence-Signed#187
- remove `<RootNamespace>` settings but maintain other unique aspects e.g. `<DnxInvisibleContent ... />`
- in a few cases, standardize on VS version `14.0` and not something more specific
- Hoist `TagHelperAttribute` creation into `private static readonly` fields to avoid allocations on every request. With the recent `TagHelperAttribute` change that made them immutable we can now pre-allocate them without worry of them being modified.
- Added two extra class configuration pieces to enable pre-allocation.
- Updated test files to showcase new pre-allocations.
#600
- Currently the `TagHelperScopeManager` creates a new `TagHelperExecutionContext` per `TagHelper` on a given page. With this change the max number of `TagHelperExecutionContext`s per page is the number of nested levels that exist.
- Added two tests validating that specific pieces of `TagHelperExecutionContext` are updated as expected.
#674
- Changed the variable used to render templates (`HelperResult`s) so they can be used inside of sections.
- Updated section test file to showcase nested scenario. Also Regenerated existing test files.
#572
- Not all `TagHelper`s have unbound HTML attributes or any attributes at all. A great example of this is MVC's input `TagHelper` which usually takes the format of `<input asp-for="..." />`. By lazily initializing we don't build extra attribute lists where not needed.
- Moved `TagHelperContext` and `TagHelperOutput` creation to CreateX methods on `TagHelperExecutionContext`.
#604
- Remove a lot of the ugly generic work done in `TagHelperAttributeList`/`ReadOnlyTagHelperAttributeList`.
- Removed error cases where we'd check on addition of `TagHelperAttribute`s that their `name` was not `null`. This was due to the pre-existing `string` indexer for `TagHelperAttributeList`. It no longer sets `TagHelperAttribute`s directly, instead it's `[key] = value` (instead of `[key] = new TagHelperAttribute(...))`.
- Updated tests to account for new immutability/string indexer format.
- Removed copy ctor from `TagHelperAttribute` since its immutability kills the value.
- Changed `ReadOnlyTagHelperAttributeList` to inherit from `ReadOnlyCollection`
#604
This change 'flattens' a TagHelperOutput when writing it out to an
HtmlTextWriter. This is a beneficial perf change because more often than
not the thing being written to is a ViewBuffer in Razor, which uses pooled
memory. This allows us to 'join' islands of pooled ViewBuffer memory back
into the main buffer instead of keeping them wrapped up in a
TagHelperOutput or TagHelperContent.
- #643 part 1
- change is viral and requires an update to `RazorPage.StartTagHelperWritingScope()`
- memoize `GetChildContentAsync()` per-encoder
- update generation tests to match and to test new behaviour
- note `HtmlEncoder`s used elsewhere e.g. in other `RazorPage` instances are unaffected
Add `NullHtmlEncoder`
Nits:
- generally clean up affected doc comments and make them more consistent
- remove unused `using`s in files I had open
Changing to IReadOnlyList since we always want to support indexing.
Replacing ToArray() with non-linq when needed, and with a static
EmptyArray when not needed.
Eliminates 50mb of list copies.
- Roslyn currently has an issue where too large of strings result in out of memory exceptions at compile time. To combat this I broke down literal strings into 1024 length pieces each resulting in their own `WriteLiteral`/`WriteLiteralTo` calls. The 1024 number corresponds directly with MVCs response string buffer.
- Added tests to validate large string rendering.
#614
- Prior to this change we'd hit the disk every time we'd create a `TagHelperDesignTimeDescriptor` to locate an assemblies XML files.
- Did not want to tie the XML cache to a static member in-case a user updates their XML information between parses. Therefore, changed `TagHelperDescriptorFactory` and `TagHelperDesignTimeDescriptorFactory` to no longer be static.
- Put the same `TagHeleprDescriptorFactory` extensibility point as we had for its counterpart `TagHelperTypeResolver` to stay consistent. This involved making `CreateDescriptors` virtual and allowing it to be provided in the `TagHelperDescriptorResolver` constructor.
#630
- Updated existing tests and added a new case to understand `@section {....` scenarios.
- Instead of trying to guess 1 character prior to EOF decided to log error on opening brace since we know its position. Updated error to account for change in location.
#625
- This allows users to write `TagHelperOutput` directly to an `IHtmlContent` accepting `TextWriter`.
- This also enables us to inspect backing fields for all of the various contents to lazily initialize them.
#358
This change significantly reduces the amount of string and List<ISymbol>
allocations that occur during compilation by changing the way
LiteralChunks are combined.
This is a low impact fix that addresses the performance issue, the design
issues that caused it still exist.
The problem here lies in what Razor fundamentally does - it parses HTML/C#
into tokens, and then combines them back into 'chunks' a representation
friendly to code generation. When presenting with a large block of static
HTML, Razor parses it into individual HTML tokens, and then tries to join
them in back into a single chunk for rendering. Due to details of Razor's
representation of chunks/tokens, the process of combining literals is too
expensive.
Mainly, what's done here is to not try to combine instances of
LiteralChunk. The process of merging them is too expensive and requires
lots of interm List<ISymbol> and string allocations.
Instead we produce a new 'chunk' ParentLiteralChunk, which doesn't do so
much up-front computing. Various pieces of the code that deal with
LiteralChunk need to be updated to deal with ParentLiteralChunk also,
which is the bulk of the changes here.
Note that we still have the potential for LOH allocations to occur during
codegen, but it's likely to occur O(1) for each large block of HTML
instead of O(N) as it did in the old code.
- Updated .cshtml files to not provide quotes for the various `TagHelper` directives.
- Updated `TagHelper` directive parsing tests. This also involved removing several tests that expected errors which no longer occur since we don't have to ensure quotes are balanced.
- Updated line mappings which significantly changed due to us no longer generating line pragmas at design time for `TagHelper` directives.
#561
John Luo
N. Taylor Mullen
Ryan Nowak
Doug Bunting
Ajay Bhargav Baaskaran
Caleb Nelton
hexelium
Kiran Challa
Pranav K
Pavel Krymets