New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Register reload sources call and make 'r' restart for web #39950
Conversation
Codecov Report
@@ Coverage Diff @@
## master #39950 +/- ##
==========================================
- Coverage 57.56% 57.24% -0.32%
==========================================
Files 194 194
Lines 18730 18728 -2
==========================================
- Hits 10782 10721 -61
- Misses 7948 8007 +59
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixes #39848?
I have some reservations about doing this if the behaviour is the same as Hot Restart. By doing this the editor doesn't know that Hot Reload isn't available and will show the user two options (Hot Restart and Hot Reload) that behave the same, and be confusing. I think understanding the difference between Hot Reload and Hot restart is already a little confusing to new users, and having a Hot Restart that doesn't do all the things we usually say it does will only add to that. In VS Code we have a setting to "Hot Restart on Save if Hot Reload is not available", but it's opt-in by default (because I thought it might be confusing to take you to a difference place due to not being stateful). If we want this behaviour we could change that without introducing confusion of having two buttons that do the same. Giving the editor a fake picture of capabilities makes it difficult to give the user the more appropriate UI. That said, if the behaviour is different - for ex Devon mentioned maybe navigating back to the route from the address bar for hot reload, then I think that would be much less confusing. |
I think we should clearly document somewhere (cc @sfshaza2) that the behavior for the flutter web workflow for reload and restart are currently the same. Also, that reload-for-flutter-web is currently not stateful. I believe that reload (and restart) will soon preserve the route (cc @mdebbar). That will give reload stateful-like behavior. I think it would be valuable to then have the behavior of restart changed o not preserve the route. I'm not sure exactly where the implementation change would gave to happen for that (cc @yjbanov, @jonahwilliams, @mdebbar). |
As far as I know, hot restart preserving the route is mostly accidental. To implement a non route preserving reload, we might register a different service extension in the web engine (reload sources?) that explicitly cleared the browser url |
But I do think it's useful behavior - it's a nice UX. cc @vsmenon
I think that we look for a service extension named |
Yes, we would probably switch the behavior around so that hotRestart was reloadSources + clear browser state |
This doesn't have to be our permanent solution, but it's good enough for now. It is useful for iterating on a web-app despite different semantics, and it doesn't require that we change our tool protocols. |
I'm not sure about IntelliJ, but VS code already had support for hot-restart-on-save, so this change doesn't enable anything new - but could add confusion to something that's already confusing (when can I reload and when do I need to restart?). That said - in my branch I think I may have already hidden the Hot Reload button if |
IntelliJ didn't have a setting for that - we would just not reload-on-save if the device didn't report as supporting reload. I think the issue with a setting for restart-on-save is that we want most people (and new users especially) on the happy path workflow. If we have a setting they have to enable to get that, most users won't be aware of the setting and won't be using that workflow. |
It doesn't need to be a setting - or it could be enabled by default. I had it opt-in because I wasn't sure if auto-refreshing the page on-save would be unexpected as a default experience, but if the consensus is that that's ok, it could be the default. That said, my concern was mostly around if it shipped to stable like this - while it's only one |
This is correct. It's because the url state is preserved by the browser. If we want to fully clear the url state on hot restart, that should be doable. We already do a bunch of DOM clean up on hot restart. But as @yjbanov pointed out, this behavior is useful for iteration, especially that there's no hot reload on web. |
Flutter is now registering a `reloadSources` and supports hot reload (even though behaviour is currently same as hot restart). flutter/flutter#39950
Flutter is now registering a `reloadSources` and supports hot reload (even though behaviour is currently same as hot restart). flutter/flutter#39950
Flutter is now registering a `reloadSources` and supports hot reload (even though behaviour is currently same as hot restart). flutter/flutter#39950
Flutter is now registering a `reloadSources` and supports hot reload (even though behaviour is currently same as hot restart). flutter/flutter#39950
Flutter is now registering a `reloadSources` and supports hot reload (even though behaviour is currently same as hot restart). flutter/flutter#39950
Description
This allows 'r' to hot restart web applications, and enables the behavior in vs code and intelllij
Fixes #39848
cc @devoncarew @DanTup