klaro-org / klaro-js

Klaro Privacy Manager. An open-source, privacy-friendly & compliant consent manager for your website.

Home Page:https://klaro.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Do you have a watcher example code?

cmette opened this issue · comments

I am looking for sample code for a watcher. Do you have a link or a doc?
Best Regards
Christian

There is two types of watchers: Service-specific watchers and global watchers. For both of them, there are examples in the annotated config. If you have trouble finding them, search the page for the term callback:.

ok - i thought watchers are something else, you call callbacks "watcher" all clear :O)

but if I take a look at the doc here https://heyklaro.com/docs/api/js_api I read there that you can register and deregister the watchers and that they have a different signature than the ordinary callbacks. This is incomprehensible. Can you describe or explain this a little differently?

Ich möchte hier noch einmal ergänzende Anmerkungen machen. Es wäre wünschenswert, wenn die Doku etwas klarer wäre. Da scheint es einige Inkonsistenzen zu geben. Diese erschwerden das Verwenden von Klaro für den Entwickler.

Folgende Probleme sind mir begegnet:

  1. Wie ein Blick in den Code von Klaro.js ergibt, sind die callbacks in config und config.services weder funktional noch vom Software-Design her identisch mit den in der API-Doku am Rande erwähnten watchern. Ich habe das mal kurz ausprobiert. Ein watcher ist offs. ein Callback, der auf den Toggle-Switches des sog. ConsentManagers alias Klaro-UI? aufgehängt werden kann. Ein klaro.callback ist eine Funktion, die in die KlaroConfig eingebaut werden kann. Beide haben unterschiedliche Signaturen und werden bei unterschiedlichen Ereignissen ausgelöst.

  2. Es ist nicht ganz klar, wie die config.callbacks verwendet werden sollen. Wir sind hier als Entwickler bisher davon aus gegangen, dass der config.callback aufgerufen wird, wenn die KlaroConfig geladen wird. In der annotated config steht dafür zu lesen:

/*
You can define an optional callback function that will be called each time the
consent state for any given service changes. The consent value will be passed as
the first parameter to the function (true=consented). The service config will
be passed as the second parameter.
*/

Das suggeriert, dass der Callback jedes mal aufgerufen wird, wenn sich der Status der Zustimmung für irgend einen Service ändert. Das ist leider nicht der Fall. Das geschieht nur beim watcher. Der config.callback wird nur beim load/reload der Page aufgerufen, also mithin bei der Instantiierung des Klaro-Objekts. Wird vom Anwender danach der Zustand der Zustimmung über das UI geändert, wird weder der config.callback noch der assoziierte config.services.callback aufgerufen. Dafür wird der config.callback beim Start für jeden Dienst einzeln (mehrfach) und zusätzlich noch einmal der config.services.callback für jeden Dienst aufgerufen. Das ist unerwartet, denn für diese Funktionalität sind scheinbar die callbacks der services vorgesehen, die ja für jeden Service einzeln definiert werden können. Worin nun die Unterscheidung zwischen config.callback und config.services.callback liegt, ist aus der Doku und meinen Tests nicht ersichtlich...

  1. Es gibt dann einige schwer verständliche Punkte / bzw. diskrepante Darstellungen in der Doku. So werden im Tutorial und der annotated config die Dienste (korrekter Weise) als services bezeichnet. Das ist konzeptionell verständlich und gut dokumentiert. Will man aber im ConsentManager über die API diese Dienste verarbeiten, so werden sie dort als app bezeichnet. Das geht aber nicht direkt aus der Doku hervor. Urprünglich dachte ich, es handelt sich hier um verschiedene Sachverhalte/Objekte, aber die app der Api ist eigentlich gleichbedeutend mit einem Service aus der annotated config. Das ist verwirrend.

  2. Weiterhin werden die Begriffe Klaro-UI und ConsentManager eingeführt. Es schein aber so, als wäre das ein und dasselbe Objekt, was nicht deutlich dokumentiert ist.

klaro.show()
zeigt eigentlich das UI (also ein Overlay mit den Toggle-Switches und den Diensten)

In Anlehnung an die kargen Kommentare zum watcher, kann man folgendes machen. Das funktioniert auch:

let m = klaro.getManager();
let w1 = {
  update: function(obj, name, data) {
    console.log("mein watcher w1 ",obj,name,data);    
  }
}
m.watch(w1);

Dieser "callback" reagiert tatsächlich bei jedem toggle des ConsentManagers, was darauf hin weist, dass der ConsentManager und das UI ein und dasselbe Objekt sind. Laut annotated config ist das eigentlich das Verhalten, welches der config.callback zeigen sollte??

  1. Was mir ebenso unverständlich ist, ist die Tatsache, dass man als Entwickler ja nun gern unmittelbar auf die Zustände des aktuellen Storages reagieren möchte. Dafür gibt es aber scheinbar gar keine callbacks oder Funktionen. Das muss man in gesondertem js-code selbst nachrüsten. So stand bei uns die Frage, ob aktuell (beispielweise beim Laden der Seite) der User bereits allen Diensten zugestimmt hat, was ja im Storage vermerkt ist. Das Ergebnis sollte bei uns in einem config.callback verarbeitet werden und könnte heißen getConsentAll(). Aber leider gibt es eine derartige Funktion nicht. Sie lässt sich auch im config.callback nicht einfach realisieren, da dort let m = klaro.getManager() oder this.getManager() unmöglich ist (getManager() is not defined). Scheinbar ist zur Ausführungszeit des callbacks der ConsentManager noch nicht instantiiert. Ich habe das aber nicht weiter analysiert... Beispiele wären hier sehr hilfreich...

Ebenso greift Klaro beispielsweise bei Anfragen nach dem aktuellen consent state auf seine
get defaultConsents()
statische Konfiguration zurück. Hat der User im Storage andere Zustimmungen abgelegt, so sind die nur durch zusätzlichen eigenen Code zugänglich. Das ist unerwartet.

Klaro scheint mir insgesamt nicht schlecht zu sein. Nicht das hier ein Missverständnis entsteht, dass ich Klaro miess machen wollte. Aber es sollte eigentlich nicht nötig sein, bei der Integration einer js library mit mehr als 6000 Zeilen code, den gesamten Code selbst noch einmal studieren zu müssen. Denn mit zunehmendem Studienaufwand wird das Projekt dann obsolet. Denn dann kann man auch seine eigene library entwickeln. Die kennt man schließlich besser...

Beste Grüße

Great to see you found out how the code actually works. Personally, I have only used the service-specific callbacks in the config once for a project. I never touched the workers before. I just answered because I thought you might have missed the config's callback property.

Just a warning if you plan to submit a PR: Do not expect it to be merged, I am pretty sure the developer abandoned this project and moved on to other things. Also, the build system pretty convoluted and does not work with node above version 15.