[gelöst]: Async: Verständnisproblem

[paul53]

@codierknecht sagte: Oder mixt man das so wie es halt gebraucht wird?

Ich verwende kein async / await, da ich mich an die "Callback-Hölle" gewöhnt habe.
In Blockly sieht es natürlich anders aus, denn es ist vieles auf async umgestellt.

[mcm1957]

@paul53

Callbackhölle ist nicht verboten.
Aber Adaptercode ist mit async deutlich leicht zu lesen.

Aber technisch ist beides OK und zulässig. Nur mischen sollte man nicht (bzw. es wird vom Mischen stark abgeraten)

[OliverIO]

@codierknecht

async / await ist nur eine vereinfachte schreibform für funktionen mit promises.

await darfst du also nur vor funktionen schreiben, die entweder ein promise zurückgeben oder auch ein async als prefix haben (und damit auch wieder promises zurückgeben).

bei funktionen die keine promises zurückgeben, dürfte es zu fehlern oder komischen verhalten führen.

auch auf das weglassen von await vor funktionen die promises zurückgeben muss geachtet werden. wenn man keinen wert erwartet, alles gut. wenn man aber einen wert erwartet, also sowas wie let result = xyz(), dann wird das so nicht richtig funktionieren.

also aus

async function xyz() {
   // code
   let value=123;
   return value;
}

macht javascript intern das daraus

