Scenario contact: @dariatiurina
Scenario
CacheView caches the rendered output of a section of a static SSR page. On a hit the components inside it are not instantiated at all, so their lifecycle methods do not run and whatever work they do is skipped, while the rest of the page still renders live.
Validate that a hit really skips the children rather than re-rendering identical output, that turning caching off restores live rendering while preserving the application's content and layout, and that a form POST bypasses the cache.
Minimum build
.NET 11 RC1.
Configurations to cover
CacheView only caches during static server rendering. Interactive content inside a cached section is covered by a separate scenario.
Also exercise
What to build
A page with one CacheView section containing a small child component. That child creates and displays a Guid, logs initialization, and performs a short artificial delay during its initialization. Keep this work in the child, not the containing page: the page still initializes on cache hits. Give an uncached paragraph a separate value generated on every request.
Add a second section whose caching is switched on and off by a flag, and a form on the page that posts back. Use a cache lifetime long enough for the cold, warm, and POST comparisons to complete without an entry expiring between them.
Things to try
- Load the page twice and compare the
Guids inside and outside the cached section.
- Check the console on the second load for the
OnInitialized line.
- Record cold and warm load times as observations, and use the child's initialization log to determine whether its work was skipped.
- Flip the enable flag off, reload several times, then flip it back on.
- Submit the form so the request is a
POST, then load the page again with a GET.
Expected behavior
A hit replays the cached markup without constructing the cached child components. Compare stable application content and layout between cached and live rendering, allowing the diagnostic GUIDs and deliberately cached values to differ.
Must hold
- On a second load the
Guid inside the cached section is unchanged and no OnInitialized line appears for it, while the uncached paragraph's Guid changes.
- The child's delayed initialization does not run on a cache hit, as shown by its log, regardless of the overall request duration.
- With the enable flag off, every load produces a new
Guid in that section, while its stable application content and layout remain unchanged.
- A
POST is never served from cache, and it does not replace the entry that later GET requests are served.
Evidence to capture
- The page source of a cold and a warm load, with both
Guids visible, and the console output for each.
- Cold and warm load times.
Documentation to use
Report whether the docs say which request methods are cached.
What to report
Report results using the format described in the validation testing manual. Include link to a repository with the test app.
Scenario contact: @dariatiurina
Scenario
CacheViewcaches the rendered output of a section of a static SSR page. On a hit the components inside it are not instantiated at all, so their lifecycle methods do not run and whatever work they do is skipped, while the rest of the page still renders live.Validate that a hit really skips the children rather than re-rendering identical output, that turning caching off restores live rendering while preserving the application's content and layout, and that a form POST bypasses the cache.
Minimum build
.NET 11 RC1.
Configurations to cover
CacheViewonly caches during static server rendering. Interactive content inside a cached section is covered by a separate scenario.Also exercise
What to build
A page with one
CacheViewsection containing a small child component. That child creates and displays aGuid, logs initialization, and performs a short artificial delay during its initialization. Keep this work in the child, not the containing page: the page still initializes on cache hits. Give an uncached paragraph a separate value generated on every request.Add a second section whose caching is switched on and off by a flag, and a form on the page that posts back. Use a cache lifetime long enough for the cold, warm, and POST comparisons to complete without an entry expiring between them.
Things to try
Guids inside and outside the cached section.OnInitializedline.POST, then load the page again with aGET.Expected behavior
A hit replays the cached markup without constructing the cached child components. Compare stable application content and layout between cached and live rendering, allowing the diagnostic GUIDs and deliberately cached values to differ.
Must hold
Guidinside the cached section is unchanged and noOnInitializedline appears for it, while the uncached paragraph'sGuidchanges.Guidin that section, while its stable application content and layout remain unchanged.POSTis never served from cache, and it does not replace the entry that laterGETrequests are served.Evidence to capture
Guids visible, and the console output for each.Documentation to use
Report whether the docs say which request methods are cached.
What to report
Report results using the format described in the validation testing manual. Include link to a repository with the test app.