Umsetzung Adapter auf Class

[foxthefox]

Ich versuche gerade den fritzdect Adapter auf die klassenbasierte Variante umzusetzen.

für die Funktion decrypt gibt es vom linter diese Meldung:

Class 'AdapterInstance<undefined, undefined>' defines instance member property 'decrypt', but extended class 'Fritzdect' defines it as instance member function.ts(2425)

ist das normal, oder kann ich da etwas verbessern?

und dann habe ich noch Probleme mit adapter.log was nun zu this.log wird.
für das errorhandling habe ich Aufrufe mit

.catch(this.errorHandler);

und dann die Funktion

errorHandler(error) {....}

hier scheint das this.log nicht mehr zu gehen, muß ich dazu im constructor etwas machen?
und wenn ja was?
etwa so:

this.errorHandler.bind(this); ???

und dann kommt da noch die Warnung:

Deprecated! Please use objectsInMemServerRedis.js in tests!

????

Gruß
Klaus

[UncleSam]

@foxthefox sagte in Umsetzung Adapter auf Class:

Ich versuche gerade den fritzdect Adapter auf die klassenbasierte Variante umzusetzen.

Super Idee, das habe ich auch bei mehreren Adaptern gemacht. Hilft ungemein, schönen Code zu schreiben. Allerdings habe ich gleich auch auf TypeScript umgestellt. Du kannst genauso JavaScript Code schreiben wie vorher, aber es geht dann noch mehr typisiert (wenn gewünscht).

für die Funktion decrypt gibt es vom linter diese Meldung:

Class 'AdapterInstance<undefined, undefined>' defines instance member property 'decrypt', but extended class 'Fritzdect' defines it as instance member function.ts(2425)

ist das normal, oder kann ich da etwas verbessern?

Hast du selber eine Funktion decrypt geschrieben? Es gibt bereits eine so benannte Funktion in der Basisklasse.

und dann habe ich noch Probleme mit adapter.log was nun zu this.log wird.
für das errorhandling habe ich Aufrufe mit

.catch(this.errorHandler);

und dann die Funktion

errorHandler(error) {....}

hier scheint das this.log nicht mehr zu gehen, muß ich dazu im constructor etwas machen?
und wenn ja was?
etwa so: this.errorHandler.bind(this);

Ganz genau. Ich bevorzuge allerdings einfach Lambdas zu verwenden: catch(e => this.errorHandler(e));
Aber das ist Geschmacksache.

Hingegen würde ich gleich auf alle async/await gehen, anstatt noch direkt mit Promises zu arbeiten. Das gibt noch viel schöneren Code!

und dann kommt da noch die Warnung:

Deprecated! Please use objectsInMemServerRedis.js in tests!

????

Ich würde an deiner Stelle den Adapter neu mit dem Adapter Creator erstellen und dann den alten Code übernehmen, so sollten solche Fehler nicht mehr vorkommen. Zudem kannst du den Code dann recht einfach aktuell halten. Das habe ich bei meinen beiden Adaptern so gemacht und bin sehr glücklich damit.

[foxthefox]

@UncleSam

danke.

ich hatte die Meldung schon so interpretiert, wenn ich die vorhandene decrypt nehme, dann braucht die scheinbar nur ein Argument. Ich habe die Funktion, die in de meisten verwendet Adaptern verwendet wird (damals den Tip bekommen, mir es von iobroker.meross abzuschauen).
Wenn nur noch ein Argument verwendet wird, dann ist wohl irgendwie sichergestellt, daß 'system.config.native.secret' schon vorgesetzt ist ?!

Also wenn ich es richtig verstehen this.errorHandler.bind(this); UND catch(e => this.errorHandler(e));??

Wie ich alles auf async/await umstelle, habe ich keinen Plan Ich bin da nicht der Guru, soll das dann alles ein try/catch mit innenliegenden await sein ?

Den neuen Adapter habe ich genau wie bevorzugt mit dem creator angelegt und dann mühevoll meinen alten code dort hinein adaptiert, leider kommt die Meldung trotzdem.

Bin noch am experimentieren wie ich den integration test hinbekomme. Das ist komplett anders als vorher
Aber dazu muß ich wohl nen eigenen Thread aufmachen.

Gruß
Klaus

[UncleSam]

@foxthefox sagte in Umsetzung Adapter auf Class:

ich hatte die Meldung schon so interpretiert, wenn ich die vorhandene decrypt nehme, dann braucht die scheinbar nur ein Argument. Ich habe die Funktion, die in de meisten verwendet Adaptern verwendet wird (damals den Tip bekommen, mir es von iobroker.meross abzuschauen).

Ich würde solche "alten Zöpfe" abschneiden (sofern du Kompatibilität garantieren kannst). Wenn du auf die eingebaute Funktion wechselst, wird auch die zukünftige bessere Verschlüsselung einfach so funktioneren.

Wenn nur noch ein Argument verwendet wird, dann ist wohl irgendwie sichergestellt, daß 'system.config.native.secret' schon vorgesetzt ist ?!

Musst du im Code von adapter-core nachschauen.

Also wenn ich es richtig verstehen this.errorHandler.bind(this); UND catch(e => this.errorHandler(e));??

Nein, entweder oder.

Wie ich alles auf async/await umstelle, habe ich keinen Plan Ich bin da nicht der Guru, soll das dann alles ein try/catch mit innenliegenden await sein ?

Genau. Den Code schreibst du dann, als ob es synchron wäre (einfach eine Zeile nach der anderen) ohne irgendwelche then und catch. Schau dir mal eine Einführung zB auf YouTube an. Der Code wird so viel lesbarer.

Den neuen Adapter habe ich genau wie bevorzugt mit dem creator angelegt und dann mühevoll meinen alten code dort hinein adaptiert, leider kommt die Meldung trotzdem.

Super!

[AlCalzone]

@UncleSam sagte in Umsetzung Adapter auf Class:

Wie ich alles auf async/await umstelle, habe ich keinen Plan

Hilft dir das?
https://gist.github.com/AlCalzone/d14b854b69ce5e8a03718336cc650a95#

[foxthefox]

@AlCalzone
SUPER writeup!

Kapitel 6, war so meine Idee was damit gemeint ist.