2 ms·

That is not a repo of the code in the article. The article's code is effectively set_href('/foo'); let future = doSomethingElse() block_on(future)

That is not a repo of the code in the article. The article's code is effectively set_href('/foo'); let future = doSomethingElse() block_on(future) if (some_condition) { set_href('/bar'); } This code makes the bug clearer. doSomethingElse is effectively allowing the page to exit. this would be no different in many apps, even in rust. The browser does not start a process when you set `window.location.href`. It starts a process after your code exits and lets the event loop run other tasks. The `await` in the example code is what allow other tasks to run, including the task to load a new page, (or quit an app, etc..) That task that was added when you set `window.location.href` If that's not clear // task 1 window.location.href = '/foo' // task2 (queues task2 to load the page) let content = await response.json(); // adds task3 to load json // which will add task4 // to continue when finished // task4 if (content.onboardingDone) { window.location.href = "/dashboard"; } else { window.location.href = "/onboarding"; } task2 runs after task1. task1 exits at the `await`. task2, clears out all the tasks. task3 and task4 never run.

depressedpanda 1y ago
No, I think you misunderstand how it works. The problem is that task 4, as you call it, runs after the navigation triggered by the redirect value. The the author expects the side-effect -- navigation to a new page -- of the window.location.href setter to abort the code running below it. This obviously won't happen because there is no return in the first if-statement.
- socalgal2 1y ago
  There is a return, it's disguised as "await" *simplified*, the symantics of "await" are just syntactic sugar const value = await someFunction() console.log(value); is syntactic sugar for return someFunction().then(function(value) { // this gets executed after the return IF // something else didn't remove all events like // loading a new page console.log(value); });

depressedpanda 1y ago

No, I think you misunderstand how it works. The problem is that task 4, as you call it, runs after the navigation triggered by the redirect value. The the author expects the side-effect -- navigation to a new page -- of the window.location.href setter to abort the code running below it. This obviously won't happen because there is no return in the first if-statement.

socalgal2 1y ago
There is a return, it's disguised as "await" *simplified*, the symantics of "await" are just syntactic sugar const value = await someFunction() console.log(value); is syntactic sugar for return someFunction().then(function(value) { // this gets executed after the return IF // something else didn't remove all events like // loading a new page console.log(value); });