Kleyguerth stieß auf einen verwirrenden Fehler, bei dem ein _hasPicked-Flag unerwartet aktiviert wurde. Dieses Problem rührte von einem kürzlichen, massiven Commit mit einem vagen Kommentar her. Das Kernproblem lag in der Art und Weise, wie TypeScript Eigenschaften behandelt, die auch Funktionen mit Gettern und Settern sein können. Ursprünglich war checkAndPick ein privater Getter, der einfach den Wert von _hasPicked zurückgab. Später wurde er zu return this._hasPicked || (this._hasPicked = true); geändert. Diese Version veränderte _hasPicked zu true, wenn es false war, und gab immer true zurück. Obwohl dies aufgrund von Zustandsänderungen in einem Getter als schlechte Praxis galt, funktionierte es wie erwartet. Die Situation verschlimmerte sich, als der Code weiter zu return this._hasPicked || !(this._hasPicked = true); geändert wurde. Diese Version setzte _hasPicked auf true, gab aber false zurück, was zu weitreichenden Problemen führte. Der grundlegende Fehler liegt in der Verwendung von Property Accessors für Zustandsänderungen, die für Setter reserviert sein sollten. Komplexe oder auch einfache Logik sollte nicht innerhalb von Property Accessors liegen.
_hasPicked-Flag unerwartet aktiviert wurde. Dieses Problem rührte von einem kürzlichen, massiven Commit mit einem vagen Kommentar her. Das Kernproblem lag in der Art und Weise, wie TypeScript Eigenschaften behandelt, die auch Funktionen mit Gettern und Settern sein können. Ursprünglich warcheckAndPickein privater Getter, der einfach den Wert von_hasPickedzurückgab. Später wurde er zureturn this._hasPicked || (this._hasPicked = true);geändert. Diese Version veränderte_hasPickedzu true, wenn es false war, und gab immer true zurück. Obwohl dies aufgrund von Zustandsänderungen in einem Getter als schlechte Praxis galt, funktionierte es wie erwartet. Die Situation verschlimmerte sich, als der Code weiter zureturn this._hasPicked || !(this._hasPicked = true);geändert wurde. Diese Version setzte_hasPickedauf true, gab aber false zurück, was zu weitreichenden Problemen führte. Der grundlegende Fehler liegt in der Verwendung von Property Accessors für Zustandsänderungen, die für Setter reserviert sein sollten. Komplexe oder auch einfache Logik sollte nicht innerhalb von Property Accessors liegen.