3 ms·
Objection your honor ;) A 'setter' should never ever cause an action to be triggered, and especially not immediately inside the setter. At the least change th
by flohofwoe 1y ago
Objection your honor ;)
A 'setter' should never ever cause an action to be triggered, and especially not immediately inside the setter.
At the least change the naming, like `navigate_to(href)`.
But in the browser environment it's also perfectly clear why it is not happening immediately, your entire JS code is essentially just a callback which serves the browser event loop and tells it what to do next. A function which never returns to the caller doesn't fit into the overall picture.
- johnfn 1y agoThat’s a good point. I actually modified my comment because I assumed everyone would take for granted that no work should be done in a setter :) > A function which never returns to the caller doesn't fit into the overall picture. Hmm, not sure about this. On the node side, you can process.exit() out of a callback. If setting href worked like that, I think it would be less confusing.
- mcherm 1y ago> If setting href worked like that, I think it would be less confusing. How do you imagine this would interact with try-finally being used to clean up resources, release locks, close files, and so forth?
- fleabitdev 1y agotry-finally is leaky in JavaScript, in any case. If your `try` block contains an `await` point, its finaliser may never run. The browser also has the right to stop running your tab’s process partway through a JavaScript callback without running any finalisers (for example, because the computer running the browser has been struck by lightning). For this reason, try-finally is at best a tool for enforcing local invariants in your code. When a function like process.exit() completely retires the current JavaScript environment, there’s no harm in skipping `finally` blocks.