fix(build): keep web apps on path routing through boot (no /#/, deep links survive)#6639
Merged
Merged
Conversation
The build template called usePathUrlStrategy() from prepareApp(), which runs after the boot UI mounts. By then Flutter's web routing had already initialized under the default hash strategy, so path-routed web apps got /#/... URLs. Move the strategy selection to the first statement in main(), before FletDeepLinkingBootstrap.install() (which calls ensureInitialized) and any runApp() — matching the before-boot ordering already used in client/lib/main.dart. Necessary for path routing but not sufficient for cold-start deep links; see the follow-up boot-overlay fix.
… the browser The boot overlay wrapped the boot screen in MaterialApp(home: ...). A MaterialApp with `home` builds its Navigator with reportsRouteUpdateToEngine: true, so on web it pushes the home route '/' to the browser URL the moment it mounts — during boot, before FletApp's real router reads the location. A cold-start deep link like /gallery or /apps/<id> was therefore overwritten to '/'. Verified with a headless-Chromium probe: pre-fix the URL reset /gallery -> / ~1.7s after 'Flutter app loaded' (before the Python worker even ran); post-fix /gallery holds. Render the boot screen via `builder:` instead of `home:`. With no home/routes/onGenerateRoute, WidgetsApp creates no Navigator (per its own docs) and reports nothing to the engine, so the deep link survives until the app's router takes over. The overlay never navigates, so it needs no Navigator. Regression from the 0.86 boot-screen rework (#6616); 0.85.3 rendered a bare SizedBox during boot, which reported nothing.
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Deploying flet-website-v2 with
|
| Latest commit: |
44476cf
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://0b67b4c4.flet-website-v2.pages.dev |
| Branch Preview URL: | https://fix-web-path-url-strategy-be.flet-website-v2.pages.dev |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Fixes two web-routing regressions in the
flet build webboot template introduced by the 0.86 boot-screen rework (#6616). Both worked in 0.85.3. Symptoms in a path-routed web app:/#/fragment (e.g./#/apps/<id>) instead of clean path URLs./— opening/refreshing/galleryor/apps/<id>bounced to the app root.Root causes
1. URL strategy applied too late.
usePathUrlStrategy()was called fromprepareApp(), which runs after the boot UI mounts (BootHost._boot/ theFLET_TESTFutureBuilder). By then Flutter's web routing had already initialized under the default hash strategy. → moved the strategy selection to the first statement inmain(), beforeFletDeepLinkingBootstrap.install()(which callsensureInitialized()) and anyrunApp(). Matches the before-boot ordering already used inclient/lib/main.dart.usePathUrlStrategy()only setsui_web.urlStrategy, so it's safe beforeensureInitialized().2. Boot-screen
MaterialAppclobbered the deep link. The boot overlay wrapped the boot screen inMaterialApp(home: …). AMaterialAppwithhomebuilds itsNavigatorwithreportsRouteUpdateToEngine: true, so on web it pushes the home route/to the browser URL the moment it mounts — during boot, beforeFletApp's real router reads the location. → render the boot screen viabuilder:instead ofhome:. With nohome/routes/onGenerateRoute,WidgetsAppcreates noNavigator(per its own docs) and reports nothing to the engine, so the deep link survives. The overlay never navigates, so it needs no Navigator. In 0.85.3 the boot phase rendered a bareSizedBox, which reported nothing.Both fixes are required: (1) restores path routing; (2) preserves cold-start deep links.
Verification
Built a path-routed web app and drove it with headless Chromium against a static server:
/gallery/~1.7s after "Flutter app loaded" (before the Python worker ran)/gallery/apps/testid123//Boot screen still renders and the app boots normally with
builder:.Files
sdk/python/templates/build/{{cookiecutter.out_dir}}/lib/main.dartSummary by Sourcery
Ensure web builds use path-based URL routing from application startup and prevent the boot screen from overwriting deep-link URLs.
Bug Fixes: