Progressively enhanced navigation #48899
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dotnet-issue-labeler
bot
added
the
area-blazor
SteveSandersonMS
force-pushed
the
stevesa/dom-merging
branch
from
9411d16 to
ef4d392
Compare
SteveSandersonMS
force-pushed
the
stevesa/progressively-enhanced-navigation
branch
from
41d8a58 to
b06b0a0
Compare
javiercn
reviewed
Jun 20, 2023
| @@ -9,7 +9,7 @@ export function synchronizeAttributes(destination: Element, source: Element) { | |||
|
|
|||
| // Optimize for the common case where all attributes are unchanged and are even still in the same order | |||
| const destAttrsLength = destAttrs.length; | |||
| if (destAttrsLength === destAttrs.length) { | |||
| if (destAttrsLength === sourceAttrs.length) { | |||
There was a problem hiding this comment.
Yes. I could backport the fix and add another test case to the earlier PR, but it didn't seem worthwhile when both of those things are going in on the same day with this PR.
There was a problem hiding this comment.
That's ok, as long as we have a test to cover it, that's good enough
javiercn
reviewed
Jun 20, 2023
| synchronizeDomContent(document, parsedHtml); | ||
| } else if ((response.status < 200 || response.status >= 300) && !initialContent) { | ||
| // For any non-success response that has no content at all, make up our own error UI | ||
| document.documentElement.innerHTML = `Error: ${response.status} ${response.statusText}`; |
There was a problem hiding this comment.
I don't think you'll actually see the redirects here.
AFAIK, fetch automatically follows the redirects.
There was a problem hiding this comment.
Yes, great point. I'll add some further test cases for redirections and make sure we're handling it sensibly (updating the history stack too).
javiercn
approved these changes
Jun 20, 2023
…plete implementation of #48763 but will be OK for preview 6.
SteveSandersonMS
force-pushed
the
stevesa/progressively-enhanced-navigation
branch
from
96553e9 to
75323b1
Compare
ghost
added this to the
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Implements #48761
This extends
blazor.web.jsso that when clicking to navigate between pages or using back/forwards, we attempt to perform the navigation via afetchrequest and updating the DOM in place.The main complexities are:
Intentional limitation for .NET 8
We are not going to support having both "progressively-enhanced nav" and "interactive router" at the same time. As soon as you add any interactive
<Router/>, we will automatically disable enhanced nav.This is because there are two important routing scenarios we need to support:
<Router/>). In this mode, the router takes over all navigation operations and expects to find some content for every URL you visit (and if not, falls back on a full-page load which may renderNotFoundContent). It doesn't make sense to navigate to content through enhanced nav because if the router doesn't know about a given URL, it's going to fall back on full-page load anyway, and by default that will then showNotFoundContent.<Router/>). In this mode there's no<Router/>so we do enhanced nav.... and in neither case does it make sense to have enhanced nav enabled while there's an interactive
<Router/>.In theory you could use both SPA and MPA routing styles in different parts of the same site, but it would be hard to set up.
<Router/>is added via enhanced nav, that router will take over and now you're in a SPA.<Router/>doesn't recognize, so it will do a full-page load. Then you need the matched endpoint to render an MPA page that does not have an interactive<Router/>(so you can't use the same rootAppcomponent if that contains the interactive router).Temporary limitations
Until #48763 and #48765 are implemented, this does not fully integrate with interactive components. As a short-term stopgap for preview 6:
The result of this is that in preview 6, things will work, but won't keep using enhanced nav if you have any interactive components and will just fall back on full-page loads (unless you have an interactive router).