nicht angemeldet
Rolf BHallo ebody,
wie schon Tantchen Wilhelmine sagte - check1 ist eine Variable. Wenn die für dein Script global ist, kannst du den Wert von check1 durch ein neues Objekt ersetzen und alle folgenden Zugriffe verwenden dann das neue Objekt.
Ob das gute Architektur ist? Keine Ahnung; dazu müsste man wissen, wie dein Script als Ganzes organisiert ist. Grundsätzlich sollte man nicht zu große Funktionen oder Klassen haben, eine Gliederung nach Komponenten ist sinnvoll. Ein Objekt wie check, das ggf. von vielen Komponenten gebraucht wird, könnte man beim Erzeugen dieser Komponenten an den Konstruktor übergeben ("injizieren"). Man könnte auch eine Klasse "ApplicationContext" haben, deren Eigenschaften die global benötigten Werte und Objekte bereitstellen - das kann okay sein, oder eine versteckte Form von COBOL-Programmierung (wo alle Variablen global sind).
Wenn das Objekt check an diverse Komponenten übergeben wird, so dass es mehrere Variablen gibt, die alle auf dieses Objekt zeigen, dann brauchst Du einen Mechanismus, der ein neues Spreadsheed lädt. Das würde ich dann vom Konstruktor trennen und statt dessen eine load-Methode schreiben, der man die URL übergibt, die das Spreadsheed lädt und das Ergebnis passend umbaut.
Wenn eine Variable check1 von diversen Komponenten genutzt wird, d.h. es gibt nur eine einzige Stelle, die auf das check-Objekt zeigt, dann kannst Du ein neues Objekt anlegen und die check1-Variable überschreiben. Und zwar genau dann, wenn der Lade- und Transformationsvorgang beendet sind. Auch hier empfiehlt sich eine Trennung von Konstruktor und Ladevorgang. Eine load-Methode könnte ein Promise zurückgeben, und dieses Promise erfüllst Du ("resolve"-Aufruf), sobald der fetch des JSON-Strings und dessen Transformation beendet sind. Das sind asynchrone Abläufe, die muss man sauber steuern.
Rolf
sumpsi - posui - obstruxi