First of all, thanks for the article. I really enjoyed it, but something is bugging me, though.
When you say that "unrelated code shouldn't wait...", I think that there is something we're not addressing here, which is:
Unrelated code shouldn't be in the same function.
My approach on that would be:
1 - Split each block of unrelated code into its own async function. That will keep scope smaller and easy to keep track of what is happening at that moment.
2 - The main function would end up being a point where each step (each block of unrelated code) of the process are invoked in a meaningful order.
Of course, but we must take into account use-cases where our code is running inside a hook for example (mounted, created etc.), or when dealing with legacy code.
The right thing to do would be refactoring it to fit what you mentioned, but we don't always have that option.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
First of all, thanks for the article. I really enjoyed it, but something is bugging me, though.
When you say that "unrelated code shouldn't wait...", I think that there is something we're not addressing here, which is:
Unrelated code shouldn't be in the same function.
My approach on that would be:
1 - Split each block of unrelated code into its own async function. That will keep scope smaller and easy to keep track of what is happening at that moment.
2 - The main function would end up being a point where each step (each block of unrelated code) of the process are invoked in a meaningful order.
Of course, but we must take into account use-cases where our code is running inside a hook for example (mounted, created etc.), or when dealing with legacy code.
The right thing to do would be refactoring it to fit what you mentioned, but we don't always have that option.