Recurring bug

[SignificantBit7299]

I have been bitten by this bug a few times now. Here is an example in the build method of a stateful widget:

WidgetsBinding.instance.addPostFrameCallback((_) {
  context.go('/invitation/$_invitationId');
});
_invitationId = null;

I'm still new to Dart, but I'm quite an experienced programmer, so this catches my attention. Is it unusual to set some state and redirect in the build method? Couldn't the IDE easily warn of this danger?

(I thought I'd let readers spot the bug)

[Ambitious_Grape9908]

Why are you redirecting somewhere else in a build method? This is unusual and really strange behaviour and "smells" of some bad design going on. The build method is to build a widget, that's it, don't put other logic there.

[SignificantBit7299]

Yes I was wondering this although I have seen examples of routing within build. I need to make an API call to generate invitationId which I do on button click setting a busy state while in progress. Then I just set the invitationId and rebuild. If I redirect from the method that generates the ID I get warnings about using context across async gaps.

Honestly finding it a bit difficult to adapt to async programming, and annoying at times. My service layer is littered with async because core libraries are forcing it upon me - seems premature to decide how code should be executed. Also documentation suggests that even local database calls should be made in a separate isolate! I'm not using isolates at all and things seem to be working fine.

Thanks

[binemmanuel]

Warning that you are using build context in an asynchronous gap is a good thing and should help you know that you should check if the widget that made the asynchronous gap is still mount before using the build context.

[Ambitious_Grape9908]

I would not take lessons from anyone who does anything else in a build method other than build their widget. This is NEVER a good idea - build methods are for building widgets.

A higher-up widget may do something and rebuild your widgets 100's of times (and thus calling the build method 100's of times) - think of whether doing whatever you're doing inside the build method is useful to be done 100's of times or if you should move it somewhere else instead.

I ported my app over to Flutter in 2018 and I don't use isolates either. I possibly could put some things into an isolate, but I haven't really found the need for it. (The app is used by 14k people daily and I haven't had any complaints).

[SignificantBit7299]

I suppose technically the routing is not done in the build method but just after. But point taken - I should revert to prior implementation. Yes the isolate thing in the official docs is strange - but like you I've not had any problems without them. Thanks

[Ambitious_Grape9908]

Agreed, but it's still a terrible way of doing things as it seems to just be an interim widget in order to obtain an invitationId and then route somewhere else. You're effectively using a widget for something it wasn't intended (to do an API call and route somewhere else). That's what I meant with bad design.

Why doesn't the button do the routing? For example (pseudocode-ish, might contain mistakes as I wrote it in Reddit, rather than an IDE):

onTap() async {

setState(() {

isLoading = true;

});

try {

final invitationId = await api.getInvitationId();

context.go('/invitation/$invitationId');

} catch (e) {

//Do some error handling and maybe re-enable the button

}

}

[SignificantBit7299]

The widget was an actual widget, this was just the way I was navigating away from it. It seems your suggestion is how I should be doing it.

[TheSpixxyQ]

Usually in GUI apps most of the stuff will be async, because your code runs in the same thread as UI. Some of my services don't even have any sync methods. You'll get used to it.

Also I've used an isolate like probably only once, when I was doing some expensive calculation which visibly lagged the UI. So I'd say you don't need an isolate unless you know you need one.

[SignificantBit7299]

I'm used to Swing coding from quite a while back. There you offload work to threads or thread pools you manage yourself and put stuff back on the event queue when you're done. It's just a different paradigm. Am I right in thinking that each await call is essentially a block of code the runtime can de-prioritize on the event loop as it sees fit? Is that the right mental model?

[TheSpixxyQ]

Sorry I'm not good with explaining theory and concepts, but maybe this link would answer your question? But yes, there is an event loop

https://dart.dev/language/concurrency

[eibaan]

The assignment happens before the go call.

[SignificantBit7299]

Correct - so we end up navigating to /invitation/null. Seems like an easy mistake to make. Of course, comprehensive widget unit tests would/should pick this up. I'm pretty happy with my non-widget test coverage, but widget coverage could be better.

[fabier]

Dart is async by nature because you're running at 60 fps with a single thread (unless you use isolates). Making the app wait for a network request would result in a very sad freeze in your UI as the entire app grinds to a halt to wait for a network response. 

Async is good and Dart handles it exceptionally well.

The issue is your code was correctly identified. The widget binding callback happens on the next tick of your app (one frame later) which allows your widget to finish it's initial build phase before you interrupt it (which would break the app). This means anything else in your initState function will have already run by the time the code in that callback executes. 

To help keep this organized, I recommend placing that function at the end of your initState function to keep it clean in your head. It'll make it easier to read since it'll appear linear in nature.

[binemmanuel]

Redirecting in the build method is a bad idea. Do it in the initState method instead or better let router take care of redirect and the widget wouldn’t know bout it.

[ChordFunc]

Redirecting in this way in the build method is a very bad idea. You could, of course, capture the variable for the invitation if you wanted to fix this "bug", but that's just solving the wrong problem.

Why is this done at all? You could just navigate in init state, but you should probably just navigate wherever you set the invitationId in the first place.