While this is good, it's not possible in Vanilla JS where you can't use enums or types. A simple idiomatic way to do this is to append .finally{isLoading = false} to the async block.
The code you describe will still result in the bug described in the article. The most sensible way to do this (resulting in the most predictable program with the fewest LOC) is with an enum.
"Good boolean" practise is clearly the way to go. But curiously, is setting isLoading=false in .finally() not guarantee that there can't be a loading and complete state at the same time, which is what the described bug is about?
Sure, you can of course fix the bug by adding more lines of code. But why choose an approach which forces you write defensive code to prevent impossible states?
It seems you do not get my point. The case you made with good booleans, as I said, is the way to go. I am not arguing that. I am only trying to understand the statement you made with The code you describe will still result in the bug described in the article. Assuming good boolean is not to be used for whatever reason, according to that statement, setting isLoading=false in .finally() will still cause bug. I do not think so
No - your approach would cause a different bug - you'd need to set isComplete to false at the start to fully ensure that the states were not mutual. As well as doing a similar thing for the errors. I think we both agree on the main point of the article.
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.
While this is good, it's not possible in Vanilla JS where you can't use enums or types. A simple idiomatic way to do this is to append
.finally{isLoading = false}to the async block.Added as an addendum.
The code you describe will still result in the bug described in the article. The most sensible way to do this (resulting in the most predictable program with the fewest LOC) is with an enum.
"Good boolean" practise is clearly the way to go. But curiously, is setting
isLoading=falsein.finally()not guarantee that there can't be aloadingandcompletestate at the same time, which is what the described bug is about?Sure, you can of course fix the bug by adding more lines of code. But why choose an approach which forces you write defensive code to prevent impossible states?
It seems you do not get my point. The case you made with good booleans, as I said, is the way to go. I am not arguing that. I am only trying to understand the statement you made with
The code you describe will still result in the bug described in the article. Assuming good boolean is not to be used for whatever reason, according to that statement, settingisLoading=falsein.finally()will still cause bug. I do not think soNo - your approach would cause a different bug - you'd need to set
isCompletetofalseat the start to fully ensure that the states were not mutual. As well as doing a similar thing for the errors. I think we both agree on the main point of the article.