Sporadischer Nebula-Fehler

[rowe42]

Beim Starten oder Refresh (F5) der Anwendung kommt es sporadisch zu einem Fehler. Obwohl man in der Netzwerkausgabe sieht, dass locales.json geladen wurde, sagt die Fehlermeldung, dass die resources nicht verfügbar sind, so dass keine Übersetzungen vorgenommen werden.

Wenn man dann Refresh macht, funktioniert es wieder.

Kommt v.a. vor, wenn man das Frontend als JAR im Security-Modus im API-Gateway betreibt. Evtl. ist das irgendeine Art von Racing Condition Problem? Ich habe den ganzen Nachmittag gegrübelt, aber finde keinen Ansatz wie man das angehen soll.

Ideen? @xdoo @dragonfly28 @ejcsid @Baumfrosch

[rowe42]

Ich habe einen Verdacht, woran es liegen kann. Die Fehlermeldung oben kommt aus https://github.com/xdoo/lhm_animad_admin_html5/blob/master/src/behaviors/animad-i18n-behavior.html und zwar aus der Methode _init, aufgerufen wenn das erste Mal die Methode t() verwendet wird. Das Problem ist, dass wir das Element <nebula-resources> holen und daraus das Property resources. Dieses wird aber in nebula-resources asynchron geholt und kann u.U. noch gar nicht geladen sein. Dann kommt es zur Fehlermeldung.

Da hat @xdoo wohl eine eigene Version des i18n-Beaviors gemacht. Bei ArsNebula gibt es bereits eine (https://github.com/arsnebula/nebula-i18n/blob/master/nebula-polyglot-behavior.html), die verhält sich aber etwas andere als unsere - und der Code ist recht komplex, ich kann durch Code-lesen nicht erkennen, ob das Problem dort auch besteht.

Mögliche Optionen:

• Wir machen eine synchrone Wait-Schleife rein, wie hier vorgeschlagen: https://stackoverflow.com/questions/31750518/javascript-waiting-until-property-of-an-element-is-ready-to-continue
• Wir nutzen "irgendwie" das bereits bestehende Behavior von Nebula, falls dieses das Problem im Griff hat. Wir müssten aber ziemlich viel umschreiben oder irgendwie davon ableiten (was ja bei Behaviors schwierig ist)
• Wir arbeiten "irgendwie" mit Promises, die wir an das erfolgreiche Setzen von Property resources hängen

An dem "irgendwie" könnt ihr sehen, dass mir bei den Optionen 2 und 3 nicht klar ist, ob und wie das funktionieren würde.

[rowe42]

Ich habe Option 2 von oben (bestehende Behavior von Nebula) mal im neuen Branch _#187 testweise für die Keepers-View umgesetzt. Um es besser testen zu können, sollte man unter bower_components/nebula-i18n/nebula-resources.html die Methode [fetchResources] wie folgt verändern:

      fetch(url, params).then((response) => {
        return response.json()
      }).then((resources) => {
        console.log('timeout started');
        setTimeout( function(a,b){console.log('timeout finished, setting resources'); this._setResources(a);this[fire]('loaded', resources)}.bind(this), 6000, resources);
//        this._setResources(resources);
//        this[fire]('loaded', resources)
      }).catch((error) => {
        this[fire]('error', error)
      })

Dadurch wird das setzen der Resources um 6 Sekunden verzögert, was dafür sorgt, dass das Problem auf jeden Fall auftritt.

[rowe42]

Die Animad-App ist nun überall auf das Nebula-Behavior umgebaut. Es funktioniert nun grundsätzlich. Der Code ist aber nicht so schön, denn

• man muss an jedes Element, das i18n braucht, die Properties resources="[[resources]]" und lang="[[lang]]" durchschleusen
• man muss das Nebula-Behavior als erstes Behavior in der Mixin-Angabe verwenden - sonst werden unsere Backend-Requests doppelt abgeschickt (keine Ahnung warum)

Aus diesem Grund werde ich das Issue nicht schließen, sondern @xdoo zuweisen. Er soll bitte entscheiden, ob wir das so lassen wollen oder ob er eine bessere Idee hat - muss aber mit dem o.g. Racing-Condition-Problem zurechtkommen.

[rowe42]

@xdoo mittlerweile hat sich meine Version auch in den Templates niedergeschlagen und es wäre aufwändig, das jetzt wieder rückgängig zu machen. Da du dich zu diesem Thema nicht geäußert hast, schließe ich das Issue und entferne die ursprüngliche Behavior im Templating. Mache gern ein neues auf, wenn du möchtest.