|
|
|
|
|
by knuthsat
1623 days ago
|
|
Sometimes you don't want to pause (with await) and give something else the chance to execute (happens a lot in UI). When code is sloppily written you realize that at some point you can't use much of the existing code outside of async. One nice example of polluting the codebase is having async local storage. Now everything that reads from the storage needs to be annotated async and now your initialization pipeline might be insanely async. Good way to avoid it is to read the whole local storage at the beginning (having a sync interface) and then everyone just reads without await. From recent experience, I did exactly that with storage and ended up removing thousands of async annotations that were no longer necessary. Similar "mistakes" happen for other things and then at some point you are putting loading guards everywhere because your async operations are always awaiting and letting the UI update when it should not. |
|
You say async were all over the place. Either it makes sense because fundamentally, what you are doing IS asynchronous. Or it make no sense because the asynchronous nature of you calls are not important in your design (I don't see why but ok), in that case you can always break the chains by using a promise: