[gelöst]: Async: Verständnisproblem

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.

Codierknecht

@mcm1957 sagte in Async: Verständnisproblem:

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

Muss ich mir anschauen.
Eine Möglichkeit wäre, nur den allerersten Aufruf des API mit setObjectNotExists zu verarbeiten.
Alle folgenden setzen dann nur noch die (dann hoffentlich existierenden) States.

Könnte allerdings dann ein Problem werden, wenn im API plötzlich neue Werte geliefert werden, die beim allerersten Aufruf nicht bekannt waren.

mcm1957

@codierknecht
Der adapter kann die Stateids cachen für die er seit seinem lStart bereits ein setObject oder exten Object abgesetzt hat. Ist durchaus üblich.

Prinzipiell ist es aber imemr ein Problem wenn der Adapter States auf Grund der Antwort des Apis anlegt da er dann den Typ meist nur heuritisch ermitteln kann und Roles, Units etc. gar nicht. Oft ist es besser, wenn der Adapter eine Liste der bekannten States kennt, diese mit Typ, Role, UNits etc. anlegt und allenfalls vom Api neu gelieferte Werte zunächst ignoriert und/oder einmal (!) als Info loggt. Kann man dann in einer neuen Release ergänzen.

OliverIO

@ticaki sagte in Async: Verständnisproblem:

Wegen der Anmerkung das 5 noch immer aktiv ist

5.0.19 hat auch noch relativ viele nutzer.

mcm1957 · 5.0.19 hat auch noch relativ viele nutzer.

@oliverio
js-controller 5 wird aber abnehmen. Telegram als ein Massenadapter verlangt schon js-controller 6 (wenn ichs richtig im Kopf habe). Weitere werden sicher bald folgen. Immerhin ist js-controlelr 6 jetzt schon bald ein Jahr draußen.

Also wenn wer will und ev. eh na major Release erstellt kann / soll er ruhig js-controller 6 verlangen.

NEWS