function xyz() {
   return new Promise((resolve,reject) => {
      try {
         // code
         let value=123;
         resolve(value);
      } catch (e) {
         reject(e);
      }
   }
}

bei await sieht es so aus

let result = await xyz();
console.log(result);

xyz().then(result=>{
   console.log(result);
}

[ticaki]

@codierknecht
Mit aktuellem Adapter eslint wird dir einen async Funktion die keinen await enthält als Fehler angezeigt. Das wieso hat mich da noch nicht wirklich interessiert, da der, der das Paket zusammengestellt hat, sich dabei wohl was gedacht hat.

[OliverIO]

@mcm1957 sagte in Async: Verständnisproblem:

Callbackhölle ist nicht verboten.
Aber Adaptercode ist mit async deutlich leicht zu lesen.

das kann ich bestätigen. speziell im tvprogram adapter im widget code (aber auch in anderen adaptern im adapter code)
hat es zu besser lesbaren code und weniger verschachtelungstiefe geführt.

[Codierknecht]

@mcm1957 sagte in Async: Verständnisproblem:

setState (wenn es die adapater.setState / this.setState Funktion ist) ist ASYNCHRON. Diese retourniert sofort

Es geht um Adaptercode - kein Script.

Im Adaptercode wird in einer "normalen" (nicht async) Funktion ein this.setObjectNotExists ohne await aufgerufen. Geht ja auch nicht, weil keine Async-Funktion.
Direkt im Anschluss wird setState aufgerufen.

Wartet der Code an der Ecke jetzt bis this.setObjectNotExists zurückkehrt, oder ist das auch auf die Art immer asynchron?
Das würde die Fehlermeldung has no existing object erklären, da ja dann das setState aufgerufen wird und evtl. setObjectNotExists noch gar nicht beendet wurde.

Ich komme aus einer Welt, in der Asynchronität (Multithreading) mit viel Aufwand erkauft werden muss und bin es gewohnt, dass eine aufgerufene Funktion erst von A bis Z abgearbeitet wird, bevor der Code nach dem Funktionsaufruf weitermacht.
Macht für mich an der Ecke allerdings auch Sinn, da man die Abarbeitung von Code so vorhersehen kann.
Asynchronität wird da in der Regel nur über die Message-Queue verwendet, damit z.B. MouseMove oder ButtonClick nix blockieren. Oder (mit relativ viel Aufwand) um z.B. während lang laufender Datenbanloperationen einen BusyDialog anzuzeigen.

Ich würde den Adaptercode vermutlich umbauen.
Alle Funktionen grundsätzlich als async deklarieren und bei jedem Funktionsaufruf mit 'nem await auf die Beendigung derselben warten. Wäre das verwerflich?

[ticaki]

@codierknecht

Wartet der Code an der Ecke jetzt bis this.setObjectNotExists zurückkehrt, oder ist das auch auf die Art immer asynchron?
Das würde die Fehlermeldung has no existing object erklären, da ja dann das setState aufgerufen wird und evtl. setObjectNotExists noch gar nicht beendet wurde.

Der läuft bis zu dem Punkt an dem er asychron wird durch. Wenn du eine Funktion ohne await als async deklarierst wird die lt. meinen Tests sychron abgearbeitet.
Einfaches Beispiel:

export async function sleep(time: number): Promise<void> {
    return new Promise(resolve => setTimeout(resolve, time));
}

Wenn du das ohne await aufrufst, geht dann Code einfach weiter, mit await wartet er time ms.

lt. Apollon sollte man auf setState() und artverwante Funktionen mit await warten, wenn du da tausende von aufrufen machst könnte das sonst zu Nebenwirkungen führen.

hab editiert

[OliverIO]

@codierknecht sagte in Async: Verständnisproblem:

setObjectNotExists

hier die funktionssignatur aus vscode

du siehst der parameter callbacl ist optional und als return type gibt es entweder Promise oder CallBackReturnType oder void

Ich interpretiere, das

• wenn du ein callback funktion angibst ist es eine callback funktion (also ohne promise/await/async) und die rückgabe des ergebnisses wird im callback behandelt oder
• ohne callback-parameter gibt die funktion ein promise zurück, also musst du auch await davor schreiben, wenn du den rückgabe wert auswerten willst oder auf das ende der abbarbeitung des befehl wartest oder
• du wertest überhaupt keinn rückgabe wert aus, dann wird die aktion einfach ausgeführt, aber willst kein ergebnis auswerten (also void)

[mcm1957]

@codierknecht said in Async: Verständnisproblem:

Im Adaptercode wird in einer "normalen" (nicht async) Funktion ein this.setObjectNotExists ohne await aufgerufen. Geht ja auch nicht, weil keine Async-Funktion.
Direkt im Anschluss wird setState aufgerufen.

Wartet der Code an der Ecke jetzt bis this.setObjectNotExists zurückkehrt, oder ist das auch auf die Art immer asynchron?
Das würde die Fehlermeldung has no existing object erklären, da ja dann das setState aufgerufen wird und evtl. setObjectNotExists noch gar nicht beendet wurde.

Wenn das so OHNE callback drinnen steht ist es fehlerhaft.

ABER es sollte auch nicht vor jedem setState ein setObjectNotExists stehen. Das ist Beschäftigungstherapie für den core aber auch eine zweite Baustelle.

Ich komme aus einer Welt, in der Asynchronität (Multithreading) mit viel Aufwand erkauft werden muss und bin es gewohnt, dass eine aufgerufene Funktion erst von A bis Z abgearbeitet wird, bevor der Code nach dem Funktionsaufruf weitermacht.

Davon musst du dich lösen. Hier läuft node / js.

Ich würde den Adaptercode vermutlich umbauen.
Alle Funktionen grundsätzlich als async deklarieren und bei jedem Funktionsaufruf mit 'nem await auf die Beendigung derselben warten. Wäre das verwerflich?

Nö - spricht mal generell nichts dagegen. Aber bitte nicht mit Callbacks mischen.

Und weil die Frage dann sicher kommt: do onXxxx können async declariert werden (async onReady... usw).

[mcm1957]

@oliverio said in Async: Verständnisproblem:

@codierknecht sagte in Async: Verständnisproblem:

setObjectNotExists

hier die funktionssignatur aus vscode

du siehst der parameter callbacl ist optional und als return type gibt es entweder Promise oder CallBackReturnType oder void

Ich interpretiere, das

• wenn du ein callback funktion angibst ist es eine callback funktion (also ohne promise/await/async) und die rückgabe des ergebnisses wird im callback behandelt oder
• ohne callback-parameter gibt die funktion ein promise zurück, also musst du auch await davor schreiben, wenn du den rückgabe wert auswerten willst oder auf das ende der abbarbeitung des befehl wartest oder
• du wertest überhaupt keinn rückgabe wert aus, dann wird die aktion einfach ausgeführt, aber willst kein ergebnis auswerten

Aber ACHTUNG:
set(Foreign)Object ist erst ab js.controller 7 gesichert async fähig. Sie Changelog des js.controllers. Soll der Adapter mit js-controller vor 7 laufen sollte man noch setObjectAsync verwenden ...

[OliverIO]

@mcm1957 sagte in Async: Verständnisproblem:

Aber ACHTUNG

es wäre natürlich schön wenn diese information dann im jsdoc stehen würde, das würde dann vscode (und die anderen IDEs) dann im infofenster auch anzeigen.
https://jsdoc.app/tags-since

[ticaki]

@oliverio

Mir hat da die installation von @iobroker/types@6.0.11 geholfen, damit ich mit 6 kompatibel bleibe.

[mcm1957]

@oliverio
Ja auch ne Möglichkeit.

Schreibs bitte im Issue von mir (https://github.com/ioBroker/ioBroker.js-controller/issues/3010) dazu was du ergänzen oder kritisieren willst. Je mehr fachlicher Input kommt desto leichter ist es für Moritz das zu erfüllen oder abzulegen (wenns eh niemand interessiert)<

Derzeit gibts leider gar keine Infos ab wann was gesichert funktioniert. Oder zumindest funktionieren sollte. Ein paar xxxAsync sind ja noch nicht umgestellt sondern nur für die Umstellung geplant (ist zumindest mein WIssensstand). ICh hab auch im Changelog des js-controllers nur die SetObject erwähnt geunden bei einer js-controller 7 Release. (Ev. brauch ich aber auch ne neue Brille)

Und das Schema zeigt ja den aktuellen Stand (js-.controller 7 ). User verwenden aber womöglich noch js-controller 3 (erst gestern im Forum ), 4 (druchaus realistisch) oder 5 (weit verbreitet und bisher nicht offiziell abgekündigt)

mcm1957 created this issue in ioBroker/ioBroker.js-controller

open [enhancement]: Dokument js.controller requirements for use of non Async functions #3010

[mcm1957]

@ticaki said in Async: Verständnisproblem:

@oliverio

Mir hat da die installation von @iobroker/types@6.0.11 geholfen, damit ich mit 6 kompatibel bleibe.

Jep klingt vernünftig
dann bitte auch js-controller > 6.0.11 in dependencies des Adapters eintragen

[OliverIO]

@ticaki sagte in Async: Verständnisproblem:

Mir hat da die installation von @iobroker/types@6.0.11 geholfen, damit ich mit 6 kompatibel bleibe.

das wäre sicherlich auch ein guter Best practise Hinweis für die developer
um zu entscheiden wie weit Rückwärtskompatibel man sein möchte.

[carsten04]

@Codierknecht Ist zwar schon 10 Jahre alt, aber wenn Du gerne mal ein Youtube-Video schaust, dann empfehle ich Dir dieses. Hier geht es grundsätzlich zum Thema Eventloop. Das muss man einmal ungefähr kapiert haben, dann sind Promises, async-Functions und Callbacks auch nicht mehr die wirklich große Hürde.
Wenn Du lieber was lesen möchtest, dann empfehle ich immer gerne modern javascript und für async/await diese Kapitel.

[OliverIO]

@codierknecht

für wirklich umfassende Aufarbeitung von javascript von Anfänger bis Experten level
finde ich diese Seite hervorragend

https://javascript.info/

[ticaki]

@mcm1957 sagte in Async: Verständnisproblem:

@ticaki said in Async: Verständnisproblem:

@oliverio

Mir hat da die installation von @iobroker/types@6.0.11 geholfen, damit ich mit 6 kompatibel bleibe.

Jep klingt vernünftig
dann bitte auch js-controller > 6.0.11 in dependencies des Adapters eintragen

Wegen der Anmerkung das 5 noch immer aktiv ist, werde ich erstmal schauen wie weit ich ohne das ich mich umgewöhnen muß zurück kann.

[Codierknecht]

@oliverio sagte in Async: Verständnisproblem:

Ich interpretiere, das

So lese ich das auch. Also ein await davor, um erst weiterzumachen wenn der Aufruf zurückkehrt.
Die aufrufende Funktion muss damit zwingens auch async sein.

[mcm1957]

@codierknecht said in Async: Verständnisproblem:

@oliverio sagte in Async: Verständnisproblem:

Ich interpretiere, das

So lese ich das auch. Also ein await davor, um erst weiterzumachen wenn der Aufruf zurückkehrt.
Die aufrufende Funktion muss damit zwingens auch async sein.

ja
oder ESM.

async ist im Adapter aber kein Problem.