Javascript - Verständnisproblem mit if ...

[paul53]

@klassisch sagte:

warum ist das besser

Weil das in der lokalen Variablen obj bereits vorliegt und nicht erst durch eine Funktion abgeholt werden muss (Ressourcenverbrauch).

@klassisch sagte in Javascript - Verständnisproblem mit if ...:

wo finde ich mehr Informationen dazu?

In der Funktions-Doku.

@klassisch sagte in Javascript - Verständnisproblem mit if ...:

daß man damit auch den vorherigen Status des Objscts abfragen kann

Ja, bei on()

obj.oldState

[Nahasapee]

@klassisch und wenn du in deinem else sowieso "nothing" machen willst und nur auf true reagieren willst kannst du es auch gleich in dein trigger setzen , dann brauchst du gar nix mehr prüfen.

on({id: 'javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1'/*Timer Solar Plug1*/, change: "ne" , val :true},(obj)=>{});

[klassisch]

@paul53

so langsam beginnt es zu dämmern.
Bisher habe ich verwendet

on({id: 'javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1', change: "ne"}, function() {
	result = getState('javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1').val;
});

und mich gefragt, warum das Objekt zweimal anfassen muß.
Muß man aber nicht, geht auch so

on({id: 'javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1', change: "ne"}, (obj){
	result = obj.state.val;	
});

und es geht noch mehr wie zB. oldState.

Ist dabei obj ein fester Begriff oder köönte das auch data123 oder so heißen?

[paul53]

@klassisch sagte:

köönte das auch data123 oder so heißen?

Ja. Ich verwende dp, das es das statische Objekt und den Zustand (state, oldState) liefert.

on('javascript.0.Visuobjekte.SoftSwitch.Timer_Solar_Plug1', function(dp) { // triggert bei Wertänderung
   let val = dp.state.val;	
});

[klassisch]

@paul53 Danke, also dp als Abkürzung für data point. Muß man die unterscheiden, wenn man mehree "on" statements im Script hat, also dp01, dp02 ?

[paul53]

@klassisch sagte:

Muß man die unterscheiden, wenn man mehree "on" statements im Script hat, also dp01, dp02 ?

Nein, Funktionsparameter sind lokal, d.h. nur innerhalb der jeweiligen Callback-Funktion gültig.

[klassisch]

@paul53 Danke! Falls man das schachteln würde (wobei mir bei on jetzt nichts dazu einfiele), dann wäre eine andere Benennung wohl sinnvoll.

[paul53]

@klassisch sagte:

Falls man das schachteln würde (wobei mir bei on jetzt nichts dazu einfiele), dann wäre eine andere Benennung wohl sinnvoll.

I.d.R. nicht. Beim Schachteln von Triggern sollte man genau wissen, was man tut.

[klassisch]

@paul53 wenn wir schon bei solchen "Abkürzungen" sind: Kann man den Datenpunkt nach der Operation auch wieder vereinfacht zurückspeichern, also nicht mit setState(id, value), sondern mit dp. irgendwas?

[paul53]

@klassisch sagte:

Kann man den Datenpunkt nach der Operation auch wieder vereinfacht zurückspeichern,

Du meinst den Trigger-Datenpunkt ?

setState(dp.id, neuer_Wert);

Damit löst man aber meist einen neuen Trigger aus.

[klassisch]

@paul53 sagte in Javascript - Verständnisproblem mit if ...:

@klassisch sagte:

Kann man den Datenpunkt nach der Operation auch wieder vereinfacht zurückspeichern,

Du meinst den Trigger-Datenpunkt ?

Ja, den Datenpunkt, auf den man getriggert hat, dessen Wert man dann entnommen und verarbeitet hat und dessen neuen Wert man dann zurückspeichern möchte.

setState(dp.id, neuer_Wert);

Damit löst man aber meist einen neuen Trigger aus.

Oh, das könnte dann oszillieren bzw. in einer Endlosschleife enden.

[paul53]

@klassisch sagte:

Oh, das könnte dann oszillieren bzw. in einer Endlosschleife enden.

Ja, wenn man es nicht abfängt.