Kleyguerth encountered a perplexing bug where a _hasPicked flag unexpectedly turned on. This issue stemmed from a recent, massive commit with a vague comment. The core problem involved the way TypeScript handles properties that can also be functions with getters and setters. Initially, checkAndPick was a private getter that simply returned the value of _hasPicked. Later, it was modified to return this._hasPicked || (this._hasPicked = true);. This version mutated _hasPicked to true if it was false and always returned true. While this was considered bad practice due to state mutation in a getter, it functioned as expected. The situation worsened when the code was further changed to return this._hasPicked || !(this._hasPicked = true);. This version set _hasPicked to true but returned false, causing widespread issues. The fundamental flaw lies in using property accessors for state mutation, which should be reserved for setters. Complex or even simple logic should not reside within property accessors.
_hasPickedflag unexpectedly turned on. This issue stemmed from a recent, massive commit with a vague comment. The core problem involved the way TypeScript handles properties that can also be functions with getters and setters. Initially,checkAndPickwas a private getter that simply returned the value of_hasPicked. Later, it was modified toreturn this._hasPicked || (this._hasPicked = true);. This version mutated_hasPickedto true if it was false and always returned true. While this was considered bad practice due to state mutation in a getter, it functioned as expected. The situation worsened when the code was further changed toreturn this._hasPicked || !(this._hasPicked = true);. This version set_hasPickedto true but returned false, causing widespread issues. The fundamental flaw lies in using property accessors for state mutation, which should be reserved for setters. Complex or even simple logic should not reside within property accessors.