This repository was archived by the owner on Feb 25, 2021. It is now read-only.
"Fixed" mode and E2E tests for <CascadingValue> #1566
Merged
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.
This is a follow-up to #1545.
It's a perf optimization that allows the framework to skip the subscription tracking and parameter snapshotting that it normally has to do when cascading parameters might change value. The intended use case is for things like "form context" or anywhere you do:
... because if the
Value
instance is constant for the lifetime of the<CascadingValue>
, we can make this really cheap.If developers fail to apply this optimization when they could, nothing bad happens. We only expect this optimization to be used by our framework components and more advanced component authors who have proactively read docs about this.
Also, E2E tests
It was convenient to chain the E2E tests for cascading parameter/value in general to this PR. As usual, the E2E tests are not meant to cover every possible combination of use cases and error scenarios (that's in the unit tests); the E2E tests are a representative sample of high-level common scenarios.