- Expanded `ReconnectDisplay` to have a `rejected` method on it. This is the method that indicates we will never be able to reconnect to the server. By default we provide a nice little message letting users know that reconnection is no longer possible and that a refresh must take place.
- Added a logger to the `DefaultReconnectionDisplay` since part of its job is handling `Retry` clicks which indirectly call `reconnect()`. Therefore, it needed the ability to log information to the console to inform users why certain reconnects were not possible.
- Updated the `UserSpecifiedDisplay` to have a `refused` understanding. Added a new CSS class to represent the `refused` state as well.
- Updated existing tests to abide by the new `ReconnectDisplay` structure
- Added a new test to validate that the `refused``ReconnectDisplay` method results in proper behavior.
#12442
- Updated text of reconnect dialog to be more clear.
- Added user feedback to the `Retry` event button click. The current flow is `Attempting to reconnect` -> `Failed to reconnect ... [Retry]` -> Click Retry -> `Attempting to reconnect`.
- Found that in cases where the server went away entirely the reconnect event would through unexpectedly preventing the reconnect display from handling a failed reconnect. Added a separate error flow to understand when the server went away/could not start a SignalR connection to.
- Could not find a great way to add tests for this scenario.
Addresses #12442
- Relaxed the `maxRetries` and `retryIntervalMilliseconds` parameters to enable the test to complete quicker. Couldn't reproduce a failure even as the test is originally on my own Mac.
#12578
Fixes part of: #12553
We don't believe that this is needed anymore. We no longer call
OnAfterRender when you're prerendering, so the main use case of this
type is gone.
* Does not produce warnings when receiving invalid event arguments.
* Does not produce warnings when receiving an invalid event handler id.
* Does not produce warnings when receiving an ack for an unknown batch.
Fixes: #11610
I took the approach here of building this into `ComponentBase` instead
of `IHandleAfterRender` - *because* my reasoning is that `firstTime` is
an opinionated construct. There's nothing fundamental about `firstTime`
that requires tracking by the rendering, it's simply an opinion that
it's going to be useful for component authors, and reinforces a common
technique.
Feedback on this is welcome.
This is no longer shipped, because the templates installed by `dotnet
new -i` show up in VS now. Removing it now so we don't have to keep it
around in servicing forever.
* Add empty Authorization src and test projects
* Add references
* Move auth types into .Authorization project
* Move auth tests
* Fix Mvc.ViewFeatures
* Remove the reference from .Web to .Authorization, so it's truly optional
* Add empty Forms src and test projects
* Remove dependencies from Components.csproj
* Move forms sources and tests
* Reference .Forms from .Web (needed unless we also have .Forms.Web)
* Rebase on #12936
* Update reference assemblies
* CR: Add Authorization namespace
* Update ref sources
* Add missing using
* Add another missing using
* Remove IVTs from Microsoft.AspNetCore.Components.Web to .Blazor/.Server
* Eliminate RendererRegistry from .Web, as it's not needed for server-side Blazor
* Reintroduce RendererRegistry as a WebAssembly-specific concept. Refactor event data parsing.
* Remove redundant guard
* Corresponding test updates
* Update ref sources
* CR: Remove renderer ID fully from server-side Blazor code
* CR: Make WebEventData internal and shared-source
* Hub test updates
* Clean whitespace
* Update binaries
* Regenerate binaries AGAIN
* Update Jest test
* CR: Replace constructor with static parse
* Yet again attempt to refresh the .js binaries
* Fix ref assembly
* Fix test
* Adds a new API endpoint to trigger graceful disconnection from blazor clients.
* Uses the sendBeacon API on the Blazor client to trigger graceful disconnections on the client when the document gets unloaded, which happens when closing the window, navigating away from the page or refreshing the page.
* Add analzyer for pubternal
This is based on some existing code from EF. I'm having a discussion
with them right now on the best way to share this logic.
I also added support for parameters here which was missing. We might
want to make this code converge with `BannedApiAnalyzer` which is much
more thorough than this.
This is using our existing package for testing analyzers thats the
*official* way to do it in our repo. Filed #12868 to track that.
* Add S C A R Y warnings to render tree types
* PR feedback
* Improve SetParametersAsync docs
Fixes: #12820
* Clarify semantics of clashing cascading parameters
This change attempts to lock down the semantics of how cascading
parameters behave inside ParameterView.SetParameterProperties.
Previously a cascading value could be used to set a non-cascading
parameter, and vice-versa. We were just missing tests in general for how
cascading values are interpreted by the parameter set logic.
[Blazor][Fixes#11964] Limit the amount of pending renders
* Adds a default limit of 10 queued pending renders per application.
* Stops producing new render batches after that limit is hit.
* Resumes producing render batches as soon as the client acknowledges a batch.
* Revert "Revert "Improve components infrastructure (#12145)" (#12679)"
This reverts commit e2d57e2806. The improvement to components infrastructure is now reinstated with the following changes:
* Check in release JS artifacts and use them as a fallback when it's not possible to build npmproj.
* Dont' build nodejs in source build.
This change adds a fail-fast mechanism to our E2E tests based on
the browser console. This will fail super hard if an unhandled exception
is thrown.
I think it would be interesting to also see if we could do the same
thing for 404s.
The goal of this change is to make it so that the E2E tests can fail
faster (3-4s) than the 30s timeout in the case that something
catastrophic happens. As a nice side benefit you get to see the
exception message.