I’m currently working with Flutter/Dart and enjoying the rapid development capabilities it offers, especially with hot reload. However, I’ve noticed that when I’m debugging and hit a breakpoint, I can’t change the value of a variable and continue execution – a feature I’ve used in other environments like C# (Visual Studio) or Java (Eclipse/IntelliJ), commonly called “Edit and Continue”.
This makes it harder to test certain code changes on the fly while investigating issues.
Why doesn’t Flutter/Dart support “Edit and Continue” or variable modification during debugging?
Is this limitation due to Dart VM’s JIT or the way Flutter manages code execution?
Are there any plans or workarounds to bring similar functionality to Flutter in the future?
More importantly: Why can’t we just execute directly to a specific widget or state? Often, during debugging, I don’t want to go through the entire flow (e.g., navigating through multiple screens) just to reach the point where the widget or state I care about is active. It would be so useful if we could “jump” directly to a certain widget or flow state for testing and debugging, without having to recreate the exact navigation flow from the beginning.
Would love to hear from the community about any insights, technical limitations, or potential features coming down the line.
When debugging a screen deep in the app, I may have to navigate through multiple screens and initialize complex state (like auth, user data, or specific deep-link conditions). Reproducing that state manually every time slows down debugging.
If I could jump directly into the relevant widget or state (like with a dynamic state injection or snapshot restore), I could focus on fixing the issue without repeating steps.
“Changing the code” might mean adding artificial entry points, mocking data, or inserting test code—essentially working around the real issue rather than inspecting it in its true context.
A feature like “Edit and Continue” or a way to jump directly into a widget/state would speed up my development.
No. Dart doesn’t support Edit’n’Continue (and, yes, the guy don’t have a clue what EnC is. It’s NOT hot reload, ffs!)
Not every C# project can have Edit’n’Continue (if I remember correctly, ASP.net is such an example). But, then again, I don’t use .net for almost 6 years now. Hasura cover all my needs
You have to understand that C# is a mutable language, while Dart is recommended to not be mutable. Even Flutter has side effects for mutable widgets (you can clearly see one widget rebuilding with its parent when you don’t use a const constructor and just by changing that, the widget stops rebuilding itself every single time (because the framework KNOWS it didn’t changed)).
With 2 in mind, mutability in Dart is kinda of a bad practice. I play around with Flutter for 6 years now, dozens of projects, hundreds of thousands of lines of code, I can count on one hand how many times I needed a var instead of a final. So, why (the team would) bother changing the memory of a language that has immutability as a (nice) functionality?
It probably has less to do with immutability which I find highly overvalued bit more with the way how a dart isolate runs inside some other OS process space like iOS or Android by maybe @mraleph can answer what the reason is. I missed that feature too
There are several different questions here, I will try to answer them separately:
Editing variable values, while paused on breakpoint. This is simply not implemented, see issue 55423. The main reason it is not implemented is that it requires some complexity in the expression compiler and JIT compiler - and it did not feel[1] like a very in demand feature, if you feel like it is important then you should leave a comment on the issue. The main complexity is around how to express writing back into the activation frame - especially if it is optimized.
Editing the code of the active function, while paused on breakpoint, the resuming and modified code runs[2]. Again, this is just not implemented. At some point we started working on this (many-many years ago) but then stopped. There is support for rewinding frames (e.g. you can restart the frame), but it is unclear how useful that is and how much that is actually used. Rewinding was not fully implemented either (e.g. I think due to some latent bugs in the implementation we don’t allow rewinding the top frame)
Entering specific state: Getting to a specific state (e.g. screen or widget) requires creating appropriate program state in memory. Debugger can’t just magically create it - code needs to run with correct inputs to get to that state. I guess in some situations it is possible to directly navigate to specific screen using the state restoration machinery, but this is not wired in the debugging workflows. Possibly a good feature request? But fundamentally it requires an ability to enter the right state simply by having route path plus a bit of data.
So this is not a decision made based on some immutability is great philosophy. It is just very non-trivial to implement. ↩︎
Hot reload does not apply changes to activation frames on the stack - only calls which occur after the reload see new code. ↩︎
Might be useful if the current state can be saved and then restored with code changes. So that the scene/situation can be reached without having to navigate to or do the preceding steps that get you to that state
Using contents of this forum for the purposes of training proprietary AI models is forbidden. Only if your AI model is free & open source, go ahead and scrape. Flutter and the related logo are trademarks of Google LLC. We are not endorsed by or affiliated with Google LLC.
