UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Codierknecht]

Ich habe noch immer Probleme beim Verständnis von async.
Kann mir da mal jemand Licht ans Fahrrad machen?

Nehmen wir mal folgendes Beispiel:

async function doSomething() {
    TestSync('my.id', 'myValue');
    await TestAsync('my.id', 'myValue');
}

function TestSync (stateId, value) {
  setState(stateId, value);
}

async function TestAsync (stateId, value) {
  await setStateAsync(stateId, value);
}

Kann ich in einer async function auch nicht-async Funktionen aufrufen?
Wenn ja: Wie verhält sich solch ein Aufruf dann? Wir abgewartet bis das Ergebnis zurückgeliefert wird?
Oder sollte man hier auf die asynchrone Version und await umstellen?

Ist es "guter Stil", alle Funktionen auf async umzustellen?
Oder mixt man das so wie es halt gebraucht wird?

[mcm1957]

@codierknecht

Falls es sich um Adaptercode handelt gilt Nachfolgendes. Im javascript Adapter kann es ggF Abweichungen geben, da weiß ich nicht gesichert Bescheid.

Du kannst in einer async Funktion jederzeit synchrine Funktionen aufrufen. Eine synchrone Funtkion wird schlicht und einfach abgearbeitet uns sobald die retourniert ist alles was drinnen geschieht auch erledigt.

setState (wenn es die adapater.setState / this.setState Funktion ist) ist ASYNCHRON. Diese retourniert sofort - nur die als Callback angebbare Funktion wird erst nach Abschluss des "StateSetzens" aufgerufen. Ohne Callback ist setState und setStateAsynch in actuellen js-controller Versionen ident. Also auch bei setState ohne Callback muss ein await davor wenn du sicherstellen wiullst dass alles erledigt ist.

Ein Mix von callbacks und async ist eher abzuraten da man da rasch den Überblick verliert. Aktuell wird empfohlen nur async Functionen und keine Callbacks mehr zu verwenden.

Aber wie geschrieben: viele Routinen sind in den aktuellen js-controller Versionen auch ohne Async Zusatz awaitable (sprich sie liefern ein promise zurück auf das mit await gewartet werden kann) In diesem Fall sind dann die xxxAsync functionen deprectaed (funktioneiren aber weiterhin uneingeschränkt).

Generell empfehle ich für solche Fragen sofern sie sich auf Adapetrdevelopment beziehen die Verwendung unserer Telegram/Discord Channels (Invites auf www.iobroker.dev) - dort sind mehr Devs unterwegs...

Nachtrag:
Die Routine

function TestSync (stateId, value) {
  setState(stateId, value);
}

stellt NICHT sicher dass der state gesetzt ist wenn sie retourniert. Und hat das noch nie getan. setState kehrt und kehrte immer sofort zurück. Früher konnte man nur durch Angabe einer CallbackRoutine (als 3ten Parameter) darauf reagieren dass der State sicher gesetzt ist. Das geht unverändert noch immer. In aktuellen js-controller Versionen funktioniert auf ein await davor (setzt dann aber eine async Funtkion voraus.

[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]

@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.