@jezell @HarrySild @caseycrogers @felangelov The agent is driven by a human, right? It’s done via the keyboard. Keyboard is a set of buttons and using it will always be less efficient vs using separate buttons for predefined actions at any junction in the algorithm. If there is no algorithm - I doubt the utility of the app.

@SuprDeclarative @dart_lang I remember implementing this and it was certainly possible to track the upload progress on mobile. I believe I used the addStream method, which returns a Future, sending chunks of data with it and waiting for each to resolve before sending the next. # of chunks sent ~= progress.

@jezell @HarrySild @caseycrogers @felangelov With apps, though, the whole point is to allow humans to do a very limited, predefined, set of tasks, but efficiently.

@jezell @HarrySild @caseycrogers @felangelov The only way a shift to shift that paradigm I can think of is via direct communication with the brain, and we’re probably quite far from it at this point.

@luke_pighetti Release build would work just fine, without complaining :D

@caseycrogers @felangelov I also find it a bit paradoxical that while the team seems to be hesitant to add these methods to Flutter, they have marked Riverpod, which uses the same data observation style, a Flutter Favorite. Maybe the ideology is shifting, after all…

@caseycrogers @felangelov Yeah, I’d love the Flutter to provide the context_watch-like tracking for Listenables and Streams/Futures out of the box. But even though I love using it, none of my peers consider this to be “idiomatic” Flutter, so probably chances are quite low.

@caseycrogers @felangelov TBH, I don’t see any issues using the existing AsyncSnapshot class for representing the singular async operation’s state. Do you see any advantages in moving to a sealed class based approach for that?

@mxesen @kevmoo Doing this as well and is extremely happy. Super useful. macOS as a target is a blessing to develop with. Builds are fast, works fast, hot reload is fully supported. If not for platform specifics - that would’ve been THE way to run dev Flutter app builds for sure.

Like why do you show me the option to BUY another luggage instead of letting me choose/see the one I already bought with the ticket during the checkin? How come I should only select the cabin bag in that case?

Somehow this gives me hope that other serious issues on Flutter Web might also receive some attention soon🤞

@RobertBrunhage Navigator 2 without deep linking and web support, basically.

- Faster - Versatile - Actual code, not .gitignored mess - No unexpected under-the-hood changes due to generator versioning

@luke_pighetti Great utility! I use something similar myself sometimes.

@0xnngma @luke_pighetti There’s a .watchOnly() method for observing only a given subset of data from a large class. It would cause a rebuild only when the latest returned value != the previous one.

@luke_pighetti @aaguueeroo @RydMike BTW, there’s a super simple optimization technique applicable to context_watch for the same reason. If you notice a slow build performance on some widget tree that uses .watch(context) for a value that frequently changes but is only needed by a deeply nested widget - extract it